Agent Identity Is Now a Procurement Question

Last quarter, the Gravitee state-of-agent-security report surveyed 900+ executives and technical practitioners. The headline number is sharp: 88% of organizations reported confirmed or suspected AI agent security incidents in the past year.

Other numbers from the same report are equally telling:

• 81% of teams are past the planning phase and into deployment.

• Only 14.4% have full security approval for their agent systems.

• Only 22% treat agents as independent identities.

• 45.6% rely on shared API keys.

• Just 47.1% of agents receive active monitoring.

This is the gap between adoption and governance, in numbers. Most agent programs in production were stood up faster than the security and identity infrastructure around them. That is no longer survivable.

The shift this year — and the reason this post belongs in the series — is that agent identity has moved from a think-piece topic to a line item in enterprise RFPs. Procurement teams are asking for it. Compliance officers are asking for it. Insurance underwriters are asking about it. The conversation has changed.

What "agent identity" actually means

There is a category of identity called the Non-Human Identity. Service accounts. API tokens. Machine roles. Pipeline credentials. In modern enterprises, NHIs outnumber human identities by something like 100 to 1.

Agents are a new and particularly problematic kind of NHI. They are:

• Non-deterministic. A given agent identity can take different actions on different runs.

• Composed. One agent invokes another, which invokes a third. The chain of who is acting on whose behalf gets murky fast.

• Long-lived. An agent identity persists across many tasks, sometimes across many users.

• Capable. An agent can do dozens or hundreds of things, depending on what tools it's wired to.

A traditional service account ran one job, on a schedule, with a fixed set of capabilities. An agent identity runs many jobs, ad hoc, with capability that depends on its harness and its tools.

The legacy identity infrastructure — designed for service accounts — does not handle this well. Which is why the field is converging on a new vocabulary.

The Zero-Trust framework that's emerging

The Cloud Security Alliance's Agentic Trust Framework, published in February 2026, is the most-cited reference. It applies zero-trust principles to agents: every agent must have a verified, auditable identity before accessing any resource; no implicit trust based on network location or prior authentication; continuous verification rather than one-time check.

The Red Hat zero-trust-for-agents piece, published the same month, takes a similar position from a platform-engineering angle. Both frameworks share a few common moves:

1. Per-agent identity, not shared credentials. Each agent gets its own credential. No shared API keys.

2. Scoped authorization. Agents have the permissions they need for the task they're doing, and no more.

3. Verifiable actions. Every action the agent takes is logged with the agent's identity, so post-hoc audit is possible.

4. Human-on-behalf-of model. When an agent acts on behalf of a user, the identity layer captures both — the agent that acted, and the user it was acting for.

5. Revocation infrastructure. When an agent is compromised or misbehaves, you can revoke it without taking the rest of the system down.

None of these are exotic. All of them are missing in the 45.6% of organizations using shared API keys.

Why this is now a procurement question

Three forces converged to make agent identity an RFP requirement, not a research topic:

• Incidents got expensive enough to matter. When the 88% became visible — when boards started seeing real losses from agent-related incidents — procurement teams got mandates from their CIOs to demand better hygiene from vendors.

• Regulators noticed. The EU AI Act, with its August 2 2026 enforcement milestone, makes governance over autonomous systems a compliance question, not just a security question. ISO/IEC 42001 certification is becoming a procurement filter. DORA has tightened operational-resilience requirements for financial-services AI specifically.

• Insurance underwriters started asking. This is the one that moves boardrooms fastest. When the cyber insurance renewal questionnaire includes "do your AI agents have unique, scoped identities," there's a budget line for it within 60 days.

The piece I would put in front of every CISO in 2026 is the one observation that ties these together: agent identity is the surface area on which audit, compliance, insurance, and incident response all meet. Get it wrong and four different functions are now your problem.

What good looks like in practice

The teams I've seen do this well share a few patterns:

1. Identity at the MCP-server boundary. From Week 3 — MCP servers are where the trust boundary lives. Authentication, scoping, and audit logging happen there. Not in the agent framework. Not in the model. In the server.

2. One identity per agent role, not per agent instance. A customer-support agent gets one identity. Not one per session. Not one shared across all agents. Scope at the role level, log at the session level.

3. Just-in-time elevation. Most of the time the agent runs with read-only scopes. When it needs to do something with side effects, it requests elevation, which triggers a human-in-the-loop or a policy check.

4. Audit trail by default. Every action gets a structured log entry: agent identity, user on whose behalf, MCP server, tool name, arguments, outcome. This is what you'll need when a regulator or auditor asks.

5. Revocation drills. Practice killing an agent identity. Confirm the system handles it gracefully. Confirm downstream systems notice. This is the thing teams skip and then regret.

Where to start if you're behind

If you're a leader looking at the Gravitee numbers and recognizing your organization in them, the sequence I'd recommend is:

• Inventory. What agent systems are in production. What credentials they use. Who has access to what.

• Stop the bleeding. Remove shared API keys for the agents that handle anything customer-facing or financially material. Replace with per-role credentials.

• Audit logging. If you don't have it at the MCP-server layer, add it. This is what makes everything else recoverable.

• Policy at the boundary. Decide which actions require human approval. Implement that at the server, not in the agent.

• Then the framework. Adopt the Agentic Trust Framework or your platform vendor's equivalent. Run the maturity model. Plan the rest of the work.

Don't try to do this in reverse order. Picking a framework first and trying to retrofit identity to existing agents is twice as much work as doing the basics first and then formalizing.

The bigger pattern, again

We've been working up the stack through this series. Plans (Week 1). Context and memory (Week 2). Protocols (Week 3). Capability (Week 4). Coordination (Week 5). Portable expertise (Week 6). Harnesses (Week 7). Evals (Week 8). Now identity. Each layer is more about organizations than about models.

The bottleneck keeps migrating outward, in exactly the pattern I argued in London. By the time you get to identity, security, and governance — which is where we are now — the conversation is barely about AI at all. It is about how organizations operate when their workforce includes agents.

If you're at the point where your agent program is bumping into security and audit reviews and you need a second pair of eyes, that is exactly the conversation we have at Applied Futures.

Next week, a layer that pulls in a different direction: small language models, and why the future is hybrid, not monolithic.