Security and identity teams keep finding agents they never set up, with few or no guardrails around how they run and what they can access. According to CSA research, 82% of organizations have unknown AI agents running in their IT infrastructure, and 65% have experienced AI agent-related incidents in the past 12 months.
At the same time, security and identity teams understand AI's potential. They don’t want to block every new agent use case; they want to enable agents, but in a way that’s effective, efficient, and secure.
The solution is to take a different approach to the identity layer. Every agent needs its own identity, with access matched to its job.
Is an agent a user? (Sort of. That's the problem.)
Like users, agents can act autonomously, on behalf of a person, a team, or on a schedule. But agents aren’t human and can act unpredictably, including accessing tools you don’t expect them to, falling for prompt injections, and running up big bills while pursuing poorly-scoped goals.
Without clarity on how to think about these user-like non-humans, teams often take one of two problematic approaches:
- Having the agent run with the same identity as the person who set it up. This breaks down when agents need different permissions than the user within a given platform. If you need to tighten up permissions on your Slack support agent and it’s running as your IT user, then their Slack permissions have to change. And you’ll need to lock out the IT user if you need to stop the agent.
- Giving all agents one shared service account. Six agents behind one “automation” credential results in brittle permissions that are either too permissive or too restrictive. Your agent that reads logs shouldn’t have the same permissions as your agent that deploys code. And with this setup, rotating secrets could take every agent down at once.
When these paths break, the risks go well beyond an agent posting personal information on the company Slack (as embarrassing as that is). According to Veza research: “The average identity now holds 96,000 entitlements, fueling least-privilege and oversight failures.”
Treating agents like tools limits their potential, and treating them like users is risky. Fortunately, there’s a third way: Give every agent its own identity, separate from the user who created it and from other agents. That lets you manage each agent’s permissions independently. From there, you can use context about the agent, its task, and the tools it’s accessing to enforce permissions on a per-tool-call basis and make every action attributable.
How to match access to the job
The way around the user/tool confusion is to think of agents as non-human identities that can operate under different authority models.
An agent can operate under its own authority, where it’s not tied to a particular user’s permissions. An example is a background agent that periodically reads logs and writes to a dashboard. This agent should have its own permissions, scoped to the work it needs to perform.
Or, an agent can operate with authority that’s delegated by a specific user, like a productivity agent that can read and write someone’s emails. In this case, it makes sense for the agent to use a subset of the user’s permissions.
Agents can use machine-to-machine (M2M) tokens to access systems with their own permissions. For tasks performed under a user's delegated authority, agents may use on-behalf-of (OBO) token flows to obtain access based on that user's permissions.
Delegation vs. impersonation
There’s an important distinction between delegating authority and letting agents impersonate users. RFC 8693, the IETF technical specification that extends OAuth 2.0 and standardizes how clients exchange security tokens at authorization servers, makes this clear. Delegation means that the system understands the difference between the agent and the user, while impersonation means that the agent is treated as the user rather than a separate entity.
Secure delegation should preserve the agent's identity as a distinct actor and limit its permissions to what's necessary for the task. This can be achieved through scoped credentials and token claims that identify the agent as acting on behalf of the user.
If you don’t explicitly design for these in your identity system, even if you are using OBO tokens, you can end up with agents that are essentially indistinguishable from users. This presents security risks and creates problems for auditing agent actions.
Enforcing least privilege at the tool-call level
What agents can access should follow the principle of least privilege (PoLP): the bare minimum necessary to perform their functions, and nothing more.
Here’s a pretty basic example: a sales rep might want to use an AI agent to enrich a CRM using research and internal meeting notes. With PoLP in mind, updating the notes field is OK, but the agent shouldn’t be able to update the overall deal value or the won/lost status.
Granular controls like these can be hard to enforce at the identity and token level. You’ll need to rely on the permissions your applications expose, which are often too coarse.
If you’re able to intercept tool calls between agents and MCP servers, however, you can monitor and control the precise actions that agents are taking. By inspecting arguments passed to the tool call, you can even do things like restrict a customer service agent from giving refunds greater than $100.
Making every agent action attributable
For an agent identity and permissions system to be governable and auditable, you need to be able to trace actions back to the agent who took them and (if applicable) the user who delegated authority. As the Block engineering team put it, you need to be able to evaluate “this user, through this software actor acting on their behalf, with this bounded delegated authority, for this request.”
Effective attribution means recording information like the following, and, where applicable, exporting it to your SIEM:
- The agent
- The user it acted for
- A reference to the token or delegation used
- The tool call and arguments
- A run ID for hosted agents
With this audit trail, security teams can investigate unexpected agent behavior, identify compromised agents, and take targeted action to prevent further damage. This includes rotating secrets and revoking outstanding tokens, as well as reviewing the delegations and revoking any you don’t trust.
Unblock agent adoption without compromising security
Security teams want to be able to say yes to agent use cases, and a strong agent identity foundation is a way forward. Give each agent its own identity and narrowly control what it can access depending on the task. This approach treats agents like what they really are: not users or tools, but non-human actors that sometimes operate autonomously and sometimes on a user’s behalf.
The right security tools are designed from the ground up for how agents operate. While there are many options that can help you put access controls and permissions in place, Runlayer sits between AI clients and the MCPs, tools, and systems agents use. This allows security teams to enforce policies on individual tool calls and maintain an audit trail of agent actions.
Read our case study with Gusto to see how Runlayer helps organizations securely enable AI agents.
