AI agent governance needs purpose-built architecture, not retrofits

At a glance

What this is: This analysis argues that AI agent governance requires purpose-built architecture because agents span multiple identity layers, act across tools, and outpace event-based security models.

Why it matters: IAM, NHI, and security teams need to treat agent governance as a distinct operating model, because partial visibility and retrofit controls create false confidence rather than real control.

By the numbers:

• Gartner named Zenity the company to beat in the AI Agent Governance category in its AI Vendor Race report as of 17 April 2026.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.
• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys.

👉 Read Zenity's analysis of AI agent governance architecture and intent-aware detection

Context

AI agent governance is the discipline of controlling what autonomous software can see, do, and access across its execution lifecycle. The problem is that agents do not behave like users or like ordinary workloads, so the usual identity, logging, and detection assumptions break down quickly.

The article’s central claim is that purpose-built architecture matters more than integrations layered onto tools that were built for static accounts and event streams. That maps directly to NHI governance, because agents inherit credentials, traverse multiple identity layers, and create runtime decisions that legacy controls were never designed to interpret.

Key questions

Q: How should security teams govern AI agents that use multiple identity layers?

A: Security teams should inventory every identity layer an agent can use, including static credentials, session identities, embedded tool identities, and any delegated relationships between agents. Governance fails when one layer is controlled while another remains open, because the agent can still act through the weaker path. Treat the layered identity surface as the actual access boundary.

Q: Why do event-based tools struggle with AI agent governance?

A: Event-based tools struggle because they see isolated actions, not the full intent behind a chain of actions. Two agents can generate the same event pattern while one is compliant and the other is drifting out of scope. Governance requires session-level correlation that preserves context across tool calls and execution time.

Q: What breaks when organisations try to retrofit IAM controls onto AI agents?

A: Retrofit IAM breaks when the control model assumes a stable human session or a single workload identity. Agents chain tools, reuse context, and move through multiple environments, so a fixed permission set no longer describes actual risk. The result is partial visibility and false confidence rather than governance.

Q: What is the difference between visibility and governance in AI agent security?

A: Visibility tells you that an agent exists and what it touched. Governance tells you whether that agent was allowed to do it, whether its behaviour stayed aligned with intent, and whether enforcement can intervene before damage spreads. A mature programme needs both, but governance is what turns inventory into control.

Technical breakdown

Why event-based detection misses agent intent

Event-based detection asks whether a single action matched a known pattern. Agent governance requires a deeper question: whether a sequence of actions still matches the agent’s intended task. Agents can issue tool calls that look harmless in isolation while the overall chain crosses policy boundaries, accesses unexpected data, or changes state in ways a point-in-time alert cannot capture. A stateful engine is different because it tracks behaviour across sessions and reconstructs intent from the action sequence, not just from one log line. That is the architectural shift here: agents create meaning through chains of actions, not isolated events.

Practical implication: Teams need runtime context and session-level correlation, not just alert volume reduction.

How layered identities expand the agent attack surface

Agents operate across several identity layers at once: static credentials, dynamic session identities, identities embedded in the tools they call, and implicit identities that emerge through agent-to-agent interaction. Controlling only one of those layers leaves the rest effectively ungoverned. That is why traditional NHI controls, which were built for service accounts and fixed assignments, miss the full problem space. The technical issue is not simply visibility. It is that authorisation becomes distributed across tool boundaries, identity systems, and runtime context, so a single permission set no longer describes actual effective access.

Practical implication: Map every identity layer an agent can use before assuming an access review is complete.

Why full-lifecycle coverage matters across SaaS, custom, and device-based agents

The article identifies three environments where agents live: SaaS-managed agents, home-grown agents, and device-based agents. These behave differently, but they all need governance from discovery through enforcement. SaaS-managed agents can appear inside existing subscriptions before security teams inventory them. Custom agents carry build-time complexity across prompts, memory, and tool integrations. Device-based agents can reuse authenticated sessions on endpoints and trigger downstream cloud actions that look like ordinary user activity. A partial control set creates blind spots because each environment fails in a different way.

Practical implication: Build inventory, policy, and enforcement coverage for all three agent deployment patterns, not just the cloud ones.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Purpose-built architecture is the category requirement for AI agent governance. Agents break the core assumptions of user-centric security tools by chaining tool calls, switching context mid-session, and moving across identity layers that legacy controls treat separately. That means a retrofit approach can show activity without showing meaning. The implication is that AI agent governance must be designed as a native control plane, not as an add-on to SIEM, DLP, or standard IAM.

Event-based security cannot explain agent behaviour once runtime intent becomes the control point. The article is right to distinguish isolated alerts from stateful behavioural analysis. A procurement agent can emit the same event pattern whether it is researching or transacting, which is why event correlation alone underestimates agent risk. Stateful intent gap: the control gap is not missing telemetry, but missing continuity across the agent’s action chain. Practitioners should recognise that the decisive failure mode is interpretive, not merely technical.

