Quick answer: Multi-agent systems introduce a credential problem that doesn't exist when you have a single agent.
With one agent, the risk model is manageable: one identity, one access policy, one audit trail. If something goes wrong, you know which agent was involved and you can revoke it cleanly.
With an orchestrator spawning sub-agents — or a pipeline where one agent calls another — the question of "who has access to what" gets complicated fast. And most teams answer it the easiest way: they share credentials across the chain. One Stripe key. One GitHub token. Inherited by everyone.
This works fine until it doesn't.
Quick answer
In a multi-agent system, every agent that shares a credential set amplifies your blast radius. A compromised or misbehaving sub-agent has the same permissions as the orchestrator above it — and every other agent drawing from the same credential pool.
The right model: each agent in the chain gets its own scoped identity. The orchestrator passes task context, not credentials. A sub-agent that needs elevated access requests it through an approval step rather than inheriting it automatically. This way, revoking one agent cuts only that agent — nothing else in the pipeline is touched.
How most teams start
The default pattern looks like this:
Orchestrator agent (has STRIPE_KEY, GITHUB_TOKEN, VERCEL_TOKEN)
└── spawns Sub-agent A
passes environment including STRIPE_KEY
└── spawns Sub-agent B
passes environment including STRIPE_KEY
└── calls Sub-agent C via API
passes STRIPE_KEY in request body
Every subprocess inherits the full environment. Every spawned agent has every credential. The orchestrator's key is passed down because it's the easy way to get each sub-agent to work.
This is the same pattern that creates problems in traditional systems — shared service accounts, inherited CI secrets — but it's harder to spot in multi-agent setups because the "agents" look like autonomous units rather than tightly coupled subprocesses.
Why this compounds at scale
Five agents all holding your Stripe secret key is not just a single point of failure — it's five separate attack vectors, five places where a prompt injection could trigger an unexpected API call, five agents that need to be considered when you rotate after a compromise.
The blast radius math is straightforward:
- One shared key, five agents: compromising any one agent gives full Stripe access — customers, payment methods, refunds, webhooks, all of it
- Five per-agent scoped credentials: compromising one agent gives access to what that agent was allowed — read-only webhook configuration, or payment intent creation, or subscription lookup — nothing else
The second model doesn't eliminate the risk of a compromised agent. But it ensures the damage is contained to what that specific agent was doing, rather than propagating across the entire pipeline.
A sub-agent working on log analysis doesn't need Stripe access. An agent running a database query doesn't need GitHub write access. But if they're all spawned from an orchestrator with a full environment, they have it anyway.
The right model: task context, not credentials
The shift is conceptual before it's technical: the orchestrator's job is to pass what to do, not the keys to do it with.
Instead of:
orchestrator → sub-agent: "Query Stripe for customer ID 123" + STRIPE_KEY
The pattern becomes:
orchestrator → sub-agent: "Query Stripe for customer ID 123"
sub-agent → credential broker: get_credential("stripe")
broker: checks sub-agent's access policy, returns scoped credential if allowed
The sub-agent's identity is registered separately. Its access policy defines which services it can reach. The credential broker enforces that policy at runtime, logs every retrieval, and issues credentials on demand rather than distributing them up front.
This decouples authorization from orchestration. The orchestrator doesn't need to know what credentials each sub-agent requires — it just sends tasks. Each agent is responsible for its own credential retrieval within its pre-defined scope.
How approval gates fit into an agent pipeline
In a single-agent setup, an approval gate is simple: the agent proposes an action, a human approves or rejects it before execution.
In a multi-agent pipeline, approval gates serve a second purpose: they prevent privilege escalation within the chain.
Consider an orchestrator that has broad access but spawns sub-agents with narrow scopes. If a sub-agent could directly call the orchestrator to "borrow" elevated credentials for a task, the scoping is theater — any sub-agent can escalate whenever it needs more access.
The right model: if a sub-agent needs access it doesn't have, it requests that access through an approval step. A human (or a policy engine with a human in the loop for sensitive actions) reviews the request and either grants it as a time-limited elevation or rejects it. The sub-agent never inherits permissions from the orchestrator automatically.
Worked example: a three-agent pipeline
Consider a pipeline with a planner agent, an executor agent, and a reviewer agent.
Planner agent
- Task: receive user intent, break it into steps, assign to executor
- Credentials it needs: none — it works with task descriptions, not external APIs
- Access policy: empty. The planner never retrieves a credential.
Executor agent
- Task: carry out assigned steps against external services
- Credentials it needs: Stripe (write: payment intents only), GitHub (write: pull requests to a specific repo only)
- Access policy: scoped to those two surfaces. GitHub read is included; refund capabilities are not.
Reviewer agent
- Task: review executor output, flag anomalies, approve before the result is returned
- Credentials it needs: Stripe (read: payment intent status only), GitHub (read: pull request status only)
- Access policy: read-only versions of the executor's scopes.
The orchestrator that coordinates these three agents holds no credentials of its own for passing down. Each agent retrieves what it needs, as it needs it, within its pre-registered policy. The audit log records three separate identities — planner, executor, reviewer — each with its own access record.
If the executor behaves unexpectedly, you revoke the executor's profile. The planner and reviewer continue operating. The underlying Stripe and GitHub keys are untouched. You're not doing an emergency rotation across every service your pipeline touches.
What this looks like in practice
Setting up this model requires three things:
1. A named identity per agent, not per pipeline. Each agent in the chain gets registered separately with its own access profile. "executor-stripe-github" is more useful than "pipeline-worker" — the name should describe what the agent does and what it touches.
2. A credential broker that enforces policy at runtime. The broker receives credential requests from agents, checks the requesting agent's policy, and either issues the credential or returns a structured denial. The orchestrator is not involved in this exchange.
3. Explicit approval paths for elevation. If a sub-agent needs broader access than its baseline policy allows, that request surfaces to a human (or a policy engine) rather than being handled automatically. A sub-agent cannot self-authorize an elevation.
This is more setup than a shared environment variable, and less convenient when you're moving fast on a prototype. It pays for itself the first time you need to pull one agent's access without touching anything else in the pipeline.
Debugging credential failures in agent pipelines
When a multi-agent pipeline fails due to a credential issue, the error is usually visible somewhere in the chain but the root cause can be hard to trace. Some patterns that help:
Log the requesting agent identity at every broker call. When a sub-agent makes a credential request, the broker should record which sub-agent made it — not just the pipeline name or orchestrator identity. Without per-sub-agent logging, "the pipeline failed" is the most specific diagnosis you can make.
Test credential scope before deploying the full pipeline. Before wiring up the orchestrator, run each sub-agent in isolation with its intended access profile. Verify it can do what it's supposed to do and gets a permission denied on what it shouldn't. Credential scope bugs caught at the sub-agent level are much easier to fix than those discovered mid-pipeline.
Treat permission denied as a structured error, not an exception. Sub-agents should return a clear, machine-readable error when the broker denies a request — "insufficient scope for stripe.refunds.create" — rather than trying alternative paths or escalating to a broader credential. The orchestrator can then decide whether to surface the error to the user or request an approval elevation.
Name profiles to reflect pipeline topology. Use names like pipeline-executor, pipeline-reviewer, pipeline-planner. When a permission denied appears in the log, the profile name tells you immediately which stage of the chain hit the scope boundary.
Further reading
- IAM for AI agents: how it differs from human IAM — the access model concepts that underpin per-agent scoping
- AI agent permissions: how to set granular access for every agent — the three dimensions of agent permissions and how to apply them
- Least privilege for AI agents — why full access is the default failure mode and how to fix it
- n8n AI agent credentials — applying the per-agent credential model to n8n workflows specifically
- Gazebo agent setup — register separate agent identities for each node in your pipeline