Scoped credentials for AI agents cut identity and privilege abuse

At a glance

What this is: This is a practitioner guide on giving AI agents their own credentials, with the core finding that borrowed sessions and shared keys create avoidable identity and privilege abuse.

Why it matters: It matters because IAM, PAM, and NHI teams now need to govern agents as separate actors, not as extensions of users or background automation.

👉 Read WorkOS's guide to scoped credentials for AI agents

Context

AI agent identity risk grows when an agent inherits a human session or a shared service account, because the credential then carries far more privilege than the task requires. In agentic apps, the control problem is not just authentication. It is who the agent is, what it may do, and whether each tool call is checked at the boundary.

The primary identity governance issue is blast radius. Once an agent can call multiple tools, access multiple resources, or act across tenants, conventional access assumptions start to fail. That shifts the work for IAM, IGA, and PAM teams from human login flows toward scoped machine identity, tool-level authorization, and auditability across the full delegation chain.

Key questions

Q: How should security teams give AI agents their own credentials?

A: Start by treating the agent as a separate principal with its own registration, token, and revocation path. Do not reuse the human user's session for the agent. Scope the agent's permissions to the exact tools and resources needed for the task, then log every invocation so the authority chain is visible later.

Q: Why do borrowed sessions create risk for AI agents?

A: Borrowed sessions give the agent the user's full entitlement set, which is usually far broader than the task requires. That expands the blast radius if the agent is compromised, misled, or simply makes the wrong tool call. The risk is not just misuse. It is uncontrolled delegation across the user's entire access profile.

Q: What breaks when AI agents share service accounts or API keys?

A: Shared credentials erase agent-level accountability and make revocation blunt. If one agent is compromised, every system using that credential is exposed, and you cannot tell which agent performed which action. Shared keys also encourage over-permissioning, because one identity has to cover multiple workflows with different access needs.

Q: Who is accountable when an AI agent takes an unauthorized action?

A: Accountability depends on the authorization chain, not just the final action. The human who approved the task, the agent identity that executed it, and the policy that allowed the tool call all matter. If your logs cannot reconstruct that chain, your governance model is incomplete and your incident response will be slow.

Technical breakdown

Borrowed user sessions and why they fail for AI agents

Borrowed sessions collapse the distinction between the person who requested the task and the software that performs it. If an agent reuses the user's OAuth token, it inherits the user's full entitlement set, not just the narrow permission needed for one action. That creates an identity and privilege abuse problem: the agent can read, modify, or delete anything the user could reach. In agentic systems, this is especially dangerous because tool choice happens at runtime, so the eventual action set is not fully known when the session is granted. The security issue is not convenience, it is uncontrolled delegation.

Practical implication: Replace inherited sessions with a separate agent identity and a token limited to the specific tools and scopes the task requires.

Tool-level authorization and scoped permissions

Tool-level authorization is the control that decides whether an agent may invoke a specific capability, not merely whether it has logged in. In practice, an MCP server, API gateway, or backend policy layer checks the agent's token against a permission map for each tool call. This works only when the permissions are explicit, default-deny is enforced, and resource scope is part of the policy. RBAC can define broad job functions, but agentic environments usually need finer scoping so one agent can read tickets while another can touch billing or deployment systems. Without that boundary, tool misuse becomes routine rather than exceptional.

Practical implication: Map every tool to an explicit permission and deny any unregistered tool by default.

Audit trails for delegated agent actions

Auditability in agentic apps must connect three things: the agent identity, the human authorization that initiated it, and the tool invocation that followed. Without that chain, security teams cannot answer who acted, under whose authority, and against which resource. This is more than logging for compliance. It is the only way to reconstruct behaviour after a prompt injection, compromised dependency, or delegated action goes wrong. In environments with multiple agents or delegated tasks, the log must also preserve the delegation path, because a single user session can fan out into several machine actors.

Practical implication: Log agent identity, user approval, tool name, resource target, and decision outcome for every invocation.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• MongoBleed breach — MongoBleed exposed secrets across 87K MongoDB servers.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agent identity and privilege abuse is the core control problem in agentic apps. When an AI agent borrows a human session or a shared service account, the system no longer knows whether a tool call reflects human intent or runtime agent behaviour. That breaks least privilege at the point where execution happens, not just at login. The implication is that agent identity must be governed as its own subject in IAM and NHI programmes, not folded into user access.

