Learn how AI agents create confused deputy conditions by default and build a credential management framework that maps effective authority and enforces least privilege at runtime.
Security engineers managing agentic deployments keep encountering the same question: how does a user with no Salesforce access extract CRM records through a Copilot agent? The answer is the confused deputy problem, and understanding its mechanism is the first step toward controlling it.
A confused deputy attack occurs when a privileged program is manipulated into using its authority on behalf of a less-privileged caller. The "deputy" holds credentials that grant broad access. The caller does not hold those credentials directly. But by invoking the deputy, the caller gains the deputy's effective authority for the duration of the interaction. The deputy is not compromised. The IAM policy is not violated in any technical sense. The access control model simply was not designed to verify whether the caller deserved the access the deputy provided.
In traditional software, this required deliberate exploitation. A developer had to craft a specific request that caused a privileged service to act outside its intended scope. It was an edge case.
AI agents are, structurally, confused deputies by design. An agent built in Copilot Studio, Salesforce Agentforce, or n8n holds credentials that belong to its creator. Those credentials may include admin-level OAuth tokens, service account keys, or hardcoded API secrets. When any user invokes that agent, the agent executes with the creator's credential authority, not the invoker's. The agent does not check whether the invoker is authorized to access the data the agent can reach. It has no mechanism to do that.
This is not a misconfiguration. It is the default operating model for most low-code and no-code agent platforms. Thousands of agents are deployed each week without security oversight, and the majority inherit credentials that grant far more access than the invoking user would ever be provisioned directly. 90% of agents carry excessive privileges relative to their actual workflow requirements.
The core problem in agentic identity security is the gap between two identities: the invoker identity (the person or system triggering the agent) and the credential identity (the account whose tokens the agent actually uses to execute actions). Most platforms log the agent's actions under the credential identity. The invoker identity is either not logged at all or logged separately in a system that security teams cannot correlate in real time.
This is the visibility gap that makes confused deputy attacks in agentic systems so difficult to detect. The blast radius of a single over-permissioned agent can span every SaaS application its embedded credentials can reach, and the invoker who triggered the escalation may never appear in any access log tied to those applications.
Security engineers cannot design controls for credential types they have not mapped. AI agents acquire and hold credentials through four distinct mechanisms, each with different risk profiles.
OAuth tokens and delegated access: most enterprise agent platforms use OAuth 2.0 to connect agents to downstream SaaS applications. When an agent creator authorizes a connection, the platform stores an OAuth access token or refresh token on behalf of the creator. That token persists in the platform's credential store. Every subsequent agent invocation uses that stored token without re-authenticating the original creator or verifying the invoker. The token scope is set at authorization time, often with broad permissions because the creator was an admin or power user. The scope rarely shrinks after initial provisioning.
Maker mode embedded credentials: maker mode is the specific configuration state where an agent executes using its creator's fixed credentials for every invocation. The Copilot Studio connector model, for example, defaults to maker mode for connections to SharePoint, Salesforce, and other enterprise applications. The agent creator's token is embedded in the connector configuration. Any user who can invoke the agent, including users with no direct access to the connected application, gains the creator's effective authority for the duration of the session. Maker mode is the single highest-risk credential pattern in low-code agent platforms because it converts every agent invocation into a potential privilege escalation event.
Service accounts: agents deployed on platforms like Amazon Bedrock and Azure AI Foundry authenticate using IAM roles or service accounts rather than individual user tokens. These service accounts are provisioned at deployment time and often carry permissions scoped for development or testing but never tightened for production. The service account operates continuously, without the lifecycle events (offboarding, access reviews, MFA challenges) that trigger human identity governance processes.
Bearer tokens and the possession-equals-authorization problem: bearer tokens are the authentication credential class that underlies most agent-to-SaaS communication. A bearer token operates on a single assumption: possession equals authorization. Any system that receives a valid bearer token treats the holder as authorized, with no verification of how the token was obtained or whether the presenting entity is the intended holder. The ShinyHunters exploitation of stolen bearer tokens from a Salesloft-Drift integration demonstrated this at scale. Attackers used stolen tokens to access Salesforce environments across more than 700 organizations. The token traffic looked identical to legitimate integration activity. No authentication alert fired. AI agents are bearer token holders at every layer of their operation.
Most agentic deployments exhibit multiple credential management failures simultaneously. When failures stack, they create toxic combinations that elevate individual medium-severity risks into critical-priority incidents. The following five failures account for the majority of confused deputy conditions observed across enterprise agentic deployments.
Over-scoped tokens: agents are provisioned with OAuth scopes that reflect the maximum access the creator might need, not the minimum access the agent's specific workflow requires.
- What this control enforces: scope-minimized token issuance scoped to the specific workflow function, not the creator's full permission set.
- Why theoretical configuration fails: the token is provisioned once at creator authorization time and is never automatically reduced as the agent's actual workflow becomes clear.
Maker mode inheritance: the agent executes with the creator's credentials for every invocation, regardless of the invoker's own permission level.
- What this control enforces: per-invoker credential resolution, where the agent's actions are scoped to the invoker's entitlements, not the creator's.
- Why theoretical configuration fails: platforms like Copilot Studio default to maker mode. The configuration appears correct because the agent is doing exactly what it was set up to do.
No invoker verification: the agent platform does not verify whether the invoking identity has the right to access the data the agent will retrieve on their behalf.
- What this control enforces: correlation of the invoker's identity against the entitlements of the SaaS application the agent is about to access, before execution.
- Why theoretical configuration fails: the agent checks that the invoker can use the agent. It does not check that the invoker should receive the output the agent's credentials can produce.
Credential forwarding through agent chains: multi-agent architectures introduce action chaining. Agent A receives a request, delegates to Agent B, which delegates to Agent C. Each agent in the chain may hold different credentials. In supervisor-agent patterns, the supervisor may forward its full conversation context, including sensitive data from earlier in the chain, to sub-agents with broader access.
- What this control enforces: scoped delegation tokens that carry only the permission needed for the next hop, with context isolation between agent hops.
- Why theoretical configuration fails: most agent orchestration frameworks pass full context by default. The forwarding behavior is correct by design; the scope is not bounded.
No rotation or expiry: agent credentials are provisioned once and left in place indefinitely. OAuth tokens are refreshed automatically. Service account keys do not expire.
- What this control enforces: short-lived just-in-time credentials issued at task execution time, with automated rotation policies and lifecycle tied to the agent's operational status.
- Why theoretical configuration fails: when an agent creator leaves the organization and their account is disabled, the agent continues running as an orphaned agent. The credential persists. The human lifecycle event that should have triggered revocation never reached the agent layer.
FailureMechanismTechnical ControlOver-scoped tokensBroad OAuth scopes set at provisioning, never reducedScope-minimized token issuance; periodic entitlement reviewMaker mode inheritanceCreator credentials embedded and used for all invokersPer-invoker credential resolution; user context token patternsNo invoker verificationAgent executes without checking invoker's access rightsInvoker-identity verification before action executionCredential forwarding in chainsFull context including credentials passed to sub-agentsScoped delegation tokens; context isolation between agent hopsNo rotation or expiryCredentials persist indefinitely with no lifecycle managementShort-lived just-in-time credentials; automated rotation policies
Knowing the failures is necessary but not sufficient. Security engineers need specific technical controls mapped to each failure mode.
Invoker-identity verification before action: the foundational control is requiring the agent platform to verify the invoker's identity and access rights before executing any action that retrieves or modifies data. This is not the same as authenticating the invoker to use the agent. It means correlating the invoker's identity against the entitlements of the SaaS application the agent is about to access. If the invoker does not have direct access to Salesforce, the agent should not retrieve Salesforce data on their behalf, regardless of what credentials the agent holds.
Scoped and just-in-time credentials: rather than embedding persistent broad-scoped tokens in agent configurations, the preferred design pattern issues scoped, short-lived credentials at the moment of task execution. The agent requests access for a specific operation, receives a time-limited token scoped to that operation, executes, and the token expires. The agent never holds a persistent credential that can be forwarded, stolen, or abused across sessions. Major secrets management platforms are shipping agent-specific controls in 2026 that implement this pattern: separate machine identities per agent, least privilege scoping per credential, short rotation intervals, and full audit logs of which agent used which credential and when.
On-behalf-of token patterns: the on-behalf-of (OBO) token pattern addresses the invoker-credential mismatch directly. In an OBO flow, the agent receives the invoker's identity token and exchanges it for a new token scoped to the downstream resource. The downstream application receives a token that carries the invoker's identity context, not the agent creator's. The downstream application can then apply its own access controls against the invoker's actual entitlements. This pattern is not universally available across all agent platforms, but it is the correct architectural direction for any team building or governing agentic workflows. It closes the confused deputy gap at the token level.
Runtime authority correlation: configuration is not reality. An agent's theoretical configuration describes what it is set up to do. Runtime authority correlation reveals what it can actually do given the live state of all entitlements across every connected application. This distinction is the difference between ghost chasing and runtime truth. Effective authority mapping requires correlating the agent's credential set against the actual permissions those credentials carry inside each connected SaaS application, the invoker's own entitlements in those applications, and the actions the agent has actually taken versus the actions its configuration permits.
Probabilistic agents require deterministic guardrails. The following framework gives security engineering teams a structured approach to AI agent credential management that scales with agent proliferation rather than breaking under it.
Step 1: Inventory all agent credentials. Security teams cannot govern what they cannot see. The starting point is a complete inventory of every agent in the environment, every credential that agent holds, and every SaaS application those credentials can reach. One enterprise discovered 377 Copilot agents through an assessment they had not initiated. Another found 2,500 agents already created before any inventory existed. The inventory is not a one-time exercise. Agents are deployed continuously, and the inventory must update in real time. The inventory must capture: agent name and platform, creator and owner identity, credential type and scope, connected applications, invoker access model (maker mode vs. per-user), and last-used timestamp.
Step 2: Map effective authority. An inventory of credentials is not the same as a map of effective authority. Effective authority is what the agent can actually do inside each connected application after all entitlements resolve. A token that appears to have read-only scope may carry write permissions through an inherited role. A service account that appears limited may have admin delegation through a platform-specific configuration. Mapping effective authority requires correlating credential scope against application-level entitlements, not just reading the OAuth scope string. This is the layer where toxic risk combinations become visible: an agent in maker mode with org-wide access and a disabled owner is not three separate medium-severity findings. It is a single critical-priority condition requiring immediate action.
Step 3: Enforce least privilege at the credential level. Least privilege for AI agents means scoping every credential to the minimum access the agent's specific workflow requires, not the maximum access the creator happens to have. This requires reviewing existing agent credentials against actual workflow requirements and reducing scope where the current grant exceeds what the task needs. Applying this discipline to agent credentials requires treating each agent as a non-human identity with its own access lifecycle: provisioning, periodic review, and revocation tied to the agent's operational status rather than the creator's employment status.
Step 4: Runtime monitoring. Static credential reviews catch the configuration state at a point in time. Runtime monitoring captures what agents actually do with their credentials during execution. This includes: which invoker triggered the agent, which credentials the agent used, which data was accessed or modified, and whether the invoker's own entitlements would have permitted that access directly. Runtime monitoring is what separates evidence-based security from ghost chasing. Security teams consistently describe the same frustration with posture-only tools: they show what could happen, but teams need to know what did happen, whether it succeeded, and what data was touched.
Step 5: Deterministic guardrails. Detection without enforcement is expensive logging. Deterministic guardrails are fixed, predictable rules applied to probabilistic agents at runtime. Where an agent would execute an action that violates a credential policy, such as using maker mode credentials for an invoker who lacks direct access to the target application, a deterministic guardrail blocks the action before it completes. The guardrail does not reason probabilistically. It applies a fixed rule: if invoker identity does not match the entitlement required for this action, block. This is the control that converts runtime visibility into runtime prevention.
For most security engineering teams, the right starting sequence is: inventory first, effective authority mapping second, least privilege enforcement third. Runtime monitoring and guardrails require the inventory and authority map to function correctly. Teams that skip to enforcement without the foundational visibility layer end up enforcing against theoretical configuration, not against the actual credential authority their agents hold.
See your confused deputy exposure before it becomes an incident. Obsidian maps effective authority across every agent, every credential, and every SaaS platform in your environment. Start your AI agent risk assessment