AI agent identity is a distinct, verifiable account for a software agent that acts on its own. It sits apart from the person who deployed the agent and apart from the shared service accounts most firms use to connect one system to another. Giving an agent its own identity keeps a record of which agent did what, under whose authority, and inside what limits.

This matters now because firms are handing agents access to client ledgers using credential models built for two other things. One model was built for people. The other was built for stable background services that do the same job every night. An agent is neither. It decides at runtime which system to call next, so the permissions you set on Monday do not describe what it does on Thursday.

The honest state of things: standards bodies opened this work between December 2025 and February 2026. Operational guidance built specifically for agent systems is still in development. If you are running an agent against client data this year, you are ahead of the controls designed to govern it. You can manage that. You would rather not discover it during a review.

What AI Agent Identity Means

An agent identity is an account that belongs to the agent itself, with its own identifier, its own permissions, and its own record of what it did. The alternative, which is what nearly everyone starts with, is to let the agent borrow something: a staff member's credentials, or a service account, or an API key pasted into a configuration file.

The difference shows up in how each kind of account behaves. A person logs in, does a set of things a reviewer would recognise, and logs out. You can ask them what they did.

A service account runs the same job on the same schedule. Its behaviour is predictable enough that you can scope its permissions tightly and leave them alone for a year.

An agent looks like the second one on the org chart and behaves like the first one in practice. It reasons about a goal, picks its own path, and calls whichever system that path requires. Nobody wrote that path down in advance, including the people who built it.

Microsoft's own documentation for its agent identity product names the gaps this opened: telling agent operations apart from workforce and workload operations, sizing access correctly across systems, keeping agents out of the most sensitive roles, and managing identity at a scale where agents get created and destroyed quickly. A vendor conceding that its previous model did not fit carries more weight than any outside assertion.

Researchers describe an agent identity as more than a label. It carries the agent's origin, its purpose, what it is capable of, and any attestations about it. Agents also belong to a broader class of non-human identity, and they go on to control other non-human identities: API tokens, service accounts, and workload credentials of their own. One identity you did not track turns into several.

The Service Account Shortcut, and What It Costs You

A firm decides to automate reconciliation, or document intake, or the mechanical half of the close. IT needs to connect the agent to the ledger and the document store, so they provision it the fastest way available. Usually that means a service account, sometimes a set of API keys shared with the tool, occasionally a real person's credentials because that was the only way to get the integration working before the deadline.

It works. The reconciliation runs. Everyone moves on. Then, seven months later, somebody asks who posted a particular entry. The log says the service account posted it.

Three things break in that setup, and they break at different speeds. Attribution goes first, and quietly. The action still happened, the record still exists, and the record no longer connects to a person. Nobody notices until somebody asks.

Scope goes second. A service account provisioned for one workflow gets borrowed for the next one, because it already has half the access needed and requesting a new account takes two weeks. Six months on, that account can reach systems nobody would have approved in a single request.

Revocation goes last, and it goes at the worst possible moment. You need to stop one agent. You find that stopping it also stops the nightly export and two integrations that were sharing the same credentials.

The part worth saying plainly: this is not carelessness. It is what the tooling makes easy. A researcher who documented a production deployment in regulated finance put the problem where it belongs, noting that current agent frameworks leave auditability, least-privilege authorisation, and boundary enforcement to whoever happens to be deploying the system. The framework ships. The accountability layer is homework.

The Three Questions an Identity Has to Answer

Strip away the protocol detail, and the standards work comes down to an argument about three questions. Any workable answer has to handle all three.

Who is this agent?

The agent needs an identifier that survives a restart, belongs to it alone, and differs from the identifier of the person who deployed it.

That sounds obvious until you look at how agents get run. A close agent that runs every month is a long-lived thing with a continuous history. A research agent someone spins up for one engagement and discards is not. Both need identity, and they need different kinds. The long-lived one needs a thread you can follow across months. The short-lived one needs a record that outlasts the agent itself, because the agent will be gone before anyone asks about it.

What is it permitted to do?

Permissions have to be checked when the agent acts, not granted once when someone set it up.

The OpenID Foundation's authorisation working group is building for exactly this. One of its drafts addresses what should happen when policy cannot authorise an action yet, because something has to happen first: an approval, a consent, a delegated authority, an attestation. That is a standards body writing the human checkpoint into the protocol itself, which tells you the checkpoint is not a workaround for immature technology. It is part of the design.

Who authorised it, and can you show that later?

This is the question your reviewer asks, and it is the one the research community has spent the most effort on.

A position paper presented at ICML in 2025 proposed a structure worth understanding even if you never touch the implementation. Three pieces of evidence travel together: a token identifying the person, a token identifying the agent, and a delegation token signed by that person which references both, states what the agent may do, and carries an expiry and a way to revoke it.

