You would not let a new employee into your systems without a login, a manager, and a record of what they touched. Yet that is exactly how most enterprises are running AI agents right now. The agent gets a shared API key, broad access, and no audit trail, then it goes to work on real data. The model is rarely the thing that fails. The missing ID card is.
What you need to know
- Agents are shipping faster than they are governed. 78% of organisations reported an AI-related security incident or vulnerability in the last six months, and only half run a formal governance programme (DigiCert, 2026).
- The gap is identity. Only 21.9% of teams treat AI agents as identity-bearing entities; 45.6% still let agents authenticate with shared API keys (Gravitee, 2026). A shared key is a building with no name badges: when something goes wrong, you cannot say who did it.
- This is an access-control problem, not a model problem. Give every agent a unique identity, least-privilege access, and a full audit log, the same three things you already require of a human user or a service account.
- Two 2026 incidents show the cost. Moltbook exposed roughly 1.5 million credentials from an unsecured database, and Ruflo (CVE-2026-59726, CVSS 10) let an unauthenticated request run commands inside an agent platform. Both were identity and access failures, not clever model attacks.
- Do the four controls in this guide before an agent reaches production. Identity, scoped permissions, secrets handling, and logging. If you cannot answer the ship-blocker question for each, it is not ready.
78%
of organisations reported an AI-related incident or vulnerability in the last six months
Source: DigiCert, State of Digital Trust 2026
21.9%
of teams treat AI agents as identity-bearing entities
Source: Gravitee, State of AI Agent Security 2026
45.6%
of agents still authenticate with a shared API key
Source: Gravitee, State of AI Agent Security 2026
Why agents slip past the controls you already have
An AI agent is a new kind of actor, and your access model does not have a slot for it. It is not a person, so it never gets provisioned through HR and onboarding. It is not a traditional service, so it skips the review a new integration would face. It lands in the gap between the two, and the gap is where the controls live.
So the agent gets whatever was fastest: a developer's key, an admin token copied from a runbook, a service account with far more access than the task needs. It works on the demo, so it ships. Gravitee found that only 19.7% of teams said all their agents were fully secured and governed before going live, and that on average 48% of agents already in production run without monitoring. The agent is doing real work on real data, and no one can say precisely what it is allowed to do or what it has done.
The uncomfortable part is that this is a solved problem for everything else. You would never give a contractor your CEO's password. You already run identity, least privilege, and audit for people and for machines. Agents just arrived faster than the process that would have caught them, a pattern we set out in the hard part of agents isn't the model.
What an ID card means for an agent
An ID card is three things a human user or a service already has, and a typical agent does not. Put plainly: a unique identity so you know who acted, scoped permissions so it can only do its job, and a log so you can reconstruct what happened. Here is the gap, side by side.
| Control | A human employee | A typical AI agent today |
|---|---|---|
| Unique identity | Named account, provisioned and de-provisioned | Shared API key, no owner |
| Access scope | Least privilege, tied to role | Broad access, whatever was fastest |
| Credentials | Rotated, stored in a vault | Hard-coded or copied from a runbook |
| Audit trail | Every action logged to the person | Actions logged to the key, not the agent |
| Off-boarding | Access revoked on the day they leave | Key lives on, often forgotten |
The point of the table is not that agents are dangerous. It is that we already know how to govern an actor with system access. We are simply not applying it to this one.
The four controls to ship before production
Do these four before an agent touches production data. Each has a ship-blocker question: if the honest answer is no, the agent is not ready, however well it demos.
| # | Control | What it means | Ship-blocker question |
|---|---|---|---|
| 1 | Unique identity | Each agent has its own credential, not a shared or human key | If this agent misbehaves at 2am, can you name it from the logs alone? |
| 2 | Least privilege | Access scoped to the task, read-only where possible, no standing admin | Could this agent delete or export data its job never requires? |
| 3 | Secrets handling | Credentials come from a vault at runtime, rotated, never in code or prompts | Is any key hard-coded, in an env file in the repo, or pasted into a system prompt? |
| 4 | Audit and monitoring | Every tool call and data access logged to the agent, with alerts on the unusual | Can you produce a complete record of what this agent did last Tuesday? |
The failures are already public
Two 2026 incidents show this is not theoretical, and neither needed a clever attack on the model.
Moltbook, a social network for AI agents, ran on an unsecured database. In January 2026, 404 Media reported that any token on the platform was publicly readable, exposing roughly 1.5 million credentials and API keys for OpenAI, Anthropic, AWS, GitHub, and Google Cloud, plus private messages belonging to thousands of agent owners. The platform was later acquired by Meta. The breach was not a model jailbreak. It was a database with no access control, holding the keys to everything the agents could reach.
Ruflo, an open-source agent orchestration platform, shipped a default deployment that exposed its tool bridge over HTTP with no authentication. Tracked as CVE-2026-59726 and rated CVSS 10, it let an unauthenticated request run commands inside the agent's container, read the provider API keys, and poison the agent's stored memory. Again, an identity and access failure: 233 powerful tools reachable by anyone, with no one required to prove who they were.
Both map straight onto the checklist above. Secrets sitting unprotected, no identity boundary, no scoping on what the tools could do. These are the failure modes grounding and evaluation will not catch, which is why identity sits alongside them rather than inside them, a point we made in AI incidents rose 55%.
Retrofitting identity onto agents you have already shipped
Most enterprises reading this already have agents in production without ID cards. You do not need to pull them offline. Work in this order.
- Inventory. List every agent, the credential it uses, and what that credential can reach. This is usually the moment the shared-key problem becomes visible.
- Give each agent its own credential. Replace shared keys first, worst-scoped first. This alone restores traceability.
- Scope down. Cut each agent's access to what its task needs. Read-only wherever the job allows.
- Turn on logging. Route every tool call and data access to a log tied to the agent, and alert on the actions that should never happen.
- Close the off-boarding gap. Decide who owns each agent and how its access gets revoked, so a retired agent's key does not live on.
This is governance you can build in weeks, not a platform rebuild. The controls are the ones your organisation already runs for people and services. The work is applying them to a new kind of actor.
We treat every agent as a first-class actor with its own identity, its own scoped permissions, and its own audit log, on infrastructure you can inspect. An agent you cannot name in the logs is one you cannot govern, and one day cannot trust.
John LiChief Technology Officer- Why can't we just use one API key for all our agents?
- Because a shared key removes the one thing governance depends on: knowing who acted. With a shared key you cannot scope permissions to a single agent's task, you cannot revoke one agent without breaking every other agent on that key, and every action is logged to the key rather than the agent. When something goes wrong, and Gravitee found 45.6% of teams are running this way, you have no record of which agent did it.
- What is the difference between an agent's identity and a service account?
- A service account is a reasonable starting point, and far better than a shared human key. The difference is scope and lifecycle. Agents are created and retired faster than traditional services, they often call many tools, and some can spawn other agents. Gravitee found 25.5% of deployed agents can create and task other agents. That means each agent needs its own scoped identity and its own audit trail, not one broad service account shared across a fleet, so you can trace and revoke at the level of the individual agent.
- Isn't this just slowing down deployment?
- The four controls add days, not months, and they are the difference between an agent you can put in front of a board and one you cannot. Only 19.7% of teams report securing all agents before go-live, so most of the delay in the market is not from doing this, it is from cleaning up after skipping it. Identity, scoping, and logging are cheaper before production than after an incident.
- Do these controls slow the agent down at runtime?
- No. A credential from a vault, a scoped permission set, and a log write add negligible latency. The cost is in setup, not in the request path. Agents run at the same speed with ID cards as without, they just leave a record and stay inside their lane.
- Where should identity for agents actually live?
- In the same identity and access systems you already run for people and services, extended to treat an agent as its own actor, on infrastructure you control. The goal is one place where every actor, human or agent, has an identity, a scope, and a log. Sovereign hosting matters here: if an agent touches regulated or sensitive data, you want the identity and audit records held in your environment, not a vendor's.