Field Report No. 1 · June 2, 2026

AI Agent Governance: Treat Agents Like Applications

AI agents are privileged applications. Govern them like applications, not like answers.

Agentic AI Identity GovernanceAgentic AINon-Human IdentityThreat ModelRegulatory

Download the report (PDF) ↓

1. The pattern

By April 2026, AI agents have moved from chat interfaces to production workloads. They open tickets, deploy code, transfer money, and orchestrate other agents. Each one authenticates as something. Each one carries permissions. Each one decides for itself.

The most useful governance definition we have found: an AI agent is a software system that authenticates with credentials, holds delegated authority, plans and executes multi-step actions, and decides which tool to invoke based on its own reasoning. That definition makes the IAM problem clear. Agents are non-human identities that authorize themselves.

Traditional service accounts run a fixed script. Agents pick the script at runtime, sometimes the next step too. That is the property that breaks the existing controls.

2. What we are seeing

The empirical picture from Q1 2026 is bad and getting worse. Across enterprise environments we and others have assessed, three numbers stand out: 92% of enterprises lack full visibility into their AI agent identities; 95% doubt they could detect or contain a compromised agent; only 16% effectively govern AI access to core systems. Forrester predicts an agentic AI deployment will cause a public data breach by year-end. The regulatory floor is closer than it reads: EU AI Act high-risk obligations enforce on 2 August 2026. OWASP published its Top 10 for Agentic Applications in December 2025, the first formal taxonomy of agent-specific risks.

Three patterns dominate the incident reporting. None of them are novel attack categories. All of them are predictable consequences of skipped controls.

The first pattern is agents acting under developer credentials. The fastest path to a working agent is giving it the same credentials the developer used during testing. In production assessments we consistently find agents running with highly-privileged API keys, OAuth tokens from developer accounts, and service principals with subscription-wide permissions. Compromise of one agent in this configuration grants attackers the full access of its creator, often across multiple environments. This maps directly to OWASP ASI 03 and is the most common gap we encounter on day one of an engagement.

The second pattern is cross-tenant trust and supply-chain compromise. Agents increasingly call tools and services they did not author, including third-party MCP servers, vendor APIs, and plugin ecosystems. The Q1 2026 OWASP round-up documented multiple incidents in which compromised third-party integrations on agent platforms enabled lateral movement into customer environments through trusted non-human identities. The pattern echoes the tj-actions GitHub Action breach of March 2025, with one new twist: a compromised tool chained through an autonomous orchestrator can affect many more downstream actions before detection.

The third pattern is AI-assisted attacks accelerating attacker tempo. OWASP and Bloomberg both reported on a multi-agency Mexican government compromise in early 2026 in which Anthropic Claude and ChatGPT were used to automate reconnaissance, script generation, and exploit iteration, accelerating an intrusion that exfiltrated approximately 150 GB across multiple agencies. This is not an agent governance failure inside the victim. It is an agent capability exploited offensively. The implication for defenders is symmetric: the same agent capabilities that compress attack tempo must be matched by defensive ITDR telemetry that operates at agent speed, not human speed.

Every Q1 2026 incident category we have catalogued maps to an existing IAM control gap. What is new is the speed at which an agent compounds those gaps.

3. What is actually changing

Three governance assumptions that no longer hold sit at the center of this shift.

The first is that permissions are fixed at provisioning time. They are not, for agents. Agents discover and invoke tools dynamically. They reach for capability the directory never knew about. Static least-privilege calculation cannot keep up with a workload whose tool catalog evolves at runtime.

The second is that human oversight sits between authentication and action. It does not, for agents. Agents complete dozens of consequential actions between human review points. The "human in the loop" model assumed a single decision per session. An agent session can fan out into thousands of decisions before any human sees the trace.

The third is that behavior is interpretable from logs. It is not, for agents. Agent reasoning is opaque; the audit trail captures the action, not the decision that produced it. Asking why an agent took an action is fundamentally different from asking why a service account took an action, because the agent's reasoning is itself non-deterministic and not preserved.

The regulatory environment is moving to match. The EU AI Act's high-risk obligations enforce on 2 August 2026, with Article 9 (ongoing risk management), Article 12 (record-keeping), Article 13 (transparency and interpretability), and Article 14 (human oversight) carrying the operational weight for agent operators. The NCCoE / NIST concept paper on Software and AI Agent Identity and Authorization landed in February 2026, drawing on OAuth 2.0 and existing NIST identity guidelines. NIST extended the AI Risk Management Framework's Govern, Map, Measure, Manage functions to autonomous agents in the CAISI initiative launched February 2026. OWASP's December 2025 Top 10 for Agentic Applications is now the operationally actionable threat model. ISO/IEC 42001 (published 2023; certification programs operational in 2026) integrates with existing ISO 27001 controls.

2026 governance has to address all three of the broken assumptions. The infrastructure to govern agents has not kept pace with the ease of building them.

4. What programs are doing about it

The programs we have inspected sort into four maturity stages. None are exotic; each is observed in production today, with a wide spread across the enterprise base.

Initial stage programs share developer credentials or static API keys across agents. Agents call APIs directly with no tool gateway. There is no registry, deployments are ad-hoc, and review is informal. This is where the 92% visibility gap comes from.

Defined stage programs have moved to per-agent service principals with some scoping. They run basic logging and manual policy checks. Inventory lives in a spreadsheet. Review is quarterly. This stage is honest about the agents in production but does not yet have runtime controls.

Managed stage programs have per-task ephemeral identity via workload identity federation. An MCP gateway enforces per-tool authorization. A policy engine sits between agent reasoning and consequential action. An agent registry tracks every deployed agent. ITDR alerts stream to the SOC. Audit-ready logs cover identity, action, parameters, and policy decisions.

