Scoping what tools, data, and actions an agent can reach — bound to the identity of the human on whose behalf it acts — so a compromised or confused agent can't exceed that person's real authority.
How it works
To manage access control for AI agents, we start by issuing a short-lived, down-scoped token that represents the identity of the end user. This token carries specific roles and attributes tied to that user, rather than a broad service credential that could grant excessive access. For instance, using OAuth on-behalf-of or STS AssumeRole allows the agent to act on behalf of the user while ensuring that it only has the permissions that the user possesses. This limits what the agent can do, which is crucial for security.
Next, we enforce authorization at the Tool boundary. Each tool that the agent interacts with must re-check the RBAC (Role-Based Access Control) or ABAC (Attribute-Based Access Control) policies against the caller's identity. This means that instead of trusting the AI model to self-restrain, each tool independently verifies whether the agent has the right to perform the requested action. For example, if an agent tries to access a sensitive database, the database tool will check the user's permissions before granting access.
a policy engine, such as OPA (Open Policy Agent) or Cedar, evaluates the ABAC rules to determine access rights. High-impact tools require human-in-the-loop confirmation, adding another layer of security. It's also critical to deploy Multi-Cloud Platform (MCP) servers with per-user scopes instead of a shared admin key, ensuring that each user's permissions are strictly enforced and isolated from others.
- Generate a scoped token for the user.
- Evaluate access using a policy engine.
- Check authorization at each tool boundary.
- Require human confirmation for high-impact actions.
- Use least privilege principles for all agents.
The software-engineering analogue
In software engineering, a common practice is to pass the caller's JWT (JSON Web Token) down through a service mesh. Each service in the mesh independently authorizes the request based on the token, ensuring that only authorized actions are performed at each hop. This is similar to how we handle access control for AI agents. However, the key difference lies in how the agent selects which tools to call. The agent uses untrusted natural language to determine the tools it interacts with, which introduces a risk of prompt injection as a privilege-escalation vector. Therefore, the enforcement of access control must occur outside the model itself, as the model cannot be trusted to manage its own permissions.
Why not the obvious alternative
A common but risky approach is to provide the agent with a single powerful API key that grants broad access to all tools and resources. This convenience comes at a high cost; if an attacker successfully injects a malicious prompt, they could gain full admin rights and control over the entire system. This scenario highlights the importance of implementing least privilege principles combined with per-tool checks, which effectively contain the blast radius to what the specific user could already do.
By enforcing least privilege and ensuring that each tool checks the user's permissions, we can significantly reduce the risk associated with prompt injection. Instead of allowing the agent to operate with unrestricted access, we limit its capabilities to only what is necessary for the task at hand. This containment strategy is vital for maintaining security in agentic deployments.
When to use which
Access control measures are essential for any AI agent that interacts with multi-tenant or sensitive data. In these cases, using per-user tokens combined with tool-level authorization is non-negotiable. This ensures that each user's actions are confined to their own permissions, minimizing risks. For read-only single-tenant demos, a lighter approach may be acceptable, but it should still adhere to least-privilege principles by default to avoid potential security issues.
In production: when it breaks
Why it happens. Access control misconfigurations can occur when roles and permissions are not correctly defined or enforced. For instance, if an AI agent is granted broader access than intended due to overlapping role definitions, it can access data outside its designated scope, leading to unauthorized retrievals.
- Check the access control list for the affected agent's permissions.
- Log the specific actions taken by the agent during the unauthorized access incidents.
- Review the role definitions to identify any overlaps or misconfigurations.
What it delivers
By implementing these access control mechanisms, we effectively reduce the risk of prompt injection attacks. The agent's capabilities degrade to acting as a specific user rather than having unrestricted control over the system. This containment is essential for ensuring that AI agents operate safely and securely within their defined boundaries.