Secrets Isolation In Multi-Agent Environments: Why Shared Vaults Become Single-Compromise Points

TL;DR

The default secrets architecture in most agent platforms is a single vault holding the credentials every agent needs, with role-based access controls deciding which agent can read which secret. The architecture optimizes for operational convenience and looks correct in security review. It collapses on the day a single agent is compromised, because the compromised agent has read access to a much larger set of secrets than the operation it actually performs requires. The replacement architecture has three properties: each agent has its own vault that no other agent can read, every secret in the vault is constrained by a capability scope that names the operation it authorizes, and the secret is minted just in time for the call that uses it. This essay walks through the failure mode, the architecture, and the implementation tradeoffs. The reader artifact is a Secrets Isolation Architecture you can apply to any multi-agent platform.

Introduction: The Compromise That Made The Problem Visible

A logistics platform ran fourteen agents that orchestrated shipping operations across forty-seven carriers. Each agent specialized: one handled rate quotes, one handled label generation, one handled tracking, one handled exceptions, and so on. The platform had a single vault that held the credentials for all forty-seven carriers, and each agent had read access to whichever carrier credentials it needed. The access control was carefully scoped at the role level. The rate-quote agent could read rate-API credentials but not label-generation credentials. The label-generation agent could read label-API credentials but not tracking credentials. The team had reviewed the access matrix and could defend it.

The compromise started with a deserialization vulnerability in the exceptions agent. The exceptions agent processed inbound emails from carriers about delivery problems, and one of the email parsers had a flaw that let a crafted email cause the agent process to execute arbitrary code. An attacker who had been studying the platform sent a crafted email and obtained a shell inside the agent process. From the shell, the attacker had everything the exceptions agent had: its environment variables, its mounted file systems, and most importantly its vault credentials.

The vault credentials were the lever. The exceptions agent's role granted it read access to credentials for nineteen carriers, because exceptions could arise from any of those carriers and the agent needed to query each one. The attacker now held credentials for nineteen carriers' APIs. Within an hour, the attacker had pulled the customer-shipment history for every shipment those carriers had processed in the last quarter. Within a day, the attacker had begun creating fraudulent return labels using stolen credentials, with the carriers shipping high-value items to drop addresses the attacker controlled.

The post-mortem identified the deserialization flaw as the proximate cause and patched it. The deeper finding was that the blast radius of any single agent compromise was the union of every secret that agent could read, regardless of whether the agent actually used that secret in the moments before the compromise. The exceptions agent had read access to nineteen carriers because it might need any of them. At the moment of compromise, it was actively using one. The other eighteen credentials were sitting available, scoped by the role, indistinguishable from the one in active use. The attacker took all nineteen.

The team's first instinct was to tighten the role. Reduce the exceptions agent's access from nineteen carriers to five. Move the other fourteen carriers to a different agent. The exercise was painful and produced a worse system: agents now had to coordinate across carrier boundaries that did not match the operational reality, the access matrix became a labyrinth, and the team had to extend it every time a new carrier was added. The blast radius shrank from nineteen carriers to five, which was an improvement but not a fix. The fundamental problem persisted: at the moment of compromise, the agent held credentials for operations it was not currently performing.

The architecture that solves the problem is structurally different from role-based access. It treats the secret as a per-call resource rather than a per-role resource. The agent does not hold the secret; the agent holds a capability that allows it to request the secret for a specific operation. When the agent needs to call a carrier API, it presents the capability, the vault mints a credential scoped to that single call, the agent uses the credential, and the credential expires within seconds. At the moment of compromise, the attacker has the capability but not any actual secrets. The capability is useful only against the specific operation it authorizes, against the specific resource it names, within the time window it permits.

The Shared-Vault Failure Mode In Detail

Before describing the replacement, it helps to enumerate why the shared-vault model fails specifically in multi-agent environments. Some of the failures are familiar from human-centric systems. Some are unique to agents.

