From 0e6c08a7214bda008a22bcf5751d58881f84d01c Mon Sep 17 00:00:00 2001 From: rkoster Date: Tue, 22 Sep 2026 09:42:01 +0200 Subject: [PATCH 1/2] docs: add Boundary agent workloads research note --- research/hashicorp-boundary.md | 107 +++++++++++++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 research/hashicorp-boundary.md diff --git a/research/hashicorp-boundary.md b/research/hashicorp-boundary.md new file mode 100644 index 0000000..db2d36b --- /dev/null +++ b/research/hashicorp-boundary.md @@ -0,0 +1,107 @@ +--- +title: "HashiCorp Boundary for Agent Workload Access" +author: Ruben Koster (@rkoster) +date: 2026-09-22 +tags: [authorization, workload-isolation, credentials, security, ecosystem-survey] +cf_areas: [uaa, capi, diego, loggregator] +status: draft +ratings: + platform-impact: + value: 78 + note: "Boundary could address access mediation and credential brokering around agent sessions, but would complement rather than replace CF isolation primitives." + maturity: + value: 75 + note: "Boundary is an established HashiCorp project with documented operating concepts, while its fit for CF-hosted agent workloads remains unvalidated." + novelty: + value: 62 + note: "The access-brokering model is established, but applying it to agent sessions and CF workload identity raises a useful platform-specific connection." + actionability: + value: 70 + note: "The model yields concrete questions about identity mapping, target placement, credential ownership, and session lifecycle for a CF prototype." +sources: + - https://developer.hashicorp.com/boundary/docs/domain-model + - https://developer.hashicorp.com/boundary/docs/domain-model/workers + - https://developer.hashicorp.com/boundary/docs/domain-model/targets + - https://developer.hashicorp.com/boundary/docs/domain-model/sessions + - https://developer.hashicorp.com/boundary/docs/domain-model/credential-libraries + - https://developer.hashicorp.com/boundary/docs/concepts/security/permissions + - https://github.com/hashicorp/boundary +--- + +## Summary + +HashiCorp Boundary is an identity-based access broker for dynamic infrastructure. It authorizes +users to establish sessions to defined targets through workers, and can associate session access +with credentials retrieved from configured credential stores. This makes it relevant to agent +workloads that need narrowly scoped access to tools or infrastructure, but Boundary is an access +plane, not a process, VM, filesystem, or network sandbox; the note is descriptive rather than an +adoption recommendation. + +## Key findings + +- **Boundary separates authorization from connectivity.** Its domain model organizes identities, + roles, scopes, projects, targets, hosts, and credential resources. Workers form the data plane: + they proxy sessions between users and targets and can provide access to private resources without + exposing their networks directly. +- **Targets are the access unit.** A target represents a networked service with permissions that a + user can exercise through a session. A role must grant the `authorize-session` permission before + the user can establish a session to the target. This is a more specific control point than + giving an agent broad network reachability. +- **Sessions have explicit lifecycle controls.** A session receives an expiration time and + connection limit from the target. It can be terminated by expiry, cancellation, or removal of a + resource associated with the session. Boundary documents that credentials associated with the + session are revoked when the session terminates, while permission changes are evaluated only when + a session is established. +- **Credential handling can be separated from the agent.** Credential libraries provide credentials + from a credential store, including integrations that retrieve credentials from Vault. This can + support per-session or otherwise centrally managed access without placing a long-lived secret in + an agent image, although the exact lifetime and rotation behavior depends on the credential store + and integration. +- **Workers are a deployable trust boundary, not an agent sandbox.** Worker placement and tags can + constrain which workers handle a target, and workers can reach private services. That supports + network segmentation and brokering, but does not by itself isolate the agent process, its + filesystem, or its local execution environment. +- **The model is applicable to tool and infrastructure access.** An agent could request access to + an approved tool endpoint or infrastructure target under a workload identity, with policy + deciding which target and worker are eligible. The agent would still need separate controls for + tool semantics, prompt injection, delegated-agent authority, and execution sandboxing. +- **Audit and security are part of the platform model.** Boundary captures data relevant to session + authorization and retains historical session data in its data warehouse. Operators still need to + decide which agent context is safe to record and how Boundary events correlate with application, + request, and tool-invocation records elsewhere. + +## CF relevance + +Boundary could complement Cloud Foundry rather than replace its workload lifecycle or isolation +mechanisms. CAPI and Diego could continue to schedule and manage the agent application or task, while +Boundary workers mediate narrowly selected connections from that workload to private services, +databases, administrative endpoints, or tool backends. CF identity or workload credentials could be +inputs to a Boundary authentication and authorization flow, but the mapping between a CF user, app, +task, instance, and Boundary principal is not established by these sources. + +This division could make the security boundary more explicit: CF governs where the agent runs and +Boundary governs which external targets it may reach and for how long. Worker placement would need +to align with CF networking and foundation or space boundaries, while Loggregator or another audit +pipeline could correlate Boundary session events with app, instance, task, and request identifiers. +Those are integration hypotheses, not existing CF capabilities. In particular, Boundary should not +be presented as the answer to per-session compute isolation; a sandbox or hardened execution +primitive remains necessary for untrusted code and tool processes. + +## Open questions + +- How should a CF user, application, task, instance, or delegated agent be represented and + authenticated as a Boundary principal? +- Should Boundary workers run inside CF spaces or foundations, outside them, or in a separate + security zone, and who operates and updates those workers? +- How can authorization prevent a confused-deputy path when an agent invokes a tool or delegates + work to another agent? +- Who owns the credential store, and what guarantees do each credential integration and target type + provide for issuance, rotation, expiration, and revocation? +- How should an app or task exit terminate its Boundary sessions, including sessions opened by + delegated agents or background tools? +- How should Boundary events correlate with CF app, space, instance, task, user, and request IDs + without logging sensitive prompts, arguments, or credentials? +- What are the expected latency, availability, retry, and fail-open/fail-closed semantics when the + Boundary control plane or a worker is unavailable during an agent tool call? +- Which additional primitive should provide process, filesystem, or network sandboxing for code and + tools that are not trusted merely because their target access was authorized? From 5aa7c78685e068190fa6d8c0bd61c2f3871fbe22 Mon Sep 17 00:00:00 2001 From: rkoster Date: Tue, 22 Sep 2026 09:45:47 +0200 Subject: [PATCH 2/2] chore: update generated research map --- generated/research-map.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/generated/research-map.html b/generated/research-map.html index d59a346..fab2574 100644 --- a/generated/research-map.html +++ b/generated/research-map.html @@ -23,9 +23,9 @@

