When several AI agents run on one API key, service account or OAuth token, nobody can say which agent did what, and one compromised agent hands over the access of all of them. Sharing is the default in many agent builds: a single key in an environment variable, one "agent-svc" account for every workflow, or an MCP server that forwards the same upstream token for every caller. This guide explains what counts as a shared agent credential, the concrete risks to attribution, blast radius and revocation, the per-agent identity patterns that platforms now support, and a phased plan to split shared credentials without breaking production. It goes deeper on one problem than the AI Agent Credential Lifecycle and Rotation Guide, which covers issuance, rotation and retirement in general. It is written for platform engineers, IAM and NHI teams, and security architects running agents in production.
Key takeaways
- Sharing destroys attribution. If three agents authenticate with the same credential, every log line looks like one actor, and an incident responder cannot separate a prompt-injected agent from a healthy one.
- Blast radius is the union of everyone's access. OWASP's NHI9:2025 NHI Reuse risk states it plainly: one compromised component holding shared credentials lets an attacker reach the other parts of the system.
- Revocation becomes an outage. You cannot revoke a shared key for one misbehaving agent without stopping all the others, so teams delay revocation, which is exactly what an attacker needs.
- Per-agent identity is now practical. Microsoft Entra Agent ID gives each agent instance its own identity from a blueprint, AWS AgentCore's token vault scopes stored credentials to one agent and user combination, and GitHub App installation tokens can be narrowed per repository and expire after an hour.
- Delegation must be recorded, not hidden. When an agent acts for a user or another agent, use token exchange with an actor claim or a session attribute such as AWS SourceIdentity so the chain is visible in logs.
What counts as a shared agent credential
A credential is shared when more than one independently acting agent, agent instance or human can present it. The test is not whether the credential is stored in one place but whether the system that receives it can tell the callers apart.
| Pattern | Example | Why it counts as shared |
|---|---|---|
| One API key, many agents | A single LLM provider or SaaS API key in a shared .env or secret, read by every agent in a framework | The provider sees one caller; usage, abuse and data access cannot be split per agent |
| Generic service account | "svc-ai-agents" with database and ticketing permissions used by a triage agent, a reporting agent and a coding agent | Permissions accumulate to the needs of the most demanding agent |
| Token passthrough | An MCP server or tool gateway that forwards the caller's or its own upstream token unchanged to every downstream API | Downstream systems cannot tell which agent or user made the call; the MCP authorization specification forbids servers accepting or transiting tokens not issued for them |
| Instances of one agent sharing a secret | Fifty replicas of a support agent across regions, all with the same client secret | A leak from one replica compromises every replica; per-instance behaviour cannot be baselined |
| Human and agent on one identity | A developer tests with the agent's production token, or an agent runs on a person's personal access token | OWASP NHI10:2025 Human Use of NHI: human and automated activity become indistinguishable |
| Orchestrator credential lent to sub-agents | A planner agent passes its own token to worker agents it spawns | Workers inherit the planner's full scope regardless of their task |
Group credentials are not new. NIST SP 800-53 Rev. 5 has a dedicated enhancement, AC-2(9) Restrictions on Use of Shared and Group Accounts, and IA-2(5) Individual Authentication with Group Authentication, which requires individuals to authenticate before a shared authenticator is used. Agents make the problem worse because they act autonomously, at machine speed, and can be steered by untrusted input.
Why agents end up sharing credentials
- Framework defaults: most agent frameworks read provider keys from environment variables, so every agent in a process gets the same key unless someone designs otherwise.
- Prototype debt: a proof of concept built with one admin token becomes the production deployment.
- Licence and quota pressure: SaaS platforms that charge per integration user push teams to reuse one account.
- Missing identity primitives: until recently many identity providers had no object type for an agent, so teams used an app registration or a service account and shared it.
- Tool gateways that pass tokens through: a gateway that simply forwards credentials is quicker to build than one that exchanges them.
- Multi-agent orchestration: sub-agents created at runtime need credentials immediately, and the easiest source is the parent.
The risks in practice
Attribution and forensics
Logs record the credential, not the intent. If a shared token deletes records, the audit trail cannot show which agent, which prompt or which user request caused it. NIST SP 800-53 AU-3 Content of Audit Records expects records to establish the source and the identity of the individuals or subjects associated with an event, and AU-10 Non-repudiation exists for actions where that link must hold. A shared agent credential fails both.
Blast radius
Each agent's exposure to untrusted input is a path to the shared credential. OWASP's Top 10 for LLM Applications 2025 lists, under LLM06 Excessive Agency, the case of an extension that accesses downstream systems with a generic high-privileged identity when it should act in the context of an individual user. Combine that with prompt injection in any one agent and the attacker inherits everything the shared identity can reach.
Privilege creep
A shared identity's permissions grow to the union of every agent's needs and rarely shrink, because nobody can prove which agent still needs which permission. This is OWASP NHI5:2025 Overprivileged NHI arriving by accumulation. See the Agent Permission Drift guide.
Revocation and rotation
Rotating a credential used by many agents needs a coordinated change across every consumer. Teams postpone it, so shared credentials also tend to be long-lived (OWASP NHI7:2025 Long-Lived Secrets). Emergency revocation of one compromised agent stops the rest.
Behavioural detection
Anomaly detection depends on a stable baseline per identity. A credential used by a nightly batch agent and an interactive assistant has no coherent baseline, so an attacker's activity hides in the noise.
Per-agent identity patterns
The fix is one identity per agent, and where the platform supports it, per agent instance, with credentials that are short-lived and scoped to the task. The platforms below document the building blocks. Product features change; check current documentation before you design on them.
| Building block | What it gives you | Documented detail |
|---|---|---|
| Microsoft Entra Agent ID agent identities | A distinct service principal per agent deployment, created from a shared blueprint | Agent identities hold no credentials of their own; the blueprint holds federated identity credentials, certificates or client secrets. Admins can apply Conditional Access to, disable, or revoke permissions for all agents of a blueprint at once. An optional sponsor names the accountable human. |
| AWS Bedrock AgentCore Identity token vault | Stored downstream OAuth tokens and API keys bound to one agent and user combination | The token vault ensures credentials can only be accessed by the agent and user combination that obtained them; agent access tokens carry both workload and user identity. |
| AWS STS SourceIdentity | A persistent, unchangeable caller label on a shared role session | Set at AssumeRole with sts:SetSourceIdentity, it cannot change during the session, survives role chaining and appears in CloudTrail under userIdentity.sessionContext.sourceIdentity; policies can require it with aws:SourceIdentity. |
| GitHub App installation access tokens | Per-task tokens narrower than the app | Tokens expire after one hour and can be limited to up to 500 named repositories and a subset of the app's permissions at creation. |
| MCP authorization | Tokens bound to one MCP server | Clients must send an RFC 8707 resource parameter naming the server; servers must validate that tokens were issued for them and must not accept or transit any other tokens. |
| OAuth 2.0 Token Exchange (RFC 8693) | Delegated tokens that name both parties | A subject_token for the party represented and an optional actor_token for the agent; the act claim records that delegation occurred and identifies the acting party, and nested act claims record a chain. |
For the identity models themselves, see the Cloud Agent Identity Services Compared (Entra, AgentCore, Google) and the OAuth Token Exchange and Delegation Guide.
Choosing the right split
Not every shared credential needs the same fix. Use the table to decide how far to go.
| Situation | Recommended approach | Trade-off |
|---|---|---|
| Agents with different purposes share one identity | Separate identity per agent type, each with its own least-privilege grants | More objects to govern; worth it in every case |
| Many replicas of one agent | Per-instance identity from a blueprint or template, or one identity per agent type plus a per-instance session label | Per-instance identity is cleaner; session labels are cheaper where the platform supports them |
| Agent acts for a signed-in user | Delegated token through token exchange, scoped to that user, with the agent named as actor | Requires an authorisation server that supports exchange; avoids a privileged generic identity |
| Downstream API only supports one static key | Put a gateway in front that holds the key and authenticates each agent separately, logging the agent ID per call | The gateway becomes a high-value component and must be hardened |
| SaaS licence limits on integration users | Separate users for high-risk agents (write or admin access) and a shared, read-only user for low-risk ones with per-call labels | Partial attribution only; document the residual risk |
| Orchestrator spawning sub-agents | Orchestrator requests a down-scoped token per sub-agent task rather than lending its own | Needs an exchange or minting service; prevents scope inheritance |
Small organisations: start with one identity per agent type and per environment, short-lived tokens, and a secrets manager. Per-instance identity can wait. Large organisations: standardise on a blueprint or template model, require an owner or sponsor per agent identity, and make "no shared agent credentials" a deployment gate. See the Agent Identity and Access Guide.
How to implement
- Inventory consumers per credential. For every agent-used key, token and service account, list which agents, instances, pipelines and humans present it. Source this from secrets manager access logs, cloud audit logs and code search for the secret's name. A credential with more than one consumer goes on the remediation list.
- Rank by impact. Prioritise credentials with write, delete, payment or admin rights, credentials reachable by agents that read untrusted content (email, web, tickets), and credentials also used by humans.
- Create target identities. One identity per agent type and environment, with an owner. Where available, create per-instance identities from a blueprint. Grant each only what its agent uses, based on observed activity, not the old shared grant.
- Shadow first. Issue the new credential to one agent while the shared one remains valid, and compare access denials and behaviour for at least one full business cycle. Treat denials as permission gaps to review, not to auto-grant.
- Cut over one consumer at a time. Move each agent to its own credential, then remove that agent's access to the shared secret in the secrets manager so it cannot fall back.
- Fix gateways and MCP servers. Replace token passthrough with audience-bound tokens or token exchange, and make the gateway log the calling agent's identity on every downstream call.
- Revoke the shared credential. When access logs show no remaining consumers for an agreed period, revoke it. Keep the old credential disabled rather than deleted for a short rollback window if the platform allows it, then delete it.
- Gate new deployments. Add a pipeline check that rejects agent manifests or infrastructure code referencing a credential already bound to another agent.
Rollback: because the shared credential stays valid until step 7, any agent that fails on its new identity can be pointed back to it within minutes. Record every rollback as a defect against the new identity's permissions.
Detection and measurement
What to log and watch
- Consumer count per credential: distinct workloads, hosts or IP ranges presenting each credential, from secrets manager and identity provider logs. More than one where one is expected is an alert.
- Human use of agent credentials: interactive sign-ins, browser user agents or developer workstation addresses on agent identities (OWASP NHI10).
- Missing attribution fields: CloudTrail events from agent roles without sourceIdentity, or gateway logs without an agent ID.
- Token audience mismatches: MCP servers and APIs rejecting tokens issued for another resource, which may indicate passthrough or token theft.
- Cross-agent anomalies: one agent identity suddenly using APIs that another agent type normally uses.
Metrics
| Metric | Target |
|---|---|
| Percentage of agent credentials with exactly one consuming agent | 100% for write or admin credentials |
| Number of agent identities without a named owner or sponsor | Zero |
| Percentage of agent actions in audit logs attributable to a single agent and, where delegated, a user | Above 95%, trending up |
| Median lifetime of agent access tokens | One hour or less where the platform supports it |
| Time to revoke one agent's access without affecting other agents | Under 15 minutes |
| Human sign-ins on agent identities per month | Zero |
For baselining technique, see the Service Account Behavioural Baselining Guide.
Framework mapping
| Requirement | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | OWASP |
|---|---|---|---|
| Restrict shared accounts | AC-2(9) Restrictions on Use of Shared and Group Accounts | PR.AA-01 | NHI9:2025 NHI Reuse |
| Authenticate the individual before the group credential | IA-2(5) Individual Authentication with Group Authentication | PR.AA-03 | NHI10:2025 Human Use of NHI |
| Uniquely identify services | IA-9 Service Identification and Authentication; IA-4 Identifier Management | PR.AA-01 | NHI4:2025 Insecure Authentication |
| Least privilege per agent | AC-6 Least Privilege | PR.AA-05 | NHI5:2025; LLM06:2025 Excessive Agency |
| Attributable audit records | AU-3 Content of Audit Records; AU-10 Non-repudiation | DE.CM-03 | None |
| Detect atypical use | AC-2(12) Account Monitoring for Atypical Usage | DE.AE-02 | None |
| Short-lived secrets | IA-5 Authenticator Management | PR.AA-01 | NHI7:2025 Long-Lived Secrets |
On the attacker side, a stolen shared agent token is used through ATT&CK T1550.001 Use Alternate Authentication Material: Application Access Token, and keys left in agent configuration fall under T1552.001 Unsecured Credentials: Credentials In Files.
Common failure patterns
- Splitting identities but keeping the shared grant: each new identity is given the old account's full permissions "to be safe", so blast radius is unchanged and only attribution improves.
- Per-agent identity, shared secret underneath: several agent identities authenticate with the same client secret or certificate. Revoking one secret still takes them all down.
- Gateway that logs itself, not the caller: the tool gateway authenticates agents separately but writes only its own identity downstream, so attribution stops at the gateway.
- Sub-agents inheriting the orchestrator token: a worker built to summarise a document can call every API the planner can.
- Developers debugging with production agent tokens: creates human use of NHI and often leaks the token into terminals, notebooks and chat.
- Revoking without a consumer map: a shared key is rotated during an incident, unknown agents fail, and the team restores the old key under pressure.
Lessons from incidents
Integration token stores show the shared-credential failure at scale. In the Salesloft Drift Breach 2025, one vendor environment held OAuth tokens for many customers' Salesforce and Google Workspace integrations; once that store was read, the attacker could act as every connected integration, and the advice that followed was to treat every token connected to the platform as compromised. Agent platforms that centralise downstream tokens carry the same risk, which is why per-agent, per-user binding in token vaults matters. The Snowflake Breach 2024 shows the companion lesson: static credentials that are never rotated stay useful to an attacker for years.
Practitioner checklist
- Build a consumer map for every credential an agent uses, and flag any with more than one consumer.
- Give every agent type its own identity per environment, with a named owner or sponsor.
- Use per-instance identities, or a per-instance session label such as SourceIdentity, for replicated agents.
- Replace token passthrough in MCP servers and gateways with audience-bound tokens or token exchange.
- Issue sub-agents down-scoped tokens instead of lending the orchestrator's credential.
- Block human sign-ins on agent identities and alert on any attempt.
- Shadow, cut over and then revoke shared credentials, keeping a short rollback window.
- Add a deployment gate that rejects a credential already bound to another agent.
- Report the six metrics above monthly to the owner of the agent platform.
Standards and references
- OWASP: Non-Human Identities Top 10 2025
- OWASP: Top 10 for LLM Applications 2025
- Model Context Protocol: Authorization specification
- IETF: RFC 8693 OAuth 2.0 Token Exchange
- Microsoft Learn: Agent identities in Microsoft Entra Agent ID
- AWS: Amazon Bedrock AgentCore Identity terminology
- AWS: Monitor and control actions taken with assumed roles (SourceIdentity)
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: AI Agent Credential Lifecycle and Rotation Guide · Agent Identity and Access Guide · Top 10 Agent Identity Controls · OAuth Token Exchange and Delegation Guide · Non-Human Identity (NHI) Guide