The first failure is blast-radius accumulation. Every secret an agent can read is part of the blast radius of any compromise of that agent. Role-based access controls define the blast radius statically. The blast radius is the same whether the agent is currently using one secret or all of them. In agent systems, the blast radius is much larger than in human systems because agents persist longer than human sessions and are configured to access broader sets of resources to reduce operational friction. A human admin might have access to every production database in principle, but in practice they hold a session that touches one database at a time. An agent holds standing access to its full set, indefinitely.

The second failure is credential lifetime. Vault-issued credentials are typically long-lived to reduce the operational burden of rotation. A typical pattern is a credential that lasts twenty-four hours, with the agent process re-fetching it from the vault when it expires. The rotation cadence reflects what the operations team can sustain, not what the security model requires. An attacker who obtains a credential at hour zero has up to twenty-three hours to use it before rotation forces a refresh. Even short-lived credentials, in the fifteen-minute range, give the attacker enough window to perform many operations.

The third failure is the decoupling of authorization from use. The role-based model decides whether the agent can read a secret. It does not decide whether the agent should use the secret in any particular call. The use decision is left to the agent code, which makes it implicitly. An agent that has read access to a credential can use the credential whenever the agent's logic decides to use it. A compromised agent uses the credential whenever the attacker's logic decides to use it. The vault has no way to distinguish.

The fourth failure is the audit gap. Vault audit logs typically record reads of the secret from the vault. They do not record uses of the credential against the downstream service. A compromised agent that fetched a credential six hours ago and is using it now produces no entry in the vault audit log for the current use. The downstream service produces an entry, but the entry attributes the call to the agent, not to the attacker, and the entry contains no reference to the vault read that authorized it. Reconstructing the chain from compromise to use takes hours of correlation work across multiple log streams.

The fifth failure is the schema rigidity. Role-based access requires every relationship between agent and secret to be expressed in advance. A new agent that needs access to existing secrets requires a role update. A new secret that should be visible to existing agents requires a role update. The role updates are reviewed manually, batched, and deployed slowly. The pace of role updates becomes a constraint on agent velocity. Teams respond by making roles broader, which increases blast radius further.

Each of these failures is fixable individually. The shared-vault model can be patched with shorter credential lifetimes, with downstream attribution, with finer-grained roles. The patches help. They do not change the structural property that the agent holds standing access to a set of secrets at the moment of compromise. The architecture below changes that property.

Architecture: Per-Agent Vaults With Capability Scopes

The replacement architecture has three components. Each agent has its own vault, which no other agent can read. Every secret in the vault is constrained by a capability scope that names the specific operation the secret authorizes. The vault mints the actual credential just in time for the call that uses it.

The per-agent vault is the first component. Instead of a single vault holding credentials for all agents, each agent has its own vault. The vault contains only the credentials the agent might need. The vault's access policy is simple: only this specific agent identity can read from this specific vault. The simplicity matters because complexity in access policies is where mistakes hide. Per-agent vaults eliminate the access matrix entirely. There is no matrix to mis-configure.

The per-agent vault solves the cross-agent blast-radius problem. A compromise of one agent gives the attacker access to one vault, not the union of all vaults. If the agent needs credentials for nineteen carriers, the agent's vault has nineteen credentials. If the agent needs credentials for one carrier, the vault has one. The decision about which credentials to provision in each vault is made at the time the agent is configured, not in a central matrix that has to be maintained for every agent. The decision is local to the agent.

The capability scope is the second component. Each credential in the vault is associated with a scope that names what the credential is allowed to do. The scope is not the credential itself; it is metadata that the vault uses when it mints the credential. The scope might say: this credential is for the rate-quote API at carrier X, valid for read operations only, valid for at most one minute, valid for at most one call. The vault enforces the scope when it produces the credential. The credential, once minted, carries the scope as a constraint that the downstream service can verify.

