Identity For Non-Human Actors: Least Privilege, Short-Lived Credentials And Approvals

Most of the harm an AI agent can do comes from the access it holds. A model that is tricked by a hidden instruction but holds no tool permissions is limited to what it says, which can still mislead someone or reveal something it was shown. The same model holding a long-lived administrator key can delete records, move money or copy a customer database.

That makes identity and access the most dependable place to contain agent risk, because these controls work whether or not the model behaves. This article covers how current guidance expects organisations to identify agents, scope and time-limit their credentials, check each action, and use human approval without turning it into a rubber stamp. It applies to anyone building or buying agents; governance frameworks for AI more broadly are covered in the AI Governance And Regulation group.

Why Agent Identity Is Hard

Most identity systems were built for two kinds of actor: people who log in, and services that run fixed code. Agents are neither. They act on behalf of a person, decide for themselves which tools to call, and may start sub-agents of their own.

OWASP’s Top 10 for Agentic Applications describes the result as an attribution gap. Without a distinct, governed identity of its own, an agent borrows a user’s session, a shared API key or a broad service account, and it becomes impossible to enforce real least privilege or to tell afterwards who did what.¹ Its entry ASI03 Identity and Privilege Abuse covers the attacks that exploit this, such as abusing inherited roles, cached credentials or chains of delegation.

The May 2026 joint guidance from six national cyber security agencies makes the same point with an example. A procurement agent is given wide access to finance, email and contracts, and its permissions are reviewed only when it is first deployed. An attacker compromises a minor tool in its workflow, inherits those permissions and approves payments. Because everything runs under the agent’s trusted identity, the audit logs look normal.²

Give Every Agent Its Own Identity

The joint guidance asks developers to treat each agent as a distinct principal with a cryptographically anchored identity, meaning its own keys or certificates.² Its recommended practices include:

• using managed identity services, decentralised identifiers or public key infrastructure to issue agent identities;
• authenticating all calls between agents and to services with mutual TLS, where both ends of a connection prove who they are with certificates;
• keeping a trusted registry that binds each identity to an authorised role, reconciling it regularly against the agents actually running, and denying access to any agent or key not in it;
• never sharing secrets across agents or leaving them static, since stolen static or shared keys are a common route to impersonation.

Keep Access Narrow And Short-Lived

Least privilege for an agent means limiting three things: which tools it can call, what each tool can touch, and for how long. The guidance recommends limiting privileges to the minimum needed for the task, scoping them as narrowly as possible, issuing just-in-time credentials for high-impact or privileged actions, and preventing agents from changing their own privileges or delegating without expiry timers and a recorded chain of grants.²

It also warns against a quieter design flaw. If permissions are checked once at start-up rather than at every call, an attacker can ride on a stale “allow” decision long after circumstances have changed. The guidance therefore asks for continuous verification at runtime, using a central policy decision point for each request.²

Protocols are starting to build this in. The Model Context Protocol’s authorisation rules, in specification version 2026-07-28, require tokens to be bound to the specific server they are meant for, forbid passing tokens through to other services, and encourage servers to ask for narrow scopes, meaning the specific permissions a token carries, and to request more only when a privileged operation is attempted.³ Its security guidance also asks servers to log each elevation with a correlation ID so it can be traced.⁴

Match Controls To Autonomy

Not every agent needs the same controls. AWS, in a vendor publication from November 2025, proposed an Agentic AI Security Scoping Matrix that sorts agents into four scopes by how much autonomy they have, and argues that controls should tighten as autonomy grows.⁵

The third column is our summary rather than AWS’s wording. The point is that an organisation should know which scope each agent falls into, because a read-only research assistant and an agent that starts its own payment runs should not share a control set.

Human Approval That Works

Human approval is a common answer to agent risk, and an easy one to get wrong. OWASP’s threat taxonomy (version 1.1, December 2025) lists overwhelming the human in the loop as a threat in its own right,⁶ and its ASI09 entry describes how a fluent, confident agent can persuade a person to approve something harmful.¹ An approval prompt that appears fifty times a day trains people to click yes.

The joint guidance offers several rules that help. Decisions about when approval is needed should be made by designers and operators, not left to the agent. High-impact actions should never run without prior approval; examples include system resets, network egress and deleting critical records. Requests to delete logs or audit records should be held until a person approves them. Actions should be classified by impact, likelihood and reversibility so approval is reserved for the ones that matter.²

Two further habits make approvals meaningful. Show the person the actual action and its target, such as the recipient address or the amount and account, rather than a summary written by the agent. Keep the number of approvals low enough that each one gets real attention.

Log For Accountability

Finally, an agent’s identity is only useful if its actions can be traced back to it. The guidance asks operators to monitor and log identity and privilege changes and audit them for drift and impersonation, to record which tools an agent used and what it retrieved, and to keep agents in enclaves with no write access to their own logs.² Google’s guidance for secure agents makes observability of actions and planning one of three core principles.⁷