Full-lifecycle coverage is not a premium feature, it is the minimum viable governance model for agents. SaaS-managed agents, home-grown agents, and device-based agents each create different blind spots, but all three require discovery, policy, investigation, and enforcement to stay aligned. The market signal is clear: governance products that stop at visibility are insufficient for real operational control. Teams should judge agent platforms by whether they cover the entire lifecycle and every execution environment.

Context-responsive authorisation is where agent governance is heading, but it also exposes a new assumption problem. Least privilege is traditionally defined at provisioning time because access needs were expected to be stable enough to measure. That assumption fails when an agent’s effective privileges change with its context during the session. The implication is that practitioners must rethink what an access decision means when the actor can alter its own path in real time, rather than simply add another policy layer on top.

Community contribution is becoming a governance signal, not just a reputation marker. The article links market influence to organisations shaping OWASP Agentic Applications work and MITRE ATLAS, which shows that the category is being defined by practitioners who understand the failure modes first. That matters because identity security for agents is still an emerging discipline. Teams should prefer controls and models that align with open threat and governance frameworks rather than proprietary vocabulary alone.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• For a lifecycle lens, see: NHI Lifecycle Management Guide for provisioning, rotation, offboarding, and visibility patterns that agent governance now has to inherit.

What this signals

Purpose-built agent governance will increasingly be judged by how well it unifies discovery, investigation, and enforcement. Teams that keep these functions in separate tools will spend more time reconciling signals than reducing exposure, especially once agent sprawl spreads across SaaS, custom builds, and endpoints. That is where the market is moving, and it mirrors the broader NHI shift toward lifecycle control rather than isolated credential management.

Only 96% of organisations store secrets outside secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs. For agent programmes, that is a warning sign because credential placement still shapes the blast radius even when runtime intent becomes the new control frontier. Teams should expect identity and security boundaries to converge around where agents can inherit and reuse access, not just where they are created.

Identity blast radius: the practical unit of control for agent governance is no longer the account alone, but the combination of credentials, tool reach, and runtime context. That is why policies built for static access reviews will keep missing the behavioural changes that matter most. Practitioners should prepare for governance models that respond to context drift in-session and can prove why an agent was allowed to continue.

For practitioners

• Inventory agent identity layers separately Document static credentials, session identities, tool identities, and any agent-to-agent relationships before assuming a single account view is enough. Use that map to identify where authorisation exists only in one layer while the agent can still operate through another.
• Replace event-only detection with session-level intent review Correlate tool calls, memory access, and data use across the full execution chain so you can judge whether the agent’s behaviour still matches the approved task. Treat a stream of isolated events as incomplete evidence.
• Classify agent environments by deployment pattern Separate SaaS-managed, home-grown, and device-based agents in your inventory and controls, because each requires a different discovery and enforcement path. A control that works for a cloud-hosted agent may leave endpoint-based activity invisible.
• Tie runtime enforcement to context drift Define the conditions that should change what an agent can do after it has started a task, then make enforcement respond to those conditions in-session. That prevents a single approval from becoming blanket permission for the rest of the workflow.

Key takeaways

• AI agent governance fails when teams assume user-centric and event-centric controls can describe autonomous behaviour.
• The scale problem is structural, because layered identities and multi-environment deployment create blind spots that point tools cannot close.
• Practitioners should evaluate agent platforms by lifecycle coverage, intent visibility, and in-session enforcement rather than by alert volume alone.

Key terms

• Agent Identity Surface: The full set of identities an AI agent can use while it executes, including static credentials, session identity, embedded tool identity, and any delegated or emergent relationships. For agentic systems, security fails when this surface is treated as one account instead of multiple controllable trust points.
• Intent-Aware Detection: A detection method that evaluates whether an agent’s sequence of actions still matches its intended task, not just whether individual events look suspicious. For autonomous behaviour, this is more useful than event-only alerting because risk often appears in the chain, not the single action.
• Stateful Threat Engine: A monitoring layer that retains context across an agent’s execution so behaviour can be judged over time rather than as disconnected events. In agent governance, the stateful model is what makes drift, scope expansion, and misuse visible before downstream impact becomes unavoidable.
• Context-Responsive Authorisation: An authorisation model that changes what an agent may do based on the context it has at runtime. For autonomous actors, this differs from static permissioning because the approval boundary can move during execution, which forces governance to account for session-level drift.

Deepen your knowledge

AI agent governance and layered identity control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agents that move across SaaS, cloud, and endpoint environments, it is worth exploring.

This post draws on content published by Zenity: Why Purpose-Built Architecture Wins in AI Agent Governance. Read the original.