The scope is the property that addresses the implicit-use problem. The agent does not get to decide what to do with the credential; the credential's scope decides for it. If the agent needs to make a different kind of call against the same carrier, the agent has to request a different credential with a different scope. Each scope is a separate authorization decision that the vault records.

The just-in-time minting is the third component. The vault does not pre-mint credentials. The credential is created at the moment the agent requests it for a specific call. The credential has a short lifetime, typically seconds to minutes, sized to cover the call's expected duration with a small margin. After the lifetime expires, the credential is unusable. If the agent needs to make a second call, it requests a second credential.

The just-in-time pattern solves the credential-lifetime problem. At the moment of compromise, the attacker holds whichever credentials the agent had requested in the last few seconds. The attacker does not hold standing access to the vault's contents because the vault holds metadata, not credentials. The attacker would have to convince the vault to mint new credentials, which requires presenting the capability scope and waiting for the vault's response. Each minting attempt is logged. The attacker's activity is visible in real time.

The three components together produce a system where the blast radius of an agent compromise is bounded by the credentials the agent has actively minted in the recent past, not by the credentials the agent could potentially access. The bound is much tighter than the role-based model can achieve.

Capability Scope Design

The quality of the architecture depends on the quality of the capability scopes. A scope that is too broad reintroduces the original problem. A scope that is too narrow makes the system unusable because the agent has to request a fresh credential for every minor variation in operation.

The useful structure of a capability scope has six dimensions. The first is the resource: which specific endpoint, database, or external service the credential authorizes. The resource should be named at the highest precision the downstream service supports. A specific account, table, or repository, not a wildcard.

The second is the operation: which specific actions the credential authorizes against the resource. Read versus write versus delete. List versus get. The operation should be named at the verb level, matching the downstream service's authorization model. Many services support coarse roles like read-only or admin. The capability scope should not use those roles directly. It should name the specific operations within the role that the agent actually needs.

The third is the time bound: how long the credential is valid. The bound should be sized to the call's expected duration plus a margin for retries. Typical values are between one second and one minute. Longer bounds are appropriate for long-running operations like file uploads. Shorter bounds reduce blast radius. The bound should never default to the maximum the downstream service supports.

The fourth is the use bound: how many times the credential can be used. For most calls, the use bound is one. The credential is for this call and no other. For batch operations, the use bound might be the batch size. For streaming operations, the use bound might be open with a time bound that closes the stream. The use bound is the property that prevents an attacker from replaying a credential many times within its lifetime.

The fifth is the parameter constraint: which arguments the call may contain. A read credential might be constrained to a specific record. A write credential might be constrained to specific fields. The parameter constraint requires the downstream service to verify the credential against the call's actual parameters, which not all services support natively. Where supported, the constraint dramatically reduces what an attacker can do with a stolen credential.

The sixth is the provenance binding: which agent and which call the credential is bound to. The credential includes the requesting agent's identity and a unique identifier for the call. The downstream service can use the binding to detect cases where a credential intended for one call is being used for another. The binding also produces clean audit attribution: the downstream log entry references the originating call, which references the agent, which references the user task that initiated the chain.

A scope that includes all six dimensions is verbose to specify. Most teams build scope templates that capture the common patterns, then parameterize the specific values per call. The templates become part of the agent's configuration. New scope templates are added as new operations become necessary. The templates are reviewed by the security team. The per-call parameterization is automatic.

Just-In-Time Minting Implementation

The minting flow has to be fast because every call now includes a vault round-trip. The acceptable latency budget for the minting is around five to ten milliseconds at the ninety-ninth percentile. Faster is better. Slower starts to be visible to users.

The minting flow has four steps. The agent constructs a credential request that names the scope template, the parameter values, and any binding information. The request is signed with the agent's identity key. The vault receives the request, validates the signature, looks up the scope template, applies the parameters, and decides whether the resulting scope is permitted by the agent's policy. If permitted, the vault produces the credential and returns it to the agent.