Optimized stage programs add cryptographic provenance to bounded ephemeral identity. Cross-model verification runs on critical decisions. Circuit breakers limit blast radius when an agent's behavior deviates from baseline. Continuous compliance monitoring produces an EU AI Act Article 9 evidence pipeline as a side effect of normal operations.

The OWASP Top 10 for Agentic Applications provides the threat taxonomy these programs are organizing around. ASI 01 covers goal hijacking via prompt injection or context manipulation. ASI 02 covers tool misuse beyond intended scope. ASI 03 covers identity and privilege abuse beyond what the task requires. ASI 04 covers memory and context poisoning. ASI 05 covers cascading failures across orchestrated agents. ASI 06 covers rogue agents operating outside the governance boundary. ASI 07 covers insecure inter-agent communications. ASI 08 covers agentic supply chain. ASI 09 covers unexpected code execution. ASI 10 covers human-trust exploitation through under-contextualized approvals.

The six controls most often observed in Managed and Optimized stage deployments map directly to those categories. Per-task ephemeral identity closes ASI 03. Capability sandboxing with explicit tool authorization closes ASI 02 and 09. A centralized policy engine for privileged actions, with human approvers required for critical actions on a structured decision summary, closes ASI 10. Full runtime logging plus ITDR integration, with detection logic that flags tool-call sequences deviating from baseline, closes ASI 04 and supplies EU AI Act Article 12 and 13 evidence. Inter-agent authentication and message integrity with mutual auth and signed envelopes closes ASI 07. Agent registry and lifecycle governance with mandatory enrollment, decommissioning as a first-class lifecycle event, and credential revocation plus dependency cleanup on decommission closes ASI 06 and supplies EU AI Act Article 9 evidence.

5. What we believe

Three positions, defendable from the patterns above.

Identity is the right control surface. The dominant industry conversation has been "AI safety" and "model alignment." Both matter; neither maps to operational controls a security program can ship. Agent governance is non-human identity governance, extended. The patterns that work are the patterns that have always worked: bound identity, scoped authorization, runtime telemetry, lifecycle hygiene. The novelty is the speed and the fan-out, not the control category.

Per-task ephemeral identity is the most operationally durable answer to privilege accumulation. The OWASP ASI 03 problem (agents accumulating privilege beyond task requirement) is structural. Long-lived agent credentials always accumulate scope through legitimate operational pressure. The only stable answer is to issue a fresh identity per task, with TTL shorter than expected duration plus margin, credentials issued via workload federation, never embedded in code or environment variables. Programs that have moved here report meaningfully fewer "what does this account do" investigations.

ITDR for agents must operate at agent speed. Human-paced detection cannot keep up with agentic attacker tempo, and it cannot keep up with the legitimate-but-anomalous behavior of an autonomous orchestrator either. The defensive playbook has to assume that agent-on-agent decisions happen faster than a SOC analyst can review, and place its controls at the points where actions become consequential: tool authorization, policy enforcement, runtime anomaly detection. Logging without enforcement at agent speed is record-keeping, not detection.

6. What to check in your own environment

Five practitioner questions to take back to your IAM and security teams this quarter.

Do we have an authoritative inventory of every AI agent running in production right now? Where do their credentials come from? If the answer is "we are not sure," that is the first finding.

Are any agents running under developer-owned credentials or service principals with subscription-wide permissions? This is the OWASP ASI 03 pattern. It is also the most common day-one finding in production assessments. If the answer is yes, scope the exposure first, then plan the remediation.

For each production agent, can we enumerate the specific tools it is permitted to invoke, the rate limits on those invocations, and the policy decisions the platform applies before invocation? If tool calls flow directly from agent reasoning to the target API with no gateway in between, the agent's reasoning is the only check.

If an agent's behavior changed today, would the SOC see an alert? What specific detection logic do we have for agent-specific deviations, like sudden expansion of tool-call diversity, new tool invocations outside the registered capability set, or inter-agent traffic that does not match the registered topology?

For agents that take consequential actions (financial transactions, data writes, external communications, code deployment), is there a centralized policy engine evaluating the request, or is the agent's own reasoning the final word? Are critical actions escalated to a human approver with a structured decision summary?

If the answer to any of these is unclear, that is the place to start. Identity is the right control surface; the question is whether your program has the surface in the right places yet.

Sources

The frontmatter sources array carries the full reference list. Primary sources for the analysis above:

  1. OWASP GenAI Security Project, Top 10 for Agentic Applications 2026 (December 2025)
  2. OWASP GenAI Security Project, GenAI Exploit Round-up Report Q1 2026 (April 2026)
  3. NCCoE / NIST, Accelerating the Adoption of Software and AI Agent Identity and Authorization, concept paper (February 2026)
  4. Cloud Security Alliance Lab Space, The AI Agent Governance Gap: What CISOs Need Now (April 2026)
  5. European Union, Artificial Intelligence Act (Regulation (EU) 2024/1689), Articles 9, 12, 13, 14; high-risk obligations enforce 2 August 2026
  6. NIST AI Risk Management Framework (AI RMF 1.0), January 2023; CAISI autonomous-agent initiative launched February 2026
  7. Microsoft Open Source Blog, Agent Governance Toolkit (April 2026)
  8. Forrester, 2026 prediction on agentic AI breach
  9. Gartner, AI TRiSM through 2026 unauthorized-AI-transactions estimate

Several sources lack stable public URLs at time of draft; URLs to be populated in the frontmatter sources block before publish.

If this Field Report raised a question about your own controls, get in touch and we will reply with a vendor-neutral read on your specific control set. No sales call attached.

Talk to a practitioner →
← All Field Reports