AI agents need identities of their own

AI agents become dangerous when they can act with broad, long-lived permissions.

An assistant that only generates text has a limited ability to cause direct harm. An agent connected to email, GitHub, cloud infrastructure, payment systems, or internal databases can take real actions. It can create files, modify records, deploy code, export data, or call additional tools.

That makes authorization one of the most important design problems in agentic systems.

The safest default is to treat every agent as a separate security principal. Each agent should have its own identity, receive only the permissions required for its current task, and request fresh approval before taking sensitive or irreversible actions.

Traditional applications usually perform a limited set of predictable operations. Their permissions are tied to known features and relatively stable execution paths.

Agents behave differently. They can interpret a broad objective, choose tools, make multiple requests, react to intermediate results, and continue working until they believe the task is complete.

That flexibility is useful, but it increases the cost of excessive permissions.

A single overbroad token could allow an agent to:

Authorization therefore needs to answer more than whether the agent can authenticate.

A secure system must determine which agent is acting, which user initiated the task, what resource is being accessed, which operation is requested, how long the permission should remain valid, and whether the action requires additional approval.

A useful way to structure agent authorization is the Separate Identity Pattern:

The human still provides the initial authority. The agent does not receive a reusable copy of the human’s full session or credentials.

Instead, the application creates limited access for the agent based on the user’s request. That access should represent the intersection of three boundaries:

If any of those boundaries excludes an action, the request should be denied or escalated for approval.

This separation also improves accountability. Logs can distinguish between an action performed directly by the user and one performed by an agent operating on the user’s behalf.

Consider an AI agent connected to a company’s ticketing system.

A user asks it to review open support tickets and draft responses. The agent needs permission to read assigned tickets and create draft comments. It does not need permission to delete tickets, export the customer database, change billing information, or manage other employees’ accounts.

A weak implementation might pass the user’s existing session token directly to the agent. The agent would then inherit everything the user can access, even though most of those permissions are irrelevant to the task.

A safer implementation would issue a short-lived delegated token with limits such as:

The system could then require human approval before a draft is sent to the customer.

The agent remains useful, but its authority is limited to the job it was given.

The Model Context Protocol makes authorization problems more visible because it gives models and agents a consistent way to interact with external tools and data sources.

An MCP server may expose access to files, databases, developer tools, business systems, or third-party APIs. Once an agent can call those tools, the MCP server becomes part of the security boundary.

Authentication alone is insufficient. The server or an adjacent policy layer still needs to decide whether a specific agent may perform a specific operation on a specific resource.

MCP security guidance increasingly emphasizes controls such as secure delegation, sandboxing, rate limiting, lifecycle management, and auditability. These controls are central to the architecture because agents can combine tool calls and operate with less direct supervision than ordinary applications.

One of the most relevant risks is the confused deputy problem.

This occurs when a system with legitimate authority uses that authority in a way the original user did not intend. An agent may technically be permitted to call a tool while still misunderstanding the request, following malicious instructions from untrusted content, or selecting an inappropriate action.

Prompt injection makes this risk more serious. A document, webpage, email, or tool response could contain instructions designed to redirect the agent.

Separating agent authority from user authority reduces the potential damage. Even when the agent is manipulated, it remains constrained by its own permissions.

Policy checks should also occur when the action is requested, rather than only when the agent begins its session. A long-running task may change direction as the agent processes new information. Authorization decisions made at execution time can account for the actual resource, operation, scope, and context.

Long-lived API keys are poorly suited to autonomous agents.

A credential that remains valid for months can be reused after the original task has ended. It may also be difficult to associate with a specific agent, user, or action.

Short-lived delegated credentials reduce that risk. OAuth-based delegation and token exchange can allow an application to grant limited downstream access without handing the agent the user’s original token.

A task-bound credential should ideally describe:

The policy layer should reject the credential when the agent moves beyond those boundaries.

Human approval is most useful when it applies to an exact proposed action.

A generic confirmation at the beginning of a session gives the agent too much room to reinterpret the user’s intent. Approval should instead identify the resource, operation, destination, and important parameters.

Sensitive actions that commonly deserve fresh approval include:

The agent should not be able to generate or approve its own confirmation. The approval must come through a trusted interface outside the agent’s control.

Authorization should be supported by additional controls.

Agents that browse the web, execute code, or access files should operate inside isolated environments. Network egress, available tools, file access, and execution time should be restricted according to the task.

Rate limits and kill switches also matter. An agent can repeat an action much faster than a person, so a mistake that would normally affect one record could affect thousands.

Every authorization decision should produce a useful audit record. Logs should identify:

Logging an action without recording why it was authorized leaves investigators with an incomplete picture.

Teams building agentic systems should treat authorization as a product requirement rather than an integration detail.

Give agents their own identities. Issue short-lived, task-specific credentials. Enforce permissions at the point of action. Require fresh approval for high-impact operations. Isolate dangerous capabilities and record each policy decision.

Then test the failure paths.

Evaluate what happens when an agent encounters prompt injection, reuses an expired token, chains several tools, requests a resource outside its scope, or begins repeating the same operation.

A useful review can start with three questions:

Vague answers usually indicate that the system relies on trust where it should rely on policy.

An AI agent should not act as an unrestricted extension of the user who launched it.

It should act as a separate principal with a defined identity, narrow permissions, a short operating window, and clear accountability.

That design does not eliminate every risk associated with agents. It does make prompt injection, tool misuse, credential theft, and unintended actions far less damaging.