The credential itself can take several forms depending on the downstream service. For services that support short-lived JWT-based authentication, the credential is a JWT with the scope encoded as claims. The downstream service verifies the JWT signature against the vault's public key and enforces the scope. For services that require static credentials, the vault either holds a long-lived parent credential and uses it to call the service's own credential-minting endpoint, or it brokers the call through a proxy that enforces the scope. Both patterns work. The JWT pattern is faster and more secure when the service supports it.

The vault's policy engine has to support per-agent policies that bound which scopes the agent can request. The policy is the analog of the role in the old model, but it operates on scope requests rather than on standing access. The policy can include cumulative bounds: the agent can request at most this many credentials per minute, this many credentials of this type per day, this many credentials against this resource per hour. The bounds are the property that catches a compromised agent that is requesting credentials at unusual volume.

The vault's audit log records every credential request and every minting decision. The records include the scope, the parameters, the policy version, the decision outcome, and the path through the policy that produced the decision. The records are tamper-evident and queryable. The audit log is the property that lets the operator reconstruct, after a compromise, exactly what credentials were minted and what operations they could have authorized. The reconstruction is direct, not inferred from downstream logs.

The vault has to be highly available because every call now depends on it. The standard pattern is to deploy the vault as a highly available cluster with replication, with the agent runtime caching minting decisions for short windows to absorb transient unavailability. The cache is a tradeoff: longer caches improve resilience but reduce the effectiveness of the cumulative bounds. The right cache duration depends on the agent's operating envelope and is itself a policy decision.

Rotation, Compromise Response, And Continuous Operation

A per-agent vault with just-in-time minting changes the operational dynamics of secret management. The rotation problem becomes simpler. Compromise response becomes faster. Continuous operation becomes more reliable.

Rotation in the old model required coordinating across every agent that held the secret. The rotation had to happen during a maintenance window, with all the agents updated simultaneously to avoid the window where some agents had the old credential and some had the new. The coordination was painful, which is why teams rotated infrequently, which is why credentials lived for months.

Rotation in the new model is local. The vault rotates the parent credential or the scope-issuing key. The next minting cycle uses the new key. Existing minted credentials continue to work for their lifetimes, then expire. There is no maintenance window because there is no coordination point. Rotation can happen daily, hourly, or on every minting if the operational team chooses.

Compromise response in the old model required revoking the credentials the compromised agent held, then waiting for the downstream services to propagate the revocation, then verifying that the revocation took effect. The window between compromise detection and effective revocation could be minutes to hours, depending on the downstream services' caching behavior. During the window, the attacker continued to operate.

Compromise response in the new model is faster. The vault can revoke the agent's policy with a single update. After the update, no new credentials will be minted. Credentials already minted will expire on their normal lifetimes, which are seconds to minutes. The attacker's effective window closes at the lifetime of the last credential the agent minted before the revocation, which is a known, bounded value. The downstream services do not need to participate in the revocation because the credentials carry their own expiration.

Continuous operation in the new model is more reliable because the failure modes are smaller. In the old model, a vault outage took down every agent that needed credentials, because the agents could not refresh expired credentials. In the new model, the agents request credentials per call, so a vault outage causes per-call failures rather than agent-wide failures. The agent runtime can implement per-call retry with backoff. Operators see the failure rate rise on the call latency dashboards rather than seeing every agent collapse simultaneously.

Named Artifact: The Secrets Isolation Architecture

The artifact below is a reference architecture that condenses the principles into a single deployable design. It has three layers: the per-agent vault layer, the capability scope layer, and the just-in-time minting layer.

The per-agent vault layer consists of one vault instance per agent identity. Each vault instance is a logical partition that may share underlying infrastructure with other vault instances but enforces an access policy that admits only one agent identity. The vault instance holds the metadata for the credentials the agent is permitted to mint, the scope templates that define what the credentials can authorize, and the per-agent policy that bounds which scopes can be requested.

