AI Agent Identity: Least Privilege and a Kill Path per Agent

AI agent identity means every agent that acts in your systems gets its own credential, task-scoped permissions and a way to switch it off alone. An agent running on a shared API key is an employee with no name, no manager and every door key: you cannot tell what it did, limit what it can do, or stop it without stopping everything else. This piece is for the CTO wiring agents into business systems and the owner or compliance lead signing them off. It sets out a five-stage lifecycle, the revocation detail most guides skip, and what the protocols leave to you.

On 28 July 2026 the Model Context Protocol (MCP), the open standard many agents use to reach tools and data, shipped a revision that hardens its authorization rules. In August, the OWASP Top 10 for LLM Applications 2026 moved "excessive agency" from sixth place to third.

Why is a shared API key riskier for an agent than for a script?

A shared API key is riskier for an agent because a script repeats the same steps, while an agent picks its tools based on whatever it reads. OWASP's LLM03:2026 Excessive Agency entry (August 2026) names the trigger: manipulated output, including prompt injection from "a malicious/compromised peer agent."

An API key is a long-lived password one program uses to call another. A scope is a named slice of permission, such as "read invoices" without "pay invoices". Prompt injection is hidden text in an email, page or document that tricks a model into obeying the attacker.

A reporting script with an admin key is dangerous only if someone steals the key. An agent with the same key is dangerous whenever it reads something hostile, because the attacker no longer needs the key. They need the agent to read one poisoned invoice. OWASP traces the damage to "excessive functionality, excessive permissions, excessive autonomy". Its example of the second is a tool meant to read data that connects "using an identity that not only has SELECT permissions, but also UPDATE, INSERT and DELETE permissions."

Speed and persistence make it worse: an agent calls tools at machine speed, and keys pasted into configuration files outlive the project.

The quieter cost is attribution: when three agents share one key, every log line looks the same. The MCP project's own security best practices describe this blind spot for token passthrough, where a server forwards a client's token instead of holding its own: the server "will be unable to identify or distinguish between MCP Clients", which makes "incident investigation, controls, and auditing more difficult." A shared key leaves the same gap: nobody can answer "which agent did this?", and our guide to agent audit trails shows why that question comes first.

What should an AI agent's identity include?

An AI agent's identity should be unique, accountable to an owner, registered in one catalogue, and carry scoped, time-bound authority. That is the interim practice in IMDA's Model AI Governance Framework for Agentic AI, version 1.5, published 20 May 2026 and updated 5 June 2026, which ties each identity to "a supervising agent, a human user, or an organisational department."

This is general information, not legal advice. IMDA's framework is voluntary guidance, and on authority it is specific: authorisations "should generally be scoped, time- or session-bound, non-transferable, and follow the principle of least privilege by default, with explicit escalation paths for elevated permissions." It wants identities differentiated by capacity: acting alone or for a named user. And it offers a ceiling "as a rule of thumb": the human user "should not be able to set permissions for the agent greater than what the human user is himself authorised to do."

OAuth, the authorization framework most identity providers implement, already has a field for that split: Token Exchange (RFC 8693) defines an "act" (actor) claim, so one token names the user as subject and the agent as actor.

Singapore's Cyber Security Agency (CSA) goes further. Its Securing Agentic AI addendum (version 1.0, published 17 June 2026, "not mandatory, prescriptive nor exhaustive") tells system owners to "Treat agents as non-human identities", maintain a "trusted registry of agent identities", and "Use short-lived, rotating credentials (ephemeral credentials) that expire immediately after agent use."

CSA also allows "unique identities per agent or agent class". Our rule: any agent that differs from another in tools, data or owner gets its own identity. A class identity fits only identical copies, such as ten instances of one reply bot, and each run still needs its own short-lived token so the log can tell them apart.

Here is where each instrument sits; binding law and voluntary guidance carry different weight with an auditor.

The PDPC's Protection Obligation requires "reasonable security arrangements" to prevent "unauthorised access". Nothing says agent. But once two Singapore agencies describe per-agent identity as good practice, a shared admin key in front of customer data becomes harder to defend as reasonable. That is our reading, not a ruling.

For financial institutions, MAS's Technology Risk Management Guidelines ask institutions to "manage and monitor the use of system and service accounts for suspicious or unauthorised activities" (paragraph 9.2.2). An agent calling core systems on a service credential belongs in that process. The guidelines do not define an agent or require one identity per agent; that design comes from the IMDA and CSA documents.

The agent identity lifecycle: provision, scope, rotate, monitor, revoke

The agent identity lifecycle has five stages: provision, scope, rotate, monitor and revoke. Provision one identity per agent with an owner and an end date. Scope it to the tools its task needs, replace stored keys with short-lived tokens, and log every call against that identity. Then make one agent revocable without stopping the others.

Each stage in operator terms (time limits are our design suggestions, not figures from any standard):

Expiry is not revocation. A 15-minute token in a hijacked agent is 15 minutes of damage, and a system that checks signatures locally, without asking the issuer, keeps accepting it until it lapses. A working kill path has three parts: disable the identity where tokens are minted, make the systems the agent calls refuse its outstanding tokens, and stop the process itself. CSA's addendum names the trigger: logs streamed to security monitoring "with processes in-place to revoke agent access when anomalous access is detected."

