Non-Human Identity Is the Real Perimeter for Enterprise AI Agents

In the last fortnight of July 2026, two parts of the stack that rarely coordinate reached the same conclusion within 48 hours.

On 28 July, the Model Context Protocol shipped a spec revision that quietly rebuilt its authorization story. Authorization servers should now return the iss parameter per RFC 9207, and clients must validate it before redeeming a code — closing the authorization-server mix-up attack. Dynamic Client Registration was deprecated in favour of Client ID Metadata Documents, with a twelve-month transition window. Credentials are now bound to their issuing authorization server, so a stolen one does not travel. Enterprise Managed Authorization moved into a formal extensions framework.

On 30 July, Okta signed a definitive agreement to acquire Permiso Security — roughly USD 200 million, almost all cash, closing in Q3 of Okta’s FY2027. Permiso does identity threat detection across human, non-human and agentic identities in multi-cloud environments, and the word that matters in every description of it is post-authentication. Two days earlier, Cyera signed a letter of intent to acquire Oasis Security for around USD 1 billion, mostly cash with the remainder in shares, on an explicitly agentic thesis.

Read those together. The protocol layer hardened how an agent proves who it is. The identity vendors spent well over a billion dollars watching what an agent does after it has proven it. Nobody spends that on a problem authentication alone solves.

Meanwhile, almost every enterprise agent in production today authenticates with a shared service account, a long-lived key in a secrets manager, and no per-action attribution back to a human being.

An agent is neither a user nor a service#

This is hard because our identity primitives do not model what an agent is. A user is a persistent principal with stable entitlements, an interactive credential, and a human who can be asked to re-authenticate. A service is a persistent principal with a static role, no human behind it, and a credential rotated on a schedule measured in months.

An agent is neither. It acts on behalf of a human principal, with a subset of that principal’s authority, for a bounded task, over a lifespan measured in seconds, then it should cease to exist as a security subject. Four properties — delegation, attenuation, task scope, ephemerality — and no primitive in a standard IAM deployment carries all four.

So teams reach for the nearest shape, a service account, because it is the one that does not require a human in the loop. The moment you do, you have thrown away the delegation and the attenuation — the only two things keeping the blast radius small.

The Hospital Management System case#

The failure is clearest in a domain where the access boundary is not negotiable. Take an agent inside a Hospital Management System that summarises a patient’s record before a consultation — last three encounters, current medications, recent labs, drafted into a one-paragraph brief. A genuinely good use of the technology, and exactly the kind of Operational Automation that pays for itself inside a quarter.

Now: which records may that agent read?

The correct answer is whatever the requesting clinician may read, and nothing more. A consultant in cardiology has a different boundary from an intern on rotation, and both differ from the records clerk. Those boundaries already exist in the HMS, enforced at the application layer, audited, and in most jurisdictions legally load-bearing.

The answer you get in practice is whatever the application’s service account may read — every record in the system, because the per-user checks live in the application layer and the agent runs underneath it. The clinician’s boundary is now advisory. It holds only as long as the prompt, the retrieval filter and the tool definitions all behave. That is not an access control; that is a convention.

The same shape appears everywhere once you look. An agent in a School ERP drafting parent progress summaries needs the class teacher’s boundary, not the ERP’s. An agent querying customer Data Platforms for a support rep needs that rep’s region and account scope, not the warehouse principal’s blanket read.

The primitives that do exist#

Most of what you need has been standardised for years and is sitting unused.

Token exchange (RFC 8693) is the delegation primitive. Before invoking the agent, the application exchanges the user’s token at the authorization server for one whose subject is still the user, whose actor claim is the agent, and whose scope is narrower. The result carries act — a machine-readable statement that this agent is acting on behalf of this human. Downstream services authorize against the subject and log against both.

This is the difference between an agent that has permissions and one that borrows them. Borrowed permissions expire, cannot exceed the lender’s, and leave a trail naming the lender.