The capability scope layer consists of the scope templates and the policy engine that validates scope requests against the per-agent policy. Scope templates are versioned and reviewed by the security team. Templates are parameterized at request time with the specific resource, time bound, use bound, and parameter constraints for the call. The policy engine evaluates each request against the per-agent policy, the global cumulative bounds, and the specific scope template's constraints.

The just-in-time minting layer consists of the minting service that produces the actual credentials and the credential-format adapters that match the downstream services' authentication requirements. The minting service holds the parent credentials or signing keys necessary to produce the downstream-compatible credentials. The adapters convert the abstract scope into the concrete credential format: a JWT for services that accept JWTs, a STS-issued temporary credential for AWS, a database role with limited permissions for databases that support per-session roles.

The three layers communicate through internal APIs that are themselves authenticated and audited. The minting service writes every minting decision to the audit log. The audit log is queryable by agent identity, scope template, time range, and decision outcome. Operators can produce a full inventory of minted credentials for any window, alongside the policy version that authorized them.

The architecture supports incremental deployment. An organization with an existing shared vault can introduce per-agent vaults for new agents while leaving existing agents on the shared vault. The migration runs agent by agent. Each migrated agent operates in the new model. The shared vault shrinks as agents migrate. The migration completes when the shared vault holds no production-relevant credentials.

Per-Agent Vault Provisioning And Lifecycle

The per-agent vault model adds a lifecycle dimension that the shared vault did not have. Vaults need to be provisioned when agents are created. Vaults need to be retired when agents are decommissioned. Vault contents need to be updated as the agent's capability needs evolve. The lifecycle has to be automated because manual management at the per-agent level does not scale.

Provisioning happens at agent registration. The agent's behavioral pact specifies the capabilities the agent will need. The provisioning logic translates the pact into the corresponding scope templates and seeds the vault with the metadata for those scopes. The translation is mechanical because the pact's capability declarations map cleanly to the scope template format. New scope templates can be added by extending the platform's library; the templates apply to any agent whose pact references them.

The per-agent policy is generated as part of provisioning. The policy bounds which scopes the agent can request, the cumulative volume bounds, and any temporal constraints. The generation pulls from the pact's stated operational envelope. An agent declared to operate at low volume gets tight cumulative bounds. An agent declared to operate at high volume gets looser bounds. The bounds can be tuned post-provisioning as the agent's actual behavior is observed.

Updates happen as the agent's needs evolve. A new capability that the agent requires triggers a pact amendment, which propagates to the per-agent vault as a scope template addition. The amendment goes through review because pact changes are change-controlled. The per-agent policy is regenerated to reflect the amended pact. The regeneration is atomic and reversible.

Retirement happens at agent decommissioning. The vault is marked inactive, which prevents new minting. Existing minted credentials continue to work for their lifetimes, then expire. After a retention period, the vault contents are deleted. The retention period covers the audit window for any operations the agent performed before retirement. The deletion is verified through cryptographic shredding of the underlying secrets.

The lifecycle integrates with the agent registration system, the pact management system, and the audit substrate. Each system contributes part of the picture. The integration is the property that makes the per-agent model operationally sustainable. Without integration, the operations team would be managing the lifecycle manually, which would produce drift and stale state.

Counter-Argument: The Operational Burden Of Per-Agent Vaults

The natural objection is that per-agent vaults multiply operational complexity. A platform with a hundred agents now has a hundred vaults. The provisioning, the policy management, the monitoring, and the cost all multiply. The operations team is already stretched. The new architecture asks them to manage a hundred objects where they used to manage one.

The objection has merit but misreads the cost structure. The cost of managing a vault is dominated by the policy complexity, not by the count. A single shared vault with a hundred agents has a complex access matrix that is harder to maintain than a hundred per-agent vaults each with a simple agent-bound policy. The matrix has to be reviewed for every change. The per-agent policies are independent. A change to one agent's policy does not require reviewing the others.

