Most teams deploying multi-agent pipelines spend time on orchestration, routing, and tool call design. Almost nobody thinks about what happens to credentials when one of those agents gets compromised.
The assumption is that because the agents are “internal,” they can share credentials. That assumption is expensive.
The Shared Credential Problem in Multi-Agent Systems
The typical setup looks like this: Agent A orchestrates Agent B and Agent C. All three read from the same environment variables. Same OPENAI_API_KEY. Same ANTHROPIC_API_KEY. Maybe the same internal service token.
This is convenient. It’s also a single point of failure that spans your entire pipeline.
If any agent in the chain gets compromised, the attacker inherits credentials that work across every other agent in the pipeline. The blast radius isn’t “the compromised agent.” It’s everything.
Here’s a concrete scenario. Your orchestrator delegates to a summarization agent. That agent reads a malicious document, gets prompt-injected, and exfiltrates the shared API key to an attacker-controlled endpoint. That key is the same key your orchestrator uses to call your internal APIs. Now the attacker has full pipeline access.
Prompt injection is the most obvious attack vector, but it’s not the only one. A compromised dependency in one agent’s environment, a rogue tool call that leaks environment variables, a supply chain attack on a library only one agent uses: any of these can expose credentials shared by all agents.
The problem compounds as pipelines get longer. A three-agent pipeline with shared credentials has three times the surface area for credential exposure. Add more agents, add more risk, all converging on the same set of keys.
You probably wouldn’t run your entire production backend under a single IAM role with full access to everything. But that’s effectively what shared credentials mean in a multi-agent pipeline.
What Credential Isolation Actually Means
Credential isolation means each agent operates with its own session-scoped token, valid only for the duration of its task, scoped only to the providers and keys it actually needs.
The core properties:
Session-scoped tokens. Each agent gets a token at startup. That token is tied to one session. When the session ends, the token expires. No residual access.
Provider scoping. A summarization agent that only calls OpenAI doesn’t need an Anthropic key. With isolation, it doesn’t get one. If that agent is compromised, the attacker gets a token valid for OpenAI, for the duration of that session. They don’t get the orchestrator’s Anthropic access. They don’t get any internal API keys.
Session independence. Compromising one session has no effect on others. The orchestrator’s session is completely separate from the summarization agent’s session. Lateral movement requires breaking each session independently.
Per-agent audit trail. Because each agent has its own token, every API call is attributed to the specific agent that made it. You can see exactly which agent called what, when, and with which token. That’s something you simply can’t get with shared credentials.
This isn’t a theoretical security property. It changes what an attacker can do with a compromised agent, and it changes what you can see when something goes wrong.
How to Set It Up With API Stronghold
api-stronghold-cli proxy start creates an independent proxy session per agent. Each session gets its own port, its own phantom token, its own TTL, and its own provider scope.
Here’s a three-agent setup:
# Orchestrator: needs Anthropic only
api-stronghold-cli proxy start --port 8900 --providers anthropic --ttl 3600
# Summarization agent: needs OpenAI only, shorter TTL
api-stronghold-cli proxy start --port 8901 --providers openai --ttl 900
# Data retrieval agent: scoped to specific key IDs only
api-stronghold-cli proxy start --port 8902 --keys uuid-1,uuid-2 --ttl 1800Each agent gets environment variables pointing at its own proxy port. The orchestrator sets ANTHROPIC_BASE_URL=http://localhost:8900. The summarization agent sets OPENAI_BASE_URL=http://localhost:8901. They never see each other’s tokens, and the proxy enforces the scope.
If the summarization agent is compromised, the attacker has a phantom token valid for 15 minutes on OpenAI only. That’s the ceiling. They can’t reach the orchestrator’s Anthropic session. They can’t reach the key IDs scoped to the data retrieval agent.
TTL is intentional. Shorter-lived agents get shorter TTLs. A summarization task that runs for two minutes doesn’t need a token valid for an hour. Set the TTL to match the expected task duration, and residual access becomes minimal even if something goes wrong.
The phantom token pattern handles the actual credential. Your real API keys never touch the agent environment. The proxy holds them, and the agent gets a scoped token that the proxy maps to the real key for matching requests. For a deeper look at how that works, see our phantom tokens post.
The Audit Trail Benefit
Shared credentials produce ambiguous logs. You see a spike in OpenAI API usage. You have no idea which agent caused it, which task triggered it, or whether it was expected behavior.
Per-session tokens fix this. Every call through a session is logged with the session ID. You can query by session to see exactly what an agent called, in what order, at what time.
That matters in three scenarios:
Debugging agent behavior. When an agent produces unexpected output, the audit trail shows what it called and in what sequence. You’re not guessing at which LLM call was responsible for the bad output.
Cost attribution. In a pipeline where multiple agents call multiple providers, knowing which agent drove which costs is only possible if each agent has its own session. Aggregate logs tell you what was spent; per-session logs tell you where to look.
Incident response. If something was exfiltrated or misused, the session log shows you exactly what happened. Shared credential logs leave you guessing.
Per-session analytics are batched to the API Stronghold server so you can query them after the fact. The data persists beyond the session lifetime, which means you can audit historical agent behavior even after the tokens have expired.
Narrowing Scope Mid-Session With Sub-Tokens
Separate sessions work well for automated pipelines where each agent has a defined role. Interactive sessions are different. You might be running a single ChatGPT or Claude session and switching between tasks that need different key access. Stopping and restarting the proxy every time you change tasks is friction most people won’t tolerate.
Sub-tokens solve this. From an active parent session, you can issue a derived token with equal or narrower permissions, without restarting the proxy.
# Start a broad session for the overall chat
api-stronghold-cli proxy start --port 8900 --providers openai,anthropic --ttl 7200
# Later, issue a tighter sub-token for a sensitive task
api-stronghold-cli proxy sub-token \
--parent <session-id> \
--session-token <parent-token> \
--providers openai \
--ttl 300The sub-token is bound by two hard rules: it can only request a subset of the parent’s providers and key IDs (no escalation), and its TTL is clamped to whatever time remains on the parent session. A sub-token can’t outlive its parent.
Revocation cascades. If you revoke the parent session, all sub-tokens issued from it are revoked immediately. Each sub-token appears in the audit trail as a child of the parent session, so you can trace exactly what happened at each scope level.
This covers the interactive use case without giving up the security property. The broad session exists for the full chat context. Sensitive tasks get a narrow sub-token scoped to exactly the keys they need, for exactly as long as they need them.
Applying This to MCP Pipelines
The same pattern applies when your agents are MCP servers.
Each MCP server gets its own session-scoped token at startup. The token expires when the MCP session ends. No long-lived keys sitting in MCP server environment variables, waiting to be read by a compromised tool or a rogue extension.
If an MCP server is compromised mid-session, the token it holds is time-limited and provider-scoped. The attacker’s window closes when the session ends. They can’t pivot to other MCP servers using the same token because each server has its own.
This is a meaningful improvement over the common pattern of giving all MCP servers access to the same .env file. That pattern means a compromised MCP server can read every key in the file, not just the ones it needs.
For background on the proxy mechanics that make this work, the phantom tokens post covers how tokens are issued, scoped, and mapped to real credentials at the proxy layer.
One Session Per Agent
The pattern is straightforward: one session per agent, scoped to what that agent needs, for only as long as it needs it.
If a compromised agent in your pipeline can reach everything the orchestrator can reach, you don’t have isolation. You have a shared blast radius with extra steps.
Credential isolation changes the security model. A compromised agent becomes a contained incident instead of a full pipeline breach. The attacker’s access is limited to one provider, one set of keys, for the duration of one session.
API Stronghold makes this the default. Start free at https://www.apistronghold.com.