Give every AI agent its own scoped identity before scaling?

Microsoft's May 7 RCE disclosure on AI agent frameworks + the IAM/PAM gap blocking 95% of agent pilots from production make this a board-level call.

· Counsel verdict · AIssential

The question

Existing IAM/PAM was built for humans and service accounts. Agents are neither. Should we invest now in a non-human identity layer with scoped entitlements per agent, or treat agents as shared-credential service accounts and accept the risk?

The premise

Team
~50 engineers, ~10 actively building AI features, single MLOps engineer. AI work pulls from feature-shipping capacity — any new commitment has to trade against the roadmap. Security is a fractional CISO + one part-time engineer.
Compliance
SOC2 Type II in scope. EU customer data subjects us to GDPR plus the EU AI Act's August 2026 GPAI-deployer obligations. SOC2 audit explicitly asks about service-account scope; auditor flagged AI agents as a future concern last cycle.
Stack
Entra ID for SSO. ~150 service accounts (CI, deploy, monitoring). 11 agents in production today: 3 customer-facing (RAG-based), 8 internal (ops automation). Today every agent shares one or two long-lived API keys per LLM provider, scoped by environment but not by agent.
Budget
Monthly AI spend ~$30K with quarterly board visibility. Approvals required for sustained jumps >20%. Cost-per-outcome metrics in place; finance asks for unit economics by use case. No dedicated security tooling budget; everything comes from existing eng capacity.

What's the realistic blast radius if today's shared-key model leaks?

Full LLM-provider account compromise. The shared key has access to every agent's chat history, embeddings, and outbound API calls. Realistic worst case: an internal-ops agent's tool-call list (which databases it can read) is exposed via a prompt-injection in a customer chat. We've never had this happen — but we've also never had >25 agents in production.

At what agent count does shared-credential pain force the migration?

Around 20-25. The breaking points are: per-agent rate-limit segmentation, per-agent cost attribution (finance asks for this every quarter), and incident-response forensics (which agent did what when something goes wrong). We're at 11 today; 6-month roadmap puts us at 22-28.

What's the minimum viable per-agent identity scheme?

Per-agent OAuth client_id + scoped API key per LLM provider, with audit logs tagged to that ID. Skip full NHI platforms (Astrix, Andromeda, etc.) until we have >50 agents. The 80% of the benefit lives in 20% of the architecture — but the 20% must ship before the agent count crosses 20.

Counsel's position

Migrate your 11 production agents from shared, long-lived API keys to a dedicated non-human identity layer with just-in-time scoped entitlements to ensure compliance with your upcoming August 2026 EU AI Act obligations.

Verdict

The verdict: Migrate to cryptographic non-human identities for production agents.

Migrate to cryptographic non-human identities for production agents

Given your upcoming EU AI Act obligations and reliance on shared API keys, transition your 11 production agents to purpose-built non-human identities.

Switch to just-in-time access tokens for agent entitlements

To avoid infinite overprivileging across your 11 production agents, replace long-lived API keys with dynamic, short-lived credentials.

Enforce workflow isolation to prevent self-escalating privilege chains

Since you currently scope API keys by environment rather than by agent, ring-fence your agent workloads to contain the blast radius of compromised identities.

Map your agent attack surfaces across prompts, tools, and memory

As you build out your 3 customer-facing RAG agents, expand your threat model beyond the prompt to secure tool execution and persistent memory.

Read another verdict

Get Counsel for your own decisions →