How to secure AI agent identities when they outnumber your people

Secure an AI agent's identity the way you would secure a contractor's access, not an employee's. That means no standing credentials, and a short-lived, scoped token issued for each job. Access is denied by default. The log is written by the system the agent calls through, not by the agent itself. Most access today is granted the other way, which is why agent identity has become one of the main security problems of 2026.

Why is agent identity suddenly a crisis?

Because the number of agents grew fast and the tools did not change.

Machine identities now far outnumber human ones, and the estimates vary by environment. KPMG's 2026 report puts the ratio around 80 to 1 in the average enterprise. Another 2026 identity security report puts it closer to 109 to 1, and figures for cloud-native companies are higher still. AI agents are pushing these numbers up faster than identity tools were built to handle. The number that says the most is about readiness: 92% of organisations say their current identity tools cannot manage AI agent identities.

What makes an agent identity different from a service account?

A service account is narrow and fixed. An agent is broad, and what it does changes from task to task.

A service account does one job with a fixed set of permissions that a human set once. An agent acts with intent and reaches across many tools in a single task. What it does is decided while it runs, instead of being fixed in advance. The Cloud Security Alliance calls the result a governance vacuum. The identities exist and hold real access, but no one is responsible for deciding what they may do or for how long. Attackers work in that gap.

Should an agent ever hold a raw credential?

No. This one rule does more than any other to limit the damage a leak can do.

An agent should never see a customer's real credential. It should get a short-lived, scoped token, like a valet key, issued for one job and expiring when the job ends. The real secret stays in a vault. It never appears in code, logs, traces, or the model's context. A leaked token is then worth almost nothing, because it only covers one job and has already expired. We wrote up the practical steps for one integration in giving an agent GitHub access safely. The same approach works for every tool.

Who owns an agent's access?

A person does, and the agent inherits it.

Access should belong to the human who authorised it. An agent can then reach only what that person could reach, and only the tools its contract named. Everything else is denied by default, and each denied attempt is logged instead of silently dropped. Enforce this at a single chokepoint that every tool call passes through. That is what an MCP gateway is for. It is the one place where a token is exchanged, a policy is checked, and a call is allowed or refused.

How do you prove what an agent did?

Write the log yourself, at the gateway. Do not rely on the agent to report on itself.

A log the agent writes about itself is only the agent's own account. The record you can rely on is the one captured by the system the agent called through. It is append-only and hash-chained, so any later edit can be detected. The difference between observing an agent and verifying it is the subject of governance versus observability versus verification. Verification lets you prove how an identity behaved, instead of hoping it behaved well.

Where do you start?

Four steps, in order. None of them needs a new model:

• Inventory. Find the non-human identities you already have. Most teams are surprised by the count, and by how many hold standing credentials.
• Scope. Replace broad grants with per-job permissions the contract names.
• Expire. Move from long-lived secrets to short-lived tokens that expire when the task ends.
• Log. Record every call at the gateway, including the refusals.

Cognibl does all four by default, so they are not a separate project. An agent connects through a gateway that issues scoped tokens, denies by default, and writes the trace. Identity, access and evidence live in one system, instead of three tools added after the fact. See how the trust layer fits together.