The standards for the second part exist. OAuth 2.0 Token Revocation, RFC 7009, defines how to revoke a token at the issuer, and Token Introspection, RFC 7662, lets a receiving system ask the issuer whether a token is still active. One detail catches teams out: revoking an access token does not reliably kill the refresh token, the longer-lived credential that mints new access tokens, because RFC 7009 makes that optional. Revoke the refresh token, and the issuer "SHOULD also invalidate all access tokens based on the same authorization grant."

Introspection costs one extra network call per request. Our rule: for read-only scopes, short expiry is enough. For any scope that moves money, edits master data or exports customer records, check each token with the issuer, so a revocation bites on the next call.

What do MCP and A2A settle, and what do they leave to you?

MCP and A2A do not choose your permissions or give you a kill path. MCP, where you implement its authorization specification, settles how a client gets a token and how a server rejects tokens not issued for it. A2A, which joined the Agentic AI Foundation in August 2026, leaves identity to standard web authentication and calls authorization logic "implementation-specific".

Start with MCP. The 2026-07-28 release adds issuer validation under RFC 9207 (a defence against a fake authorization server), binds client credentials to the issuer that minted them, and formally deprecates dynamic client registration in favour of client metadata documents published at a URL.

Under the authorization specification, a server must reject any token not issued for it, and "MUST NOT accept or transit any other tokens." That forbids token passthrough: forwarding one token from system to system.

Then the parts generic coverage skips. Authorization "is OPTIONAL for MCP implementations." Local servers using the STDIO transport, where the server runs on the same machine as the agent, "SHOULD NOT follow this specification, and instead retrieve credentials from the environment." So a local MCP setup runs on whatever key sits in an environment file, which is the shared-key pattern this post is about.

Scopes have a trap too. When a server issues no scope challenge, the client falls back to requesting "all scopes defined in scopes_supported." The specification intends that list to be "the minimal set of scopes necessary for basic functionality", so a server owner who publishes every scope there hands every new client every permission. The project's guidance calls "wildcard or omnibus scopes" a common mistake.

A2A is the protocol agents use to work with other agents. The Agentic AI Foundation, the Linux Foundation body that already hosts MCP, announced A2A as a hosted project on 17 August 2026, and the A2A project's own post followed on 27 August. The A2A specification (version 1.0.0) says identity "is handled at the protocol layer, not within A2A semantics." It is blunt about one case: a task that pauses in the TASK_STATE_AUTH_REQUIRED state because it needs further authorization. Section 7.6.4 says of that state:

"The A2A protocol does not define the scope, representation, validity, or revocation semantics of the authorization decision or credential obtained in response to this state."

The scope and lifetime of any mid-task grant are yours to define and revoke. Where credentials travel along a chain of agents, section 7.6.3 says they "SHOULD be bound to the agent which originated the request." Agent Cards, an agent's public self-description, "MAY be digitally signed". May, not must. Checking that signature, and deciding what an outside agent may ask for, are your jobs. Our plain-English protocol map covers how the four agent protocols fit together; it predates both the July MCP revision and the A2A move.

Illustrative example: scoping an accounts-payable agent

Least privilege for an accounts-payable agent means it can draft payments but cannot edit supplier bank details or release money. When a poisoned invoice arrives, the scoped design fails safe and one identity is revoked. The shared-key design pays the attacker.

Illustrative example: a 40-person distributor runs three agents: one processes supplier invoices, one answers customer order queries, one builds weekly sales reports. All three call the ERP (the core finance system) with one admin API key stored in a configuration file, never rotated.

Hidden text in a PDF invoice tells the agent the supplier has changed banks and to update the details before scheduling SGD 48,000 in payments. With the shared key, nothing stops it. When finance spots the change a week later, the log shows "admin key, PUT /suppliers/2231". Revoking the key stops customer service and reporting too, so the team hesitates for a day.

Now the scoped version. The invoice agent has its own identity, owned by the finance manager. Its scopes are: read invoices, read the supplier list, create draft payments. It cannot edit supplier records, and any payment over SGD 5,000 waits at a confirm step for a person. The attempted bank change returns "insufficient scope", which raises an alert. The on-call engineer disables that one identity and revokes its refresh token in under five minutes. Customer service and reporting carry on. Nothing is paid.

The example forces one decision: which scopes to deny. Edit-supplier and release-payment are the two that turn one poisoned PDF into lost money. For the CTO, the work is mostly in the ERP: splitting one admin role into narrow roles behind a token issuer. For the MD or owner, the trade is a few days of engineering against an unrecoverable payment. For compliance, the scoped log shows who acted, for whom, under which permission.

Where Origin Pi stands

We treat agent identity as the first design decision in an agent project, because every other control depends on it. You cannot bound permissions for an agent you cannot name, tie an approval at a confirm step to it, or keep an audit trail that says which agent acted.

So in the agent-ready layer we build, each agent gets its own identity and owner plus a short list of scopes, and every call passes a policy check that knows who the agent is acting for. Bounded permissions live in the systems the agent touches, never in its prompt: the line IMDA draws when it prefers access controls "that prevent the tool from being called by the agent at all." Cerebrum, our governed record, is in build; it is designed to keep each identity next to its grants and decision records.

Your first step this week: list every credential your agents use, and for each one ask what else stops working if you revoke it. Any answer other than "nothing" is your first fix.