As AI agents gain access to tools and data, identity and authorization become the real security boundary. A practical architecture for least privilege, delegation, approvals, and audit.
The dangerous part of an AI agent is not that it can write a convincing answer. It is that the answer can become an action.
Connect a model to email, a database, a terminal, and a payment system and you have created a new kind of actor inside the organisation. It can read instructions from untrusted material, decide which tool to use, and execute at a speed no human operator can match. Yet many early agent deployments still authenticate that actor with one broad service account and record its work under a generic application name.
That design makes the agent useful quickly. It also makes accountability disappear.
In May 2026, the US National Institute of Standards and Technology published its analysis of industry responses on AI agent security. Respondents broadly agreed on two points: agents introduce new security threats that are slowing adoption, and established cybersecurity controls remain relevant but need to be adapted.
The adaptation begins with identity.
Traditional enterprise software often has two identities in a transaction: the human user and the service processing the request. Agentic systems can have many more:
Collapsing all of these into one credential destroys the delegation chain. When an unusual database export appears in the audit log, the security team needs to know more than “the AI service did it.” They need to know which person initiated the task, which agent decided to call the tool, which policy allowed it, what arguments were passed, and what data left the boundary.
An agent therefore needs its own machine identity. That identity should be distinct from the invoking user, scoped to a defined capability, and connected to the user through a traceable delegation record.
This is not merely a vendor pattern. NIST’s AI Agent Standards Initiative, updated in April, identifies authentication and identity infrastructure for human-agent and multi-agent interactions as a standards priority. Google Cloud announced broader policy and monitoring support for agent identities in May. AWS’s April security guidance similarly argues that agents require separate identities, secure credential flows, and infrastructure-enforced least privilege.
The products differ. The architectural direction is converging.
Imagine a procurement agent asked to reconcile an invoice discrepancy.
It may read the invoice, look up the purchase order, query the supplier record, draft a correction, and perhaps release a payment. These actions do not carry equal risk. Reading a document is reversible. Sending a message is visible but difficult to retract. Releasing money is consequential and may require separation of duties.
A safe implementation does not give the agent “procurement access.” It evaluates each action against at least three pieces of context:
The effective permission is the intersection of those constraints, not the union. An agent must never gain more authority simply because it sits between two systems.
For multi-agent workflows, carry that context forward. A subagent should receive a narrower task and narrower permissions than its parent, along with a short-lived delegation token. It should not inherit a permanent credential or the full authority of the original user.
Prompts are useful for expressing intent. They are a poor place to enforce security.
“Never send a payment above €5,000 without approval” sounds like a control, but it is an instruction interpreted by the same probabilistic system making the decision. It can be weakened by conflicting context, indirect prompt injection, ambiguous tool output, or a model change.
The policy must be deterministic and external. The agent can propose an action; a separate authorization layer decides whether the action is permitted. That layer should inspect the action, parameters, identity, delegation chain, resource, and current environment before the tool is invoked.
This creates a useful separation:
AWS described this principle in April as deterministic external enforcement. It is the agentic equivalent of not trusting client-side validation in a web application.
An agent needs access to credentials without being able to read or reproduce them.
Do not place secrets in system prompts, tool descriptions, retrieved documents, or environment output the model can inspect. Use a credential broker or gateway that completes OAuth and token exchange outside the reasoning context. Issue short-lived, audience-restricted credentials for one tool and one task. Rotate them automatically.
The model should ask to call get_customer_record. The gateway should authenticate the request, inject the appropriate credential, enforce the approved parameter scope, and return only the fields the agent is allowed to see.
This reduces both accidental leakage and the value of a successful prompt-injection attack. An attacker may influence the agent’s intention, but they still have to cross a policy boundary they cannot rewrite in natural language.
Teams often classify an entire agent as “human in the loop” or “fully autonomous.” That is too coarse.
Autonomy should attach to actions:
| Action class | Example | Default control |
|---|---|---|
| Read-only | Search approved documents | Allow and log |
| Reversible write | Create a draft ticket | Allow with validation |
| External communication | Send customer email | Preview or sampled review |
| Sensitive data movement | Export employee records | Explicit approval |
| Financial or destructive | Release payment, delete data | Strong approval and separation of duties |
As evidence accumulates, the review policy can change. A low-risk action that passes thousands of representative evaluations may move from full review to sampling. A rare, irreversible action may always require a person.
This is what earned autonomy looks like: not confidence in the personality of the agent, but evidence for a bounded action under known conditions.
For every consequential action, retain enough information to reconstruct what happened:
Avoid logging entire prompts or retrieved documents by default; auditability cannot come at the cost of creating a second uncontrolled store of sensitive data. Record structured facts and protected references, then retain detailed payloads only where the threat model and policy justify them.
Test the record during incident exercises. If the team cannot answer “who authorised this action?” without searching five systems and interviewing the developer, the delegation chain is incomplete.
Before an agent receives write access, require these controls:
This may sound like more infrastructure than a prototype deserves. That is precisely the point. A prototype that only drafts text can remain lightweight. The moment it can act on a production system, identity and authorization are part of the feature—not enterprise decoration to add later.
Agents are becoming actors inside software estates. Treating them as identifiable, constrained principals is how organisations make that power usable without making it invisible.
If you are moving an agent from read-only assistance to production actions, we can help design the identity, policy, evaluation, and audit layers through Co‑Build.