The provisioning concern is real but tractable. Per-agent vaults should be provisioned through automation, not through manual operator action. The agent registration flow creates the vault as part of the registration. The vault inherits scope templates from a library that the security team maintains. The per-agent policy is generated from the agent's declared capabilities. The operator's role is to review the generated policy, not to author it from scratch.

The monitoring concern is also tractable. The per-agent vaults emit a uniform telemetry format. The monitoring dashboard aggregates across vaults rather than monitoring each individually. The aggregation surfaces the relevant signals: minting volume per agent, scope distribution per agent, policy denials per agent, latency at each layer. Operators see the overall health of the secrets infrastructure as a single view, with the ability to drill into any agent that triggers an alert.

The cost concern depends on the underlying vault implementation. A per-agent vault that requires its own dedicated infrastructure is expensive. A per-agent vault that is a logical partition on shared infrastructure is cheap. Modern vault implementations support the partitioning natively. The marginal cost per agent is small.

The operational burden, when measured honestly, is comparable to the shared vault. The properties that change are the blast radius and the response time, both of which improve substantially. The operations team trades complexity in the access matrix for complexity in the per-agent policy. The trade is favorable because per-agent policy is easier to reason about than a global matrix.

Vault Telemetry And Anomaly Detection

The per-agent vault model produces telemetry that the shared vault model could not. Every agent has its own minting pattern. Patterns can be observed, baselined, and monitored for deviations. The telemetry becomes an early warning system for compromise that the shared vault could not provide.

The baseline for an agent emerges from the first few weeks of operation. The agent mints a characteristic mix of capability types, at characteristic volumes, at characteristic times. The baseline captures the mix, the volumes, and the temporal pattern. New baselines are computed weekly to track normal evolution.

Deviations from the baseline become alerts. An agent that suddenly mints capabilities of a type it has never minted before triggers an alert. An agent that mints at twice its usual volume triggers an alert. An agent that mints at hours when it normally is idle triggers an alert. Each alert is a candidate compromise indicator. Most alerts are false positives, reflecting legitimate changes in the agent's task mix. The investigation cost per alert is low because the audit log makes the relevant context accessible quickly.

The alerts feed into the platform's incident response workflow. A confirmed deviation triggers a graduated response: increased scrutiny on the agent's subsequent calls, requesting reauthentication if the agent is interactive, ultimately revoking the agent's policy if the deviation cannot be explained. The response is automated for the early stages and escalates to human review for the later stages.

The pattern works because the baseline is per-agent. A shared vault model would have to baseline against the aggregate behavior of all agents, which is so heterogeneous that anomalies are hard to distinguish from normal variation. Per-agent baselines have much tighter distributions, which makes the anomaly detection more sensitive without producing more false positives.

The telemetry also feeds longer-term analyses. Trends in minting volume across the agent fleet indicate platform growth. Trends in scope distribution indicate how agent capabilities are evolving. Trends in denial rates indicate whether policies are appropriately scoped. Each trend informs platform planning and policy evolution.

What Armalo Does

Armalo provides per-agent secrets isolation as part of the zero-trust runtime. Every agent registered on Armalo receives its own logical vault that no other agent can read. The vault is provisioned automatically as part of agent registration. Scope templates are inherited from Armalo's library and can be customized per agent. The per-agent policy is generated from the agent's behavioral pact and is reviewable through the agent dashboard.

Armalo's minting service supports JWT-based credentials, AWS STS-style temporary credentials, and proxy-mediated calls for services that do not support short-lived credentials natively. The minting decisions are recorded in the audit substrate alongside other authority decisions, queryable through the trust oracle. The per-agent policy includes cumulative bounds that catch unusual minting volume and feed into the agent's composite score.

The sandbox modes Armalo supports work in concert with the secrets isolation. An agent running in process isolation, container isolation, or microVM isolation has its credentials minted just in time and bounded by lifetime. A compromise of the sandbox bounds the attacker to the credentials the agent has actively minted in the recent past. The combination of sandbox isolation and secrets isolation produces a blast radius that is much smaller than either property alone could achieve.

