An AI Agent Needs Its Own Identity—and a Smaller Permission Set

Imagine a customer-support agent using a manager's credentials. It can read tickets, issue refunds, export customer records, and change account settings because the manager can do all four. The agent's actual assignment is much narrower: summarize a ticket and prepare a response.

The problem exists before the model makes a mistake. The integration has granted more authority than the task requires.

OWASP describes excessive agency as a risk arising when an AI application has too much functionality, permission, or autonomy. Reducing that exposure means examining what the application can execute, not simply improving the instructions given to the model. OWASP: Excessive Agency

Start by separating three concepts. Identity establishes which software actor is making a request. Authorization determines whether that request is permitted. Accountability identifies the people and teams responsible for operating the system. Mapping an agent to an owner does not mean the owner personally approved each action.

A useful access design gives the agent a distinct, managed identity and grants permissions for its specific workflow. Where it acts on behalf of a user, preserve that delegation context without copying the user's entire permission set. Effective access should respect both the application's limits and the user's permitted scope.

For our support example, I would allow the agent to read the assigned ticket and create an internal draft. Customer-data exports and account changes would be unavailable. A refund workflow would use a separate, narrowly defined tool, with server-side checks on the ticket, customer, amount, and approval.

This distinction matters because allowing a tool name is not enough. A permitted “read customer” operation could still request the wrong customer's record. Enforce resource and tenant boundaries in the service that owns the data, even if a gateway also performs checks.

Credentials should be managed outside prompts and ordinary configuration files, using an appropriate secret manager or workload identity mechanism. Prefer scoped, short-lived credentials where the integration supports them. Short lifetimes reduce exposure; they do not automatically provide immediate revocation.

For HTTP-based MCP authorization, validate tokens for the intended resource. The MCP security guidance explicitly rejects token passthrough: accepting a token intended for another service and forwarding it downstream undermines authorization boundaries. Downstream access needs its own correctly designed authorization arrangement. MCP security guidance

Product roles also deserve precision. Cisco describes Duo as supporting agent identity and lifecycle management, and Secure Access as enforcing fine-grained access policies through its MCP gateway architecture. Those are complementary functions; identity registration alone does not establish complete enforcement. Cisco solution brief

Finally, test removal of access. Disable the agent, change its owner's role, and exercise old sessions and cached credentials in a controlled environment. Measure when access actually stops, including queued jobs and downstream connections. A directory update is an event; successful revocation is an observed outcome.

A simple access record can capture the agent, owner, permitted action, resource scope, conditions, credential lifetime, approval requirement, and revocation mechanism.

The question to ask is concrete: if this agent misunderstood its task today, what would the infrastructure still prevent it from doing?