AI agent identity: control without limiting scale

AI agents only scale with identity, limits, and evidence for every action. When an agent reads data, queries systems, changes records, or initiates workflows, it is no longer just a language interface. It becomes a non-human identity within the organization.

This shift requires revisiting a common assumption: application permissions are not enough to govern autonomy. An agent may receive a legitimate request and, during execution, encounter malicious instructions in emails, documents, webpages, or tickets. It may also combine data from different sources and produce an action that none of the individual systems would explicitly authorize.

The topic has recently gained technical depth. In February 2026, NIST opened a specific proposal on identification, authentication, authorization, delegation, and non-repudiation for software and AI agents. In May, Google Cloud introduced agent identities as a distinct type of principal, separate from users and service accounts. OWASP has also elevated identity and privilege abuse among the most critical risks in agentic applications. NIST, 2026 (nccoe.nist.gov) Google Cloud, 2026 (cloud.google.com) OWASP, 2026 (genai.owasp.org)

What is AI agent identity, and why does it need to be separate?

AI agent identity is the verifiable record that distinguishes an agent from people, generic applications, and other agents. It should include technical and operational attributes: owner, environment, purpose, model in use, permitted tools, code origin, risk level, and lifecycle.

The recurring mistake is to run the agent with a broad service account or, worse, a user's persistent token. This reduces initial friction but eliminates accountability. After an incident, the team knows that a credential performed an action, but cannot answer basic questions: which agent used it, for what purpose, in what context, and on whose behalf.

A dedicated identity establishes separation of duties. The user remains the one requesting a task. The agent becomes the one executing it. The tool or API is the protected resource. This distinction makes it possible to apply different policies to each relationship.

The glossary helps make the design objective:

• Non-human identity: identity for software, a service, robot, or agent that accesses resources without being a person.
• Delegation: temporary authorization for the agent to act on behalf of a user or process.
• Attestation: cryptographic proof that the workload is what it claims to be and is running in the expected environment.
• Non-repudiation: the ability to demonstrate afterward which identity took an action and under what authorization.

Separation also prevents the agent from being treated as an enterprise chat interface with unrestricted access. An assistant that summarizes documents has a different risk profile from an agent that changes prices, approves refunds, or opens tickets with vendors. The identity must express that difference from registration onward.

Which access decisions need to be made for every action?

Authorization must assess the specific action, not just the permission granted at installation. In traditional systems, an application receives scopes and uses them in a relatively predictable way. With agents, the execution path changes according to the task, retrieved context, and available tools.

For this reason, the access decision needs to consider at least seven signals: agent identity, delegating user or process, requested resource, intended action, data involved, environment, and transactional risk. A customer service agent may look up a customer's history. That does not mean it can export the entire contact database or change commercial terms.

This model is known as contextual authorization. It combines RBAC, or role-based access control, with ABAC, or attribute-based access control. RBAC establishes a simple baseline, such as “support agent.” ABAC adds conditions: customer region, data classification, time of day, financial amount, source channel, and session trust level.

Recent Microsoft documentation recommends preserving user authorization when an agent accesses tickets, files, emails, or customer records. The delegated access pattern is more appropriate when there is an authenticated user; application-only access should be limited to well-defined, auditable back-office tasks. Microsoft Learn, 2026 (learn.microsoft.com)

In practice, the policy question should not be “can the agent use the CRM?” It should be: “can this agent, for this user, in this task, read this record and perform this action now?” The difference may seem semantic. It is an architectural difference.

How do you apply least privilege when the agent decides the next step?

Least privilege for agents means granting only the access required for the next verifiable step. It does not mean providing a broad set of permissions because the workflow may eventually need them.

The safest way to apply this principle is to replace persistent credentials with short-lived, specific, revocable tokens. Each token should have a scope limited by tool, resource, action, and duration. An agent that needs to create a proposal draft can receive read access to approved customer data and write access only to a draft repository. It does not need permission to send the document, apply a discount, or update the master record.

It is also worth segmenting tools by criticality. Organize them into four groups:

1. Low-impact inquiry: searching articles, order status, and public documentation.
2. Sensitive inquiry: accessing contracts, financial data, HR information, or personal data.
3. Reversible action: creating drafts, opening tickets, suggesting changes, and updating non-critical fields.
4. Material action: sending payments, deleting data, changing prices, modifying permissions, or making external commitments.