In plain terms, it is a receipt. It shows which person authorised which agent to do which specific thing, and when that authority runs out. That is the artifact you want to be able to produce, whatever the underlying technology ends up being called.

One consequence is worth stating once, because it shapes the buying decision more than any feature comparison. A firm that owns its implementation decides where these boundaries sit. A firm running someone else's platform inherits whatever answer that platform's engineers arrived at, and usually learns what the answer was during an incident.

Where the Standards Stand Today

The work started. It is real. It is not finished. Anyone telling you otherwise is selling something.

In December 2025, the OWASP GenAI Security Project published its first list of the ten most serious risks in agent systems. Identity and privilege abuse landed third. Worth pausing on that placement: OWASP lists are built by working security practitioners arguing from what they see in production, and more than a hundred of them contributed to this one. Third place means that when people who break into systems for a living compared notes, identity came up more often than supply chain problems, more often than memory poisoning, and more often than rogue agents. Only goal hijacking and tool misuse ranked higher.

In February 2026, the NIST National Cybersecurity Center of Excellence published a concept paper on applying identity standards to software agents, and asked the public what they thought. The comment period closed that April. A concept paper is not guidance. It is a government lab saying it intends to work on a problem and asking practitioners to describe the problem first. What NIST asked about is instructive: how to identify agents, how to authorise them, how to audit them, and how to handle non-repudiation, which is the formal name for being unable to deny that you did something.

The Model Context Protocol, the standard most agent tooling now uses to connect agents to systems, revised its specification in July 2026 with authorisation as a focus. Its maintainers noted that authorisation is where implementers spend most of their integration time. The revision closed a hole that let an attacker confuse a client about which authorisation server it was talking to.

The agent-to-agent protocol moved to the Linux Foundation in June 2025 for neutral governance, and now supports cryptographically signed agent cards, so a system can verify what an agent claims about itself before trusting it.

Read the right column, and you get the picture. The vocabulary exists. The protocols are stabilising. The operational controls written specifically for agent systems, the ones your IT director would hand an auditor, are still being drafted.

What This Looks Like When It Fails

The clearest example on record is not an AI agent, and saying so is more useful than reaching for a shakier one.

In August 2025, Google's threat intelligence team documented a campaign in which attackers used stolen authorisation tokens belonging to a third-party integration to reach customer data across a large number of organisations through the API. Two details carry the lesson. The tokens were already trusted, so multi-factor authentication and the usual user controls never came into play. And as the investigation widened, the advice hardened into treating every token stored in or connected to that platform as compromised.

That was an integration, not an agent. The failure mode is the same one, an architectural generation earlier: a non-human identity holding standing credentials, trusted by everything it touched, with a blast radius nobody had mapped in advance. Agents make it worse in one specific way. An integration does what it was built to do. An agent decides.

OWASP's own review of the first quarter of 2026 describes the shift bluntly, characterising a move from theoretical risk to real exploitation, with attackers going after agent identities and orchestration layers rather than model outputs. That comes from a volunteer security project rather than a company selling a remedy, which is why it is worth quoting rather than the survey numbers circulating alongside it.

What to Put in Place Before the Standards Land

Five decisions. All of them are about identity and attribution, and none of them require you to wait for anything.

Give every agent its own identity. Not a person's credentials, not a shared account. If two agents authenticate as the same thing, you have one agent as far as your records are concerned.

Record who authorised what, and for how long. Which named person approved which agent to perform which action, with an expiry date. Even a maintained document beats nothing, and it forces the conversation about who is accountable.

Scope permissions to the workflow the agent was built for. When the next workflow arrives, re-scope rather than add. Accumulated permissions are how a reconciliation agent ends up able to reach payroll.

Test revocation before you need it. Turn one agent off in a controlled window and find out what else stops. Every firm assumes this is a single action. Some are right.

Put the agent in the access review now. Not after the reviewer asks. Adding it yourself, ahead of the request, changes the conversation from a finding into a demonstration that you were paying attention.

Runtime monitoring, governance structure, data handling, and vendor selection are four separate problems with four separate answers. Each deserves its own treatment rather than a paragraph here.

How Codebridge Approaches This

Codebridge came out of KPMG, which shapes how we think about this more than any technical preference. Auditors ask who did what and under whose authority. That question does not soften because the actor is software.

We deliver implementation as a service rather than a product, and the client owns the code. That ownership is the part that matters for everything above. When you own the implementation, where the identity boundary sits is your decision, revisited when your obligations change. When you run someone else's platform, the boundary is wherever their engineering team put it, and you find out during an incident.

The way we work: a fixed-fee three-week discovery, prototyped on your own data rather than on a sample dataset, with fixed dates. You keep what we build.

If you are weighing an agent against a client-facing workflow and the accountability question is the part that stalls it, book a 30-minute call and we will work out whether your workflow fits a three-week prototype.