Short-lived credentials. If a token lives 90 seconds, exfiltrating it is worth much less. Every cloud provider has had workload identity federation for years — the OIDC-token-for-temporary-credential swap that removes static keys entirely. The blocker is never the technology. It is that someone must own credential lifecycle for a fleet of agents that did not exist eighteen months ago, and no team’s remit covers it.

Scope to the task, not the role. The change most teams resist, and the one with the highest return. Do not mint a credential scoped to records:read. Mint one scoped to records:read for patient_id=X, valid for one consultation, issued when the clinician opens the chart. The authorization decision moves from provisioning time to invocation time — the only point at which you know what the task is.

Per-invocation audit records that name the human. If your log says a service account read 400 patient records at 09:14, you have logged nothing of forensic value. If it says agent summariser-v4 read patient 8871 on behalf of Dr Okonkwo under task token t-9f2, you have an answer to the only question anyone asks after an incident.

Why post-authentication detection is the interesting half#

Here is what the Okta and Cyera deals are actually pricing. Do all of the above properly and you still have a gap authentication cannot close: the credential is legitimate and the behaviour is not.

A prompt-injected agent holding a valid, correctly attenuated, thirty-second token is still a valid caller. It passes every check at the gate. It then reads 200 records in a pattern no clinician has ever produced — breadth without depth, no dwell time, alphabetical by surname. That is not an authentication failure. It is a behavioural anomaly by an authorized principal, and the only place to catch it is downstream of the gate.

That is why Permiso’s positioning is post-authentication, and why detection is being bought rather than built. Signature-based rules fail here because there is no signature — the request is well-formed by construction. You need a behavioural baseline per agent identity, which requires that agent identities be distinct. Which brings you back to the shared service account. The detection layer is not an alternative to fixing identity; it is a thing you cannot build until you have.

Agent-to-agent, where it gets genuinely ugly#

Now let the summarising agent call a second agent to fetch lab results. The delegation chain is user to agent A to agent B, and three properties must hold: agent B can see the original human principal, agent B’s scope is a subset of agent A’s, and the audit record reconstructs the full chain. RFC 8693 nests actor claims for exactly this, and almost nothing in the wild implements the nesting correctly.

The failure mode is worse than confused deputy. It is scope laundering: agent A holds a narrow token, calls agent B which holds its own broader service credential, and the narrow scope evaporates at the hop. The user’s boundary was enforced at the first call and discarded at the second. Every multi-agent AI implementation I have reviewed this year has had this bug, and none had a test for it.

If you build one thing this quarter, build that test: assert that a downstream agent cannot reach a resource the upstream human principal cannot. A dozen lines. It will fail on the first run.

Against the superset shortcut#

The most common shortcut in production is granting the agent a permission superset “so it doesn’t fail”. It is understandable — a permission-denied error at 2am looks like an outage, and a broad grant makes the demo work. It is the wrong trade, for a reason specific to agents. In a conventional integration a superset grant is latent risk: the code path either exists or it does not, and you can read it. With an agent, the code path is generated at runtime from natural language, so the full grant is not latent — it is reachable, by anyone who can influence the input. You have widened the attack surface to the size of the permission set.

Let it fail instead, loudly, with a denial naming the missing scope, and treat each denial as a scoping bug. That is slower for a fortnight and correct forever. Teams that take the shortcut discover the cost when their first incident cannot be scoped, because the audit log names a service account that touched everything.

Where to start#

Inventory the agent identities in production and count how many are distinct. Most organisations find one credential behind a dozen agents. Split them — you cannot baseline behaviour or attribute an action to a shared identity.

Then take your highest-privilege agent and make one call on its path use a token-exchanged, task-scoped, short-lived credential end to end. Not the fleet. One call. The plumbing is the same for all of them, and it will surface every place your architecture assumed a persistent principal.

The protocol layer has done its part. The identity vendors are buying the detection layer. The delegation model in the middle is the part nobody can buy for you.

---

Running agents on a shared service account is a decision you make once and discover later. If you are putting agents into a clinical, financial or student-records system and want the identity model right before the audit, talk to us.