The Real Moat in Agentic AI Is Authority, Not Models.

Most agentic-AI strategy conversations are still about models. Which one, how big, how fine-tuned. That is the wrong axis. Models are converging and commoditising on a timeline measured in months. Authority — the machinery that decides what an agent is allowed to do inside your business — is not converging at all. That is where the durable advantage sits.

Agent identity is splitting from non-human identity

For years, anything that was not a person got filed under non-human identity: service accounts, API keys, machine certificates. The assumption was that these things are static. You provision them, scope them once, rotate the secret, and move on.

Agents break that assumption in three ways. Their scope changes as the workflow changes. They act on behalf of a specific person, which means the delegation chain matters as much as the credential. And they make decisions, so the audit question shifts from what accessed this to what decided this and under whose authority.

Once those three properties are in play, the old category stops fitting. Agent identity becomes its own discipline with its own primitives.

What shipping first buys Microsoft

Microsoft moved on this before the category had a settled name, with Entra Agent ID giving agents first-class identity inside the same directory that already governs your people.

The technical merit matters less than the sequencing. Whoever ships the first credible primitive sets the vocabulary. Competing products get described in relation to it, buyers evaluate alternatives against it, and integrations are written to it. That is a position you cannot buy back later with a better feature.

For operators already on Microsoft, the practical consequence is that the identity layer for agents lands where your identity layer already is. That is a shorter route than assembling it.

Agent identity is separating from the non-human-identity category. Microsoft shipped first with Entra Agent ID. The 18-month window is open.

The delegation chain is the new primary key

An access log tells you a credential touched a record. That was sufficient when the actor was a person or a static integration, because the credential and the accountable party were the same thing.

Agents break the equivalence. An agent acts on behalf of someone, using permissions granted by someone, possibly triggered by a third party, inside a workflow owned by a fourth. The question an auditor asks is not which credential but under whose authority, and answering it requires the chain.

So the delegation chain becomes the object you have to model: who granted what scope, to which agent, on whose behalf, valid until when. Systems that only store the credential cannot reconstruct it after the fact, which is discovered during the first incident.

Why service accounts will not do

The fastest way to get an agent into production is to give it a service account with generous permissions. It works, it is invisible to governance, and it is how most agent estates actually start.

Three costs arrive later. Attribution disappears, because several agents share one identity and the log cannot separate them. Least privilege becomes impossible, since the account's scope is the union of everything any agent needed. And revocation becomes all-or-nothing, so withdrawing one agent's authority breaks the others.

The third is the one that bites. The whole value of scoped authority is being able to take it back surgically, and a shared account removes exactly that capability at the moment you need it.

Build for portability, not for a winner

Nobody should bet the estate on which agent-identity product wins. The defensible position is to hold the metadata any winner will require.

That list is short and stable: a unique identity per agent, a named human delegator, an explicit scope, an expiry, and a decision-level audit record. Every credible future standard will want these, whatever it calls them.

Operators who capture that from the start can migrate. Operators who do not are holding logs that answer the previous era's question, and the migration becomes a re-implementation rather than a mapping.

This is the cheap insurance available inside the window. It costs discipline at provisioning time and nothing else.

What to do while the window is open

Our read is that there is roughly an eighteen-month window before agent identity hardens into whatever it becomes. Decisions made inside that window are cheap. Decisions made after it are migrations.

The move is not to buy everything now. It is to make sure every agent you deploy in the meantime is built with an identity, a delegator and an audit trail, so that whatever the layer settles into, you have the metadata it will want.

What to do next

1. 01Inventory every agent and automation running today and record who delegated its authority. Most operators cannot produce this list.
2. 02Stop provisioning agents on shared service accounts. One agent, one identity, one named owner.
3. 03Decide your agent-identity position deliberately rather than inheriting it from whichever tool ships first internally.

← All Foundation insights