Scoped credentials are the named control boundary this category needs. The practical failure mode here is over-broad delegation, not authentication weakness alone. A support agent that can only read an invoice is safe enough; a support agent holding refund, ticket, and admin permissions is not. This is the identity blast radius problem, and it explains why per-agent credentials matter more than shared automation accounts in multi-tool environments.

Tool-level authorization is the enforcement layer that prevents tool misuse from becoming systemic. Authentication can prove who the agent is, but only authorization can constrain what it may do at the moment of invocation. The article maps cleanly to OWASP-AGENTIC and OWASP-NHI because an agent is an NHI even when it is user-triggered. Practitioners should treat every tool as a separately governed capability, not as an ambient privilege of the agent runtime.

Auditability must include the delegation chain, not just the final action. Agentic systems can pass work from one actor to another, and that makes attribution harder than in human IAM or static workload identity. If the log only shows the last hop, the security team loses the evidence needed for incident response, recertification, and accountability. The consequence is that governance has to track the originating user, the agent, and each delegated step as one control surface.

Identity blast radius: The article exposes a useful named concept for the field. Identity blast radius is the difference between the permission a task needs and the permission the credential actually carries. In agentic systems, that gap can turn one benign workflow into broad systems access, which is why identity architecture now determines how far a failure can spread.

From our research:

• 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
• That matters because only 44% of organisations say they have implemented any policies to govern AI agents, leaving most deployments with scope control but no formal governance baseline.
• For a broader control model, see OWASP Top 10 for Agentic Applications for the surrounding agentic risk categories practitioners need to manage.

What this signals

With 80% of organisations already seeing AI agents act beyond intended scope, the governance gap is no longer theoretical. IAM teams should assume that task delegation without separate agent identity will keep producing privilege spillover, even when the underlying model or workflow changes.

Identity blast radius: the real programme risk is not whether an agent can log in, but how far one compromised or mis-scoped credential can reach. That means access reviews, PAM controls, and NHI governance all need to reflect the agent as a distinct actor with its own audit trail and revocation path.

Practitioners should align agent governance with OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework so identity, authorization, and monitoring are managed as one control system.

For practitioners

• Register each agent as a separate principal Issue per-agent credentials instead of reusing the user's OAuth session or a shared service account. Keep the agent token narrower than the human user's full permissions, and revoke that agent independently when behaviour changes or compromise is suspected.
• Enforce default-deny tool mappings Build a permission map for every tool your agents can call, and reject any tool that does not have an explicit authorization rule. Use the same control at the MCP server, API gateway, or service middleware so the decision happens at invocation time.
• Separate user authorization from agent authority Let the human approve the task, but do not transfer the human's entire session to the agent. Issue a scoped token that reflects what the user authorised the agent to do, then log that relationship for later review and recertification.
• Log every delegated tool invocation Capture the agent identity, the originating user, the target resource, the permission decision, and the delegation chain for each call. Keep the audit trail queryable so security teams can reconstruct misuse quickly and certify access accurately.

Key takeaways

• AI agents become an identity risk when they inherit human sessions or shared service accounts instead of receiving scoped credentials of their own.
• The strongest evidence in the source is that most organisations already see agents operating outside intended scope, which makes this a present governance issue rather than a future one.
• The control that changes outcomes is not broader automation, but separate agent identity, tool-level authorization, and a complete delegation audit trail.

Key terms

• Agent Identity: An agent identity is the separate account or principal assigned to an AI agent so its actions can be authenticated, authorized, and audited independently of the human who initiated it. In practice, this prevents borrowed sessions from turning one delegated task into broad system access.
• Scoped Credential: A scoped credential is a token, key, or certificate limited to a narrow set of actions, resources, and duration. For agents, scoped credentials are the main way to keep runtime decisions from inheriting a user's full access profile or a shared service account's broad reach.
• Tool-Level Authorization: Tool-level authorization is the control that decides whether an agent may invoke a specific tool or capability at the moment of use. It is stronger than login-only checks because it constrains each action, not just the session, and it creates a clearer boundary for agent governance.
• Identity Blast Radius: Identity blast radius is the amount of access exposed when one credential, session, or principal is misused or compromised. In agentic systems, it measures how far a single agent can reach across tools, tenants, and resources before policy stops it.

Deepen your knowledge

Agent identity, scoped credentials, and tool-level authorization are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for AI agents from a similar starting point, it is worth exploring.

This post draws on content published by WorkOS: Securing agentic apps with scoped agent credentials and tool-level authorization. Read the original.