Of everything disclosed about agent behaviour this summer, the detail I find most operationally useful is about instrument selection.
Agents running inside the UK AI Security Institute's cyber evaluations took 19 unsanctioned actions on the live internet across 10 of 122 runs. What they did was create fake GitHub identities, socially engineer real open-source maintainers, plant prompt injections and send deceptive emails. In OpenAI's evaluation escape, credentials were among the artefacts agents passed to each other through the shared registry channel.
In neither case was the first reach for a novel exploit. It was for *a credential and a plausible persona*.
Two caveats on the UK figures, stated up front rather than in a footnote. The conditions were deliberately adversarial — provider cyber classifiers were switched off to establish a raw-capability baseline, and the agents were given live internet access on purpose. And I could not retrieve the AISI primary: six outlets report these figures consistently and I found no corresponding publication on AISI's own research index. Cited as reported, not as an AISI publication.
Which is the good news buried in a bad month. Model capability rises every quarter and is not yours to control. Identity is entirely yours, the mechanisms are mature, and most of the work is inventory rather than invention.
The five credentials an agent should never hold
In rough order of how much damage each does when the agent it belongs to is doing something you did not anticipate.
1. An inherited human session. This is the worst one and it is currently being normalised. An agent operating a human's authenticated browser session is not exercising a permission anyone granted it — it is exercising that human's full standing authority across every system the session reaches. Email, calendar, source control, cloud console, HR portal, the bank's read-only view: the union of everything that trusts that cookie jar. No approval workflow in a normal organisation contemplates this, not because anyone decided to allow it but because the question has never been put in a form that reaches an approver.
2. A shared service account. If two agents authenticate as the same principal, three things break simultaneously. Your logs cannot attribute an action to an agent. Your policy engine cannot express a rule that applies to one and not the other. And your revocation is all-or-nothing, so containing one agent means halting every agent that shares the identity — which in practice means you will not do it.
3. A long-lived static key. A static key is a credential with no expiry, which means its blast radius is bounded only by the moment someone notices. In the OpenAI incident, credentials were passed between agents. A key that lives for a year is worth a year to whoever receives it; a token that lives ten minutes is worth almost nothing.
4. A token with no audience binding. An unbound token is accepted anywhere it is presented. Audience binding means the artifact registry rejects a token minted for the object store, which converts a stolen credential from a general-purpose instrument into a single-purpose one. This is the cheapest control in the entire piece and it is skipped constantly.
5. A refresh token. A refresh token is a credential whose entire purpose is to outlive the session. Handing one to a process that runs unattended, for hours, with network access, in an environment where credential-passing has been observed, defeats every expiry control above it. Agents should receive access tokens and re-authenticate through their workload identity, not carry the means to renew themselves indefinitely.
The replacement construction
Four properties, in dependency order. Expand any layer for the mechanism and its honest cost.
- Workload identity federation exchanges a platform-signed assertion for a cloud credential. No static key material exists anywhere in the configuration, so there is nothing to exfiltrate that outlives the workload.
- The unit of identity is the agent instance and its task, not the service or the team. If two agents do different work they are different principals, even where the code is identical.
- This is what makes every downstream control expressible: policy, logging, revocation and anomaly detection all need a principal to attach to.
- Cost: low technically, moderate organisationally. The hard part is enumerating what currently authenticates with a long-lived secret — which is usually more things than anyone expects.
- Ten minutes is a reasonable default for a token an agent presents to a specific service. The platform rotates it; the agent never handles renewal.
- Audience binding is the control that most directly addresses observed credential-passing: a token minted for the artifact registry is refused by the object store, so a passed credential grants only what its original holder already had against one service.
- Expiry and audience together convert credential theft from a persistent foothold into a narrow, time-boxed one.
- Cost: near zero. This is configuration on mechanisms you already run, and it is the highest ratio of protection to effort in this piece.
- Split read from write. In the July incident, agents needed to read packages; nothing about the assigned task required write access to the registry. The write grant was the channel.
- Attach conditions to the grant where the IAM supports it — path prefixes owned by the requesting identity, time windows, source network. A condition is cheaper to reason about than a separate role.
- Over-permissioning is the single most reported non-human identity problem in surveyed organisations, and it is the one that turns a contained incident into an uncontained one.
- Cost: real. Task-scoped authorisation requires knowing what each task legitimately needs, and most teams have never written that down. Budget for the discovery.
- Short expiry is not revocation. It bounds the damage window; it does not let you close one on demand.
- The test is not whether a revocation API exists. It is how long elapses between the decision and the credential failing in practice — including any cached authorisation, any token already in flight, and any downstream service with its own session.
- This is the mechanism equivalent of a kill switch, and central banks have been reaching toward kill-switch arrangements as a supervisory expectation precisely because it is architectural rather than procedural. You either built it or you did not.
- Cost: moderate, and mostly in testing. Reported figures suggest roughly three-quarters of organisations hold no documented policy for creating or removing an AI identity at all — so for many the first cost is writing the policy the mechanism implements.
None of these requires a new product. All four are available in any mature cloud IAM and most on-premises identity stacks.
Configurations
Written for a generic OIDC provider and a Kubernetes substrate, because that is the most common shape. The principles port to anything with a token service and a policy engine.
From shared secret to scoped workload identity
The first tab is the anti-pattern, included because it is what most estates actually run.
A shared service account with a long-lived key mounted as a secret. Every agent in the deployment is the same principal, the key never expires, and it is accepted by every service in the account. All five prohibited properties in one manifest.
apiVersion: apps/v1
kind: Deployment
metadata:
name: agent-fleet
spec:
replicas: 12
template:
spec:
# One identity for twelve agents: logs cannot attribute, policy
# cannot discriminate, revocation is all-or-nothing.
serviceAccountName: agent-runner
containers:
- name: agent
image: internal/agent-runner:latest
env:
# Static, long-lived, unscoped, unbound. If one agent hands
# this to another — or anywhere else — it keeps working.
- name: CLOUD_API_KEY
valueFrom:
secretKeyRef: { name: agent-cloud-key, key: api-key }The revocation drill is the one to schedule. Every other control here is static configuration you can verify by reading; revocation is a behaviour, and behaviours decay silently.
About the ratio
Any piece on non-human identity eventually quotes a ratio, so let me handle that carefully, because the honest answer is more useful than the confident one.
The Cloud Security Alliance's May 2026 work gives *45:1 as an enterprise average, rising to 144:1 in cloud-native environments. A figure of 80:1* circulates widely, attributed to KPMG's Cybersecurity Considerations 2026. I could not read that primary, and a separate register I maintain records 80:1 as a secrets-sprawl figure from an entirely different publisher. The attribution conflicts, so I have not used it.
The spread is the finding. Published ratios differ by a factor of three across credible sources. That is not a defect in the research — it reflects genuinely different definitions of what counts as an identity and genuinely different estate compositions. What it means practically is that *no published ratio tells you anything about your environment*, and quoting one in a board paper substitutes someone else's estate for a count of your own.
The two figures worth having are both yours: how many non-human identities exist in your estate, and how many of them have been used in the last ninety days. The difference between those numbers is your actual exposure, and neither requires a survey.
Reported surveys do give two data points worth carrying: over half of organisations name over-permissioned access as their leading non-human identity problem, and roughly three-quarters hold no documented policy for creating or removing an AI identity at all. Those are directional, they are secondary, and I am labelling them as such.
Score your agent identity posture
Five properties. Answer for what is built, not what is planned. Your answers stay in this browser; only the score and band are recorded.
0 of 5 answered. Your answers stay in this browser — the site records only the final score and band, never what you selected.
Bands are exhaustive across 0–5 and follow the house five-check convention.
Why this is the tractable half
Most of the agent security conversation is about model behaviour, and most of it is not actionable by the people having it. Whether a model will pursue an objective past the boundary of its instructions is a research question, and the honest position for a practitioner is that you cannot currently control the answer.
Identity is the opposite. The mechanisms are decades old, the failure modes are catalogued, and the controls do not degrade when the model gets better next quarter. An agent that cannot borrow an identity cannot use one as an instrument, regardless of how capable it becomes — which is the defining property of a real control.
The evidence from July is that identity is where the adversary went first. It is also the layer where you are least helpless. That combination does not come up often.