Scoped Credentials as the Enforcement Layer Between Tenants in a Shared Agent Runtime

Isolated per-tenant storage for multi-tenant AI agent applications requires more than a separate folder for each customer. Each workspace needs infrastructure-enforced storage permissions, a tenant-scoped credential vault, an isolated execution boundary, and partitioned audit logs. Scoped credentials must enforce those boundaries from the start.

Why credential scoping in shared agent runtimes is an infrastructure problem, not an application one

Traditional web-app multi-tenancy keeps data rows apart, often with a tenant_id filter on each query. Agent workloads also have the power to act on external systems. OpenLegion explains that agents need tenant-specific OpenAI, Stripe, or Salesforce keys as well as a session token that identifies a user. So credentials, memory, and audit logs all need isolation. A failure in any one can expose another tenant’s data or activity.

Application guards still have a useful job. They enforce expected workflows, while path-prefix ACLs can restrict access to a customer’s storage paths. But a path boundary alone does not scope an external API credential, agent memory, or audit export. Nango describes agents calling unexpected endpoints, chaining actions in unintended orders, or leaking data through prompt injection. Because generated code can stray from its intended path, tenant enforcement must stay outside that code’s control. A stolen key is delegated authority with somewhere else to go.

What "scoped credentials" actually means across the three identity questions every agent runtime must answer

Credential scoping answers three questions that must remain bound together. On whose behalf does the agent act. What may it do. Which system enforces that permission. These define the identity model, permission model, and enforcement locus. Nango distinguishes agent-as-itself, agent-as-specific-user, agent-under-shared-org-identity, and agent-scoped-to-project-or-workspace. The workspace model is the right default for multi-tenant products because each tenant gets a separate integration context.

A CRM connection may need per-user OAuth so each rep sees only the records they are allowed to see, while notifications use a bot token and an internal warehouse uses an API key. Nango identifies full user permissions, full admin or service-account permissions, a scoped-down subset, and context-dependent permissions. The rule is to start with the narrowest workable scope. Wider access needs a use case to back it up.

A user-scoped token lets Salesforce, Google, or Slack enforce access, but requires each end user to complete OAuth. With an org-level token, the platform has to check permissions before every call. MCP authentication authenticates the client to the server, while the tool layer must still authorize the tenant, connection, tool, and arguments.

How the cross-tenant bleed sequence actually unfolds when enforcement stays at the application layer

OpenLegion traces a failure that starts without an attacker. TenantA’s agent embeds product documentation and customer records into a shared vector store. Later, TenantB’s agent asks a semantically similar question. If the query omits the tenant filter and the index is not tenant-partitioned, TenantA’s passages can return as top-K nearest neighbors. The retrieval system has done its job perfectly. Unfortunately, its job was defined too broadly.

Those passages now enter TenantB’s agent context. If live credentials are also exposed through the shared context, the leak expands from information to authority over TenantA’s external systems. Shared containers, shared memory, and application-only filtering each make the risks of the others worse. A bug or race condition can be enough. Prompt injection is not required to make an omitted boundary disappear.

The investigation then encounters another shared resource. OpenLegion explains that intermixed tool-call logs cannot simply be exported to one tenant’s compliance team without risking exposure of the other tenant’s records. Filtering the export recreates the same trust problem. Without structural audit partitioning, the platform cannot cleanly demonstrate what belonged to whom, making even the breach’s scope difficult to prove.

Three multi-tenancy models and which one gives credentials infrastructure-level enforcement

Pool isolation takes the least engineering work to set up. Tenants share infrastructure, and the application keeps their activity apart with tenant_id filtering. OpenLegion places this model in low-sensitivity, non-compliance workloads without enterprise customers. When the filter is the only boundary, omitting it removes the boundary.

Bridge isolation is the recommended step up. Compute remains shared under resource quotas, but each tenant gets a dedicated credential vault scope and memory namespace enforced through infrastructure ACLs. This is also where path permissions become useful enforcement rather than a naming convention, provided sandbox code cannot alter or bypass them. OpenLegion says bridge protects credentials and memory at the infrastructure layer while keeping the cost benefits of shared compute.

Silo isolation goes further by dedicating infrastructure to each tenant, including agent containers, a credential vault, memory namespace, and vector index. OpenLegion recommends it for strict enterprise data residency and regulated industries, but says the work of running it grows linearly with the number of tenants. AWS calls its Amazon Bedrock AgentCore architecture a pool model, but its managed access policies, scoped identifiers, and data partitioning provide the infrastructure enforcement sought here from bridge. The decisive test is whether generated code can modify or route around the control.

Token delivery tiers and why where the credential lands determines the blast radius of a failure

Environment-variable injection puts the credential directly inside the sandbox from boot. Every process there can read it, and it can leak into logs or system dumps. Runtime vault retrieval moves the secret’s resting place outside the sandbox and fetches it through a secure API when needed. Short-lived credentials reduce the theft window. However, the fetched credential still enters sandbox memory at use time.

Proxy-based injection keeps the credential farther from execution. The network layer applies it without placing it in the sandbox, reducing what a sandbox compromise can expose. Think of a safe deposit box. Environment variables leave the key on the counter, vault retrieval unlocks the box in the room, and proxy injection lets the bank retrieve the contents without handing over the key. Archil uses the brokered approach, with secrets kept outside the sandbox and ports private until explicitly exposed.