Pact compliance includes a secrets-discipline dimension that reflects how cleanly the agent operates within the per-agent vault model. Agents that request credentials at appropriate scope, that release them promptly, and that maintain low denial rates score higher. The score feeds the trust oracle and informs counterparty decisions in the agent marketplace.

FAQ

Does just-in-time minting work for batch operations that need to authenticate many calls in sequence? Yes, with the right scope design. A batch credential can have a use bound greater than one, sized to the batch. The credential remains valid for the batch's duration and then expires. The audit record covers the full batch. The pattern preserves the bounded blast radius: an attacker who steals the credential mid-batch can use it only for the remaining uses within the time bound.

What is the latency overhead of per-call minting? A well-implemented vault produces a credential in three to ten milliseconds at the ninety-ninth percentile. The overhead is below the noise floor of the LLM inference latency that drives the call decision. For calls that are themselves very fast, like in-memory cache lookups, the minting overhead becomes visible and may motivate batching.

Can the credentials be cached on the agent side to reduce minting volume? Caching is permissible within bounds. The cache duration must be much shorter than the credential lifetime, and the cache must be in memory only, never persisted. The pattern is most useful for credentials that authorize repeated reads against the same resource. Caching for credentials that authorize writes or for credentials with parameter constraints is risky and should be avoided.

How does this interact with on-premises systems that cannot support short-lived credentials? Through proxy-mediated calls. The agent calls a proxy that holds the long-lived credential and forwards the call to the on-premises system. The proxy enforces the scope. The architecture is similar to a service mesh's identity-based policies. The on-premises system sees a stable identity, and the agent never holds the actual credential.

What happens if the vault is compromised? A vault compromise is the catastrophic failure mode the architecture cannot prevent. The mitigations are the standard ones: hardware security modules for the signing keys, separation of duties for the operators, threshold cryptography for the most sensitive operations. The architecture limits the blast radius of agent compromises but accepts that vault compromise is a higher-tier failure that requires its own treatment.

How do you handle agent-to-agent communication that needs to share secrets? Through the same architecture. When agent A needs to pass a secret to agent B, A requests a credential scoped to a specific operation that B can perform. A passes the credential to B. B uses it for the specific operation. The credential is bound to the call, not transferable to other calls. The architecture preserves the property that B's compromise does not expose A's broader vault.

Does the architecture work for agents that hold long-lived OAuth tokens for user accounts? With modifications. OAuth tokens are issued by external authorities and are not minted by the vault. The vault can hold the tokens and enforce per-call scopes when the agent uses them, but the tokens themselves cannot be minted just in time unless the OAuth provider supports short-lived tokens or refresh patterns. The pattern is to use the vault as a guarded access layer that enforces capability scopes around the OAuth tokens, even though the tokens themselves are not under the vault's full control.

Bottom Line

The shared-vault model survived for a decade because human-operated systems did not stress its weaknesses. Humans do not request credentials at machine speed. Humans do not persist sessions across days. Human compromises produce identifiable behavioral changes that the operator notices. Agents have none of those properties. They request at machine speed, they persist indefinitely, and their behavioral changes after compromise are invisible against the baseline of normal agent activity. The shared vault becomes a liability sized to the union of every secret it holds.

The per-agent vault with capability scopes and just-in-time minting addresses each of the failure modes structurally. The blast radius shrinks from the union of every secret to the credentials minted in the recent past. The credential lifetime shrinks from hours to seconds. The use is bound to the call rather than to the role. The audit chain is direct rather than inferred. The rotation is local rather than coordinated. Compromise response is fast rather than slow.

The architecture costs more to build than the shared vault costs to maintain. The cost is paid back in the absence of the catastrophic compromise that the shared vault makes inevitable. The right time to migrate is now, with the second agent, while the access matrix is still simple enough to abandon cleanly. The right time is not after the compromise that draws the press attention.