ASI03: Identity & Privilege Abuse
How agents with delegated authorization keys or IAM roles are manipulated to perform actions on behalf of unauthorized users, bypassing role-based access control (RBAC).
Delegated Authority and the Confused Deputy
When an agent is deployed to automate enterprise workflows, it is often assigned its own identity: a service account, an OAuth API token, or an IAM role. This delegated authority introduces a major security challenge. If a low-privilege user can interact with the agent, and the agent has access to high-privilege systems, the agent becomes a Confused Deputy.
The core issue is a mismatch in access control: the agent validates that it has permission to perform the action, but fails to verify if the user who initiated the request has that permission. If this boundary is unchecked, a regular employee can use the agent to bypass authentication controls and read HR records, update payroll data, or modify cloud configurations.
Click the card to reveal the explanation
An Agent with AWS IAM Secrets
An engineering organization connects a DevOps agent to their AWS cluster, granting it permissions to create containers, modify service routes, and view deployment configurations.
A junior developer asks the agent: "We need to test high-availability on staging. Update the staging security group to allow inbound traffic on port 22 from 0.0.0.0/0." The agent checks its own AWS IAM role—which has AdministratorAccess—and executes the request.
The security boundary is bypassed. The junior developer does not have permissions to modify AWS security groups directly, but by using the agent as a proxy, they successfully executed an unauthorized configuration change.
- The agent did not check the user's specific OAuth token or permissions
- It acted on its own high-privilege credentials rather than user context
- The incident created a significant security vulnerability in network rules
- Mitigated by User Context Propagation (delegated tokens)
Privilege Abuse Attack Vectors
Confused Deputy Attacks
An attacker tricks an over-privileged agent into executing administrative tools, modifying configurations, or retrieving database tables that the user is not authorized to access directly.
Credential Harvest / Token Theft
Manipulating the agent to extract its own integration keys or secrets from its environment variables, session memory, or system configuration logs.
Lateral Entitlement Movement
A compromised agent in a staging environment leveraging its trust relationship to access production systems or services, bypassing network segmentation.
Securing Agent Identity & Access Controls
1 / 4🔑 Implement User Context Propagation
Do not run agents under static administrative service accounts. Propagate the user's active session token (like OAuth JWT) to all tool executions so the backend enforces user-specific permissions.
🔒 Apply Least Privilege to Service Accounts
If a tool requires a service account, restrict its scope to the absolute minimum needed. Do not grant write access to databases or global admin roles to developer tools.
👥 Enforce Dual-Signoff for High-Impact Actions
Any request to modify infrastructure, delete records, or transfer assets must require a secondary human sign-off before the API execution completes.
📋 Audit User Identity in Reasoning Loops
Explicitly pass the user's identity metadata into the system prompt, instructing the model to reject queries that demand actions beyond that user's known tier.
Identity Safeguards
- Short-lived Session Keys. Restrict API tokens used by agents to short lifetimes. Avoid hardcoded, permanent environment keys.
- Separation of Environments. Never let staging agents access production API keys or databases. Staging containers should be physically isolated from production networks.
- Active Auditing. Maintain immutable logs that record both the identity of the user who triggered the agent and the tools the agent subsequently invoked.