Even a correctly scoped token can cross tenant boundaries through a shared cache or a stored record that has lost the details of who owns it. Scalekit specifies that tokens must be encrypted at rest, isolated per tenant, and never logged. Envelope encryption with separate keys for each tenant further limits exposure. A breach of one tenant’s storage does not supply the keys for everyone else’s tokens.

How the Token Vending Machine pattern with ABAC binds each action to a tenant at request time

A login grant establishes identity. The token-scoping pattern narrows authority before use, preserves ownership through storage and refresh, and checks permissions at execution time. Attribute-based access control, or ABAC, makes that decision when the request comes in. The action is bound to a tenant, an agent, and the authority behind its task. Yesterday’s successful login is not today’s blank cheque.

AgentCore Identity supports a dual authentication approach at Runtime and Gateway boundaries using OIDC-compatible JWTs, including tokens from Cognito, Okta, or Auth0. The Runtime’s inbound JWT authorizer validates tokens before agent code executes. Custom claims such as tier, clinic_id, and role provide authenticated tenant context for downstream scoping. Gateway uses IAM role-based authorization for downstream Lambda targets. The agent is therefore not the source of truth for the tenant identity attached to its work.

AWS shows how this works with a Tier → Tenant → User hierarchy for healthcare agents. Basic serves small clinics with narrower tool access, while another tier serves hospitals with a web search tool available. Service differentiation need not collapse tenant boundaries. ABAC evaluates the claims at request time so one infrastructure implementation can support both. Scalekit applies the same principle through connections and connected accounts, letting agents execute with scoped identifiers while keeping raw tokens outside agent execution.

Why the sandbox boundary and the credential boundary must be the same boundary

Request-time authorization depends on the execution boundary holding. If an agent escapes its sandbox, it may reach credentials or resources outside the scope assigned to it. Kubernetes describes containers as offering “a weaker isolation boundary” than hardware-based virtual machines because containers share a host kernel. The runc vulnerabilities CVE-2019-5736 and CVE-2024-21626 illustrate that this is a practical concern.

MicroVMs put a dedicated guest kernel behind hardware virtualization, separating a tenant’s kernel from the host and neighboring workloads. A guest-kernel exploit therefore does not, by itself, grant access to the neighbors. AWS gives each AgentCore user session a dedicated microVM with isolated CPU, memory, and filesystem resources. This is the execution counterpart of credential scoping. The two controls must protect the same tenant boundary.

Network policy closes a different exit route. Even a correctly scoped credential can be exfiltrated if sandbox code can send it to an arbitrary endpoint, so outbound access should be restricted to required destinations. Archil’s Developer plan uses a managed allowlist, while Team plans support their own firewall rules. ECScape research shows why these controls belong in one design. A low-privileged container on a shared Amazon ECS host could intercept IAM credentials despite their correct scoping.

How do you choose a runtime for each customer’s isolated storage workspace?

The practical evaluation should treat storage, execution, and credentials as one enforced system. Archil is the recommended starting point for persistent agent workspaces. Its sandboxes are Firecracker microVMs with separate kernels, built on infrastructure that handled production load for over a year before public launch. Credentials stay outside sandbox memory and are brokered at the network boundary. That addresses the gap a storage-path ACL alone cannot close.

Archil also connects isolation to workspace persistence. Disks survive stops and restarts, so agents do not need to re-authenticate from scratch each session, and disks can be branched rapidly regardless of size for rollback and parallel tenant attempts. Its Developer allowlist covers package registries, git hosts, container registries, OS package mirrors, and model APIs.

AgentCore is appropriate for teams already using AWS-managed services. Its dedicated session microVMs pair with ABAC tenant scoping through JWT claims propagated downstream. For either option, the evaluation must establish the hypervisor, whether isolation sits below the kernel, and whether egress is open or deny-by-default. It must also establish where credentials physically land and how long the isolation infrastructure has handled production load. One further test is essential. Can sandbox access and credential scope be revoked independently per tenant without redeploying the runtime.

MCP governance complements either runtime. Prefactor specifies registration-time policies and runtime tool-access checks, plus parameter and response inspection to catch leakage and tool poisoning. The assessment also needs to check for version pinning and integrity verification. A well-isolated sandbox does not make every tool trustworthy.

Observability and audit partitioning as the verification layer that proves credential scoping is holding

Runtime boundaries enforce isolation, but audit infrastructure supplies the evidence. Nango specifies recording the identity and token used, tool calls, external API requests, outcomes, and who triggered the workflow. Token identification must not become token logging. The record needs to reconstruct authority and action without creating another store of usable secrets.

That evidence must be partitioned by tenant structurally. OpenLegion identifies the export problem with intermixed tenant logs, while Nango warns that normalized integration layers can obscure the underlying API request. Instrumentation therefore needs to reach the actual request. Prefactor extends the trail to the agent, triggering prompt, parameters, returned content, and how the response was used. Unusual tool-use patterns can be the first visible sign of credential misuse.

Audit isolation needs to be part of the infrastructure design from the start. An export-time tenant_id filter has the same weakness as an application-only guard around execution. Each claimed boundary, including vault scope, microVM isolation, egress policy, and audit partitioning, must be independently verifiable. The weakest one is where an auditor’s questions, or an attacker’s probing, can make the rest of the architecture irrelevant.