Focus use cases

Attested Workload Authority and Mediated Tool AccessExchange platform-attested workload identity for scoped authority while credentials and outbound tool access remain mediated by the platform.Strategic decision: Decide whether CF should become the portable trust and policy layer between agent workloads and the tools they invoke.
Gap, experiments, and evidence
Current CF gap
CF issues workload identity certificates but does not exchange them for scoped tool authority, keep third-party credentials out of workloads, mediate off-platform access, or record delegation-aware audit events.
Candidate POC
Exchange a Diego instance identity certificate for a short-lived scoped token, invoke one allowed tool through a credential proxy and egress mediator, deny another, and emit attributable audit events.
Candidate RFC scope
Define workload token exchange, authority and delegation claims, credential brokering, outbound mediation and policy enforcement, audit events, revocation, and integration boundaries for UAA, routing, and service brokers.

Core

Supporting

-
Gap, experiments, and evidence
Current CF gap
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.

Core

Supporting

ResearchIdea

Platform Impact x Maturity

Emerging < Maturity > EstablishedLocal concern < Platform Impact > Platform-wide concern
Unplaced notes (0)
  • All notes are placed.
+
Gap, experiments, and evidence
Current CF gap
CF can stage apps and run ephemeral tasks but cannot cheaply compose a reusable environment with per-session workspace state, select stronger isolation, constrain session networking, or resume the session lifecycle.
Candidate POC
Start two isolated sessions from one content-addressed staged environment, attach separate mutable workspaces, apply per-session egress policy, stop one session, and resume it on fresh compute.
Candidate RFC scope
Define environment and workspace references, session identity and lifecycle, isolation classes, network policy, workspace persistence and cleanup, scheduling, quotas, and compatibility with existing CF staging and task APIs.

Core

Supporting

ResearchIdea

Platform Impact x Maturity

Emerging < Maturity > EstablishedLocal concern < Platform Impact > Platform-wide concern
Unplaced notes (0)
  • All notes are placed.
 -