Groups three and four require additional policies. For material actions, use just-in-time approval, or JIT: permission is released only for that decision, at that moment, with a strict scope. The user or manager does not “give the agent access”; they approve a declared action.

This reduces the impact of two common risks. The first is indirect prompt injection, when external content attempts to redirect the agent. The second is tool misuse, when an apparently harmless instruction induces an action beyond the original intent. OWASP notes that identity and privilege abuse has one of the largest gaps between risk severity and organizational preparedness. (genai.owasp.org)

Where should policy reside: in the prompt, the agent, or the infrastructure?

Authorization policy must be enforced outside the prompt and validated before tool execution. Prompts guide behavior. They are not access controls. A model may misinterpret an instruction, receive conflicting context, or be manipulated by external content. The decision to allow a transaction must reside in a deterministic layer.

A mature architecture has five control points. The first is inventory: every agent, tool, MCP server, integration, and credential must be known. MCP, or Model Context Protocol, is a protocol used to connect models and agents to tools and context sources. It can accelerate integrations, but it also multiplies the access surface.

The second point is the identity provider. It issues and validates credentials for the user, agent, and workloads. The third is the policy engine, which evaluates attributes and produces a decision to allow, deny, or request approval. The fourth is a tool gateway, which intercepts calls to APIs, databases, SaaS systems, and automations. The fifth is the observability layer, responsible for recording intent, context, decision, execution, and outcome.

The recommended flow is straightforward:

1. The user or process initiates a task.
2. The agent receives its own identity and a limited delegation.
3. Before each tool call, the gateway sends the attributes to the policy engine.
4. The policy allows, denies, or requires additional approval.
5. The event is recorded with correlation across user, agent, tool, and resource.

NIST highlights these exact areas: identification, authentication, dynamic authorization, delegation, action logging, and traceability of data and prompt origins. (nccoe.nist.gov) The practical implication is clear: security must follow execution, not just initial provisioning.

What evidence is needed to audit an agent in production?

A useful audit trail must reconstruct the complete decision chain, not merely list API calls. Conventional logs record that an endpoint was called. For agents, that is insufficient. It is necessary to know why the action was taken and which constraints were in place.

Each relevant event should contain a correlation identifier. This identifier links the initial request, the delegating user, the agent version, the model, the retrieved documents, the action plan, the tools called, the policy decisions, and the final response.

Also record versions. An agent may change behavior when there is a change to the system prompt, model, memory, tool, or policy. Without versioning, it is difficult to compare incidents and impossible to attribute a failure to a specific modification.

There is an important distinction between execution telemetry and control evidence. Telemetry shows latency, call volume, error rates, and costs. Control evidence demonstrates that an action was authorized according to the policy in effect. Companies need both.

Define indicators that connect governance to operations: percentage of inventoried agents, number of dormant permissions, volume of denied actions, approvals by risk category, out-of-scope access attempts, time to revoke credentials, and log coverage by tool. These indicators reveal whether the organization is controlling autonomy or merely observing its expansion.

How can you implement agent identity without paralyzing operations?

Implementation should begin with agents that already access critical systems, not with an idealized platform. The initial goal is to reduce real exposure and create reusable patterns.

Start with a 30-day inventory. List production agents, prototypes with access to real data, automation integrations, service accounts used by agents, MCP tools, and credentials stored in vaults or environment variables. Classify each item by autonomy, accessed data, and action impact.

Next, choose a high-value workflow with manageable risk. Good candidates include ticket triage, proposal preparation, KPI consolidation, or assisted record updates. Avoid starting with payments, data deletion, administrative permissions, or regulatory decisions.

For this workflow, create a dedicated agent identity, short-lived tokens, tool-level scopes, and JIT approval for material actions. Then implement correlation logging and simulate failures: a malicious instruction in a document, an expired token, an out-of-scope read attempt, an unavailable tool, and a context change during execution.

Expansion should happen through standards, not improvised copies. An internal catalog of agents, approved tools, policy templates, and minimum logging requirements reduces divergence across teams. Orchestration platforms such as Centriu can centralize operational visibility, provided authorization continues to be enforced by independent, verifiable controls.

The intended outcome is not to prevent agents from acting. It is to ensure that every action has an identity, explicit authority, a technical limit, and retrievable evidence. This is the foundation for turning automation into sustainable operational capability.