Agent identity is not a security problem

In most companies that already run an agent in production, that agent authenticates with a shared service account and an API key that never expires. The same account three other processes use, created years ago by someone who has since left, with no formal owner.

Nobody did their job badly. The pilot needed to read the CRM, requesting a new identity meant three weeks of tickets, and there was a credential sitting right there that already worked.

And it worked, which is the worst thing that could have happened.

Why this stops being anecdotal

Gartner projects that 40% of enterprise applications will embed agents by the end of this year, up from less than 5% last year. IBM found that security incidents involving shadow AI have more than doubled in a year, reaching 43%, and that two thirds of organisations have no process capable of detecting it.

A borrowed credential in a pilot is a shortcut anyone understands. The problem arrives when that shortcut becomes the usual way of connecting four out of every ten applications, without anyone having decided it.

How far the identity provider reaches

An identity provider does two things well: check who is calling, and check whether they have permission to call a particular place.

When the caller is an agent, the question you need to answer is a different one. This specific action, right now, in this case, is it one of the things the business has delegated to it?

The identity provider doesn’t know that, and no amount of product maturity will change it, because the answer depends on business rules that live somewhere else.

The two mental models we drag along

When we hand out permissions, an agent fits neither of them.

We give a person broad access because they have judgement and because, if they do something reckless, they answer for it. An application works the other way round: fixed script, always the same thing in the same order, and you can read its code and know what it is going to ask for.

An agent decides at runtime which sequence of calls to make, and the sequence is different every time. That is why permissions modelled on what it can call do not bound what it can do.

An agent with read permission on customers and write permission on invoices. Separately, both are reasonable, and separately both were approved. Combined, they allow issuing an invoice to a customer nobody wanted to invoice.

Nobody authorised that. Nobody forbade it either, because the permission was granted per endpoint and the risk appears in the combination.

What a permission has to name

“Can read customers” describes a surface. “Can check whether an invoice is reconciled” describes a complete business action, with a beginning and an end.

It looks like a difference in wording and it is a difference in architecture, because it changes where the control lives. An endpoint scope is defined at the identity provider. A capability is defined in the integration layer, the only one that knows that checking a reconciliation means four queries across three systems and a rule nobody ever wrote down.

That is the only point where you can actually apply the brake.

It is the same idea behind an agent needing capabilities named after the business rather than technical operations. I arrived at it from the usability side, since an agent chooses far worse when you hand it thirty operations named after tables. It turns out that decision was the governance decision all along.

The audit trail has to answer three questions

Recording that a token called an endpoint is useless in an audit. It is exactly what you already record today, and it has never helped you.

Look at what actually happens when somebody asks for something:

   Marta (accounts payable)
        │  asks: "check this vendor's invoices"
        ▼
   Assistant agent
        │  delegates: check_reconciliation(vendor=X)
        ▼
   Invoice agent
        │  invokes the capability
        ▼
   Integration layer  ──── this is where it's decided and logged
        │
   ┌────┴─────┬─────────────┐
   ▼          ▼             ▼
  ERP       Bank      Accounting

The one calling the ERP is the invoice agent. The one who wanted something is Marta, two hops further up. If all you keep is the call, you have lost the stretch that explains why that call was allowed.

Which agent, not which service account. With its own identity, distinguishable from the other two that share the same credential today.

On whose behalf. This is the one almost nobody records and the one you will be asked about. An agent almost never acts on its own: it acts because someone asked it to, or because another agent delegated the task.

Under what criterion. Which capability was invoked, with which parameters, and which rule allowed the invocation.

The difference in the record looks like this. What a normal system keeps today:

11:04:19  svc_integration  GET /api/v2/invoices?vendor=X  200

And what you need to be able to answer in an audit:

11:04:19
  actor        invoice-agent-03
  on behalf of assistant-agent-01 → [email protected]
  capability   check_reconciliation
  parameters   vendor=X, period=2026-08
  rule         accounts-payable/read-reconciliation

All three have to end up in a record the agent cannot modify, because a system that writes wherever it likes and then audits itself against that same record isn’t auditing anything.

Why this lands on you if you do integration

The identity provider issues the token. The integration layer decides how far that token reaches.

Every control that genuinely bounds an agent lives where the capability is defined: which operations exist, which parameters they accept, what gets recorded, and what requires a person to confirm it. And this isn’t a new problem: it is API governance, which we have been doing for fifteen years. What has changed is that the consumer no longer behaves the way we expected.

I say this with the reasonable doubt of someone looking at it from one side only, but I have the feeling the topic is falling entirely to security, and that it will stay half-solved there. Security can give you dedicated identities and short-lived tokens. None of that answers what the agent can do.

The agent that needs none of this

If it only reads, and it reads public data or data that compromises nobody, build it and move on: the cost of governing it exceeds the risk. And if you are exploring whether a use case makes sense, do it with fake data: identity gets designed once you know you are going to production.

What doesn’t work is the usual middle ground, the pilot that touches real systems with borrowed credentials and the promise of tidying it up later.

Where to start

Give the agent its own identity, neither shared nor inherited. That alone lets you answer what each one did, which today you cannot.

Make the permission expire, short-lived and scoped per task. An eternal token with broad permissions has the same control value as a password written on a sticky note.

Record the delegation, not just the call. Who asked what of whom.

And make the capability the unit. If you cannot list what your agent is allowed to do, you haven’t decided it yet.

In a few months someone from compliance is going to ask what exactly your agent can do against the company’s systems. The answer cannot be “it depends on what it decides”.

It has to be a list.

---

The full pattern for how those capabilities get exposed, and how a system distils them as it learns, is in MCP-Led: semantic integration for enterprise systems.