Independent analysis by NHI Mgmt GroupSource article: Zenity, “Why Purpose-Built Architecture Wins in AI Agent Governance” (May 5, 2026)

TL;DR: Traditional security tools cannot secure AI agents because they were designed around user-centric identity, event-based visibility, and fixed data paths, according to Zenity and Gartner’s April 2026 evaluation. The governance problem is structural, because agent behavior, layered identities, and runtime intent invalidate assumptions that legacy IAM and detection stacks rely on.


At a glance

What this is: NHI Mgmt Group's analysis, drawing on Zenity's blog post: AI agent governance requires purpose-built architecture because agents break the identity, visibility, and data-flow assumptions behind retrofitted security tools.

Why it matters: IAM, PAM, and NHI teams need to treat agent governance as a structural design problem, because layered identities and runtime behaviour change how access must be inventoried, authorised, and enforced.


Context

AI agent governance is the problem of controlling what autonomous software can access, do, and trigger across systems. The central issue is that agents do not behave like human users or simple service accounts, so security models built for either one often miss the runtime behaviour that matters most.

The article’s core claim is that retrofitting legacy IAM, SIEM, and DLP stacks onto agents leaves governance gaps at discovery, authorisation, detection, and enforcement. For identity programmes, that means the control plane has to reflect agent behaviour, not just credentials and sign-in events.


Key questions

Q: How should security teams structure a DLP audit checklist for SaaS, cloud, and endpoint environments?

A: A useful DLP audit checklist should cover the full data path, not just one control layer. Start with data classification, then verify access controls, encryption, alerting, and incident handling across SaaS, cloud, and endpoint tools. Add clear review criteria, regular updates, and integration with operational workflows so the checklist drives action rather than becoming a static compliance document.

Q: Why do traditional IAM and SIEM controls miss SaaS lateral movement?

A: Traditional IAM and SIEM tools are usually optimized for human login events, endpoint telemetry, and isolated application logs. SaaS lateral movement often uses valid OAuth tokens or API keys, so there is no suspicious authentication event to flag. The attack happens inside trusted cloud-to-cloud traffic, which makes single-system monitoring incomplete.

Q: What are the signs that an AI governance programme is too shallow?

A: A shallow programme usually shows up when teams rely on accuracy alone, lack clear metrics for fairness or explainability, and cannot verify how models behave under stress. Another warning sign is when mitigation is discussed abstractly but not tested with documented methods, datasets, or repeatable evaluation. Good governance produces evidence, not just intent.

Q: What should teams do when user permissions change during an active agent task?

A: Treat permission checks as real-time, not session-scoped. If a user is demoted, revoked, or offboarded while an agent is still working, the next token exchange must reflect the new state immediately. Cached authorisation creates stale access and defeats the purpose of delegated control.


Technical breakdown

Why legacy identity models fail for AI agents

Traditional identity tooling assumes a stable actor, a single identity layer, and a mostly linear path from authentication to action. AI agents break that model by chaining tool calls, inheriting multiple credential types, and operating across static secrets, dynamic sessions, and tool-embedded identities. That creates a governance problem that cannot be solved by looking only at who authenticated. The meaningful question is what the agent can do across the full execution path, including agent-to-agent interactions and hidden context in the tools it uses.

Practical implication: map agent access at the execution level, not just at sign-in or secret issuance time.

Why event-based detection misses agent intent

Event-based controls can tell you that a tool call, file access, or API request occurred, but they usually cannot tell you whether the sequence was consistent with the agent’s intended task. That matters because two agents can generate nearly identical events while pursuing very different outcomes. Intent-aware detection adds state across the session, so behaviour can be judged against the expected action chain rather than isolated alerts. In agent environments, this is the difference between seeing activity and understanding whether the activity is appropriate.

Practical implication: evaluate whether your detection stack can reconstruct agent intent, not just match known event patterns.

Why governance must cover the full agent lifecycle

The article separates SaaS-managed, home-grown, and device-based agents because each introduces a different inventory and control problem. SaaS-managed agents may appear before central governance exists, custom agents carry build-time complexity and undocumented integrations, and device-based agents can trigger downstream SaaS actions that look like ordinary user behaviour. A partial view in any one environment leaves a false sense of control. Governance only becomes meaningful when discovery, policy, runtime enforcement, and investigation are connected across the full lifecycle.

Practical implication: align discovery and enforcement across SaaS, cloud, and endpoint agent estates instead of treating them as separate programmes.


Threat narrative

Attacker objective: The objective is to use agent behaviour and delegated access to reach data or systems in ways that look legitimate at the event level but violate governance intent.

  1. Entry occurs when SaaS-managed, home-grown, or device-based AI agents are introduced into the environment before governance is fully established.
  2. Credential and context access then expand across layered identities, static secrets, dynamic sessions, and tool-level permissions that the agent can inherit and combine.
  3. Escalation happens when event-based tools fail to recognise intent drift, allowing an agent to chain legitimate actions into an unintended sequence across systems.
  4. Impact is delivered when unsafe agent actions reach downstream data, SaaS, or cloud systems before human review or inline prevention can intervene.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

AI agent governance fails when identity is treated as a credential problem instead of a runtime behaviour problem. Agents inherit access, chain tools, and act across multiple identity layers, so the control question is no longer who logged in. It is what the agent can decide to do with the access it already has. The implication is that authorisation must move closer to execution, not remain anchored only in provisioning.

Purpose-built agent architecture is now a governance requirement, not an optimisation choice. Retrofits assume existing IAM, SIEM, and DLP layers can be stitched together after the fact, but the article shows why that assumption breaks. Agent behaviour cuts across discovery, investigation, detection, and enforcement, so fragmented tooling produces partial visibility and delayed response. Practitioners should treat connected workflow architecture as the baseline for agent governance.

Intent-aware detection is the named concept that changes agent security from alerting to interpretation. Event-based tooling can surface activity, but it cannot reliably distinguish a normal multi-step workflow from a scope violation or manipulation attempt. A stateful view of agent intent is therefore the control boundary that matters. The practical conclusion is that behavioural context, not event volume, determines whether an agent environment is governable.

Full-lifecycle coverage across SaaS-managed, home-grown, and device-based agents exposes the real perimeter of agent risk. Each environment introduces different blind spots, from shadow agents that appear inside enterprise subscriptions to local tools that trigger cloud-side actions. A single control plane that does not span all three categories leaves governance incomplete. The implication is that inventory, policy, and enforcement must be designed as one system across the whole estate.

Context-responsive authorisation is the likely next control shift for agent governance. Static allowlists describe what an agent may do in theory, but agent risk changes as context changes during runtime. That means the next control layer will need to adjust permissions based on what the agent has learned or accessed inside the session. Practitioners should expect runtime context to become part of authorisation design, not just detection.

From our research library:

What this signals

AI agent governance is moving from point controls to lifecycle control, and that shift matters because agents do not stay inside a single identity boundary long enough for traditional review cycles to catch them. Security teams should expect discovery, policy, and enforcement to converge into one operating model as agent estates grow.

Runtime intent is the boundary that now matters: when an agent can chain actions faster than a human can inspect them, governance based on post-event review becomes structurally late. Teams that still treat agents like enhanced service accounts will keep missing the behaviour that actually creates risk.

Use of AI agents should trigger a review of whether current IAM and NHI programmes can express permissions at runtime, not just at provisioning time. The control question is no longer who has access, but how access is allowed to change once the agent has new context.


For practitioners

  • Define the agent identity surface Inventory every place an agent can hold, inherit, or embed identity, including static secrets, session credentials, tool identities, and agent-to-agent links. Treat this as a governance map, not just a secrets register.
  • Separate agent estates by operating model Classify SaaS-managed, home-grown, and device-based agents separately so discovery, policy, and response controls match where each type actually lives and acts.
  • Move detection from events to intent Require stateful analysis that can compare observed action sequences with the task the agent was expected to perform, rather than relying on isolated alerts.
  • Connect investigation to enforcement Ensure posture findings, runtime anomalies, identity relationships, and data-access evidence feed a single workflow that can block unsafe behaviour before downstream systems are affected.
  • Plan for context-responsive authorisation Design policy logic that can change what an agent may do after it accesses new context, rather than assuming a static permission set remains valid for the whole session.

Key takeaways

  • AI agent governance cannot be solved by retrofitting controls that were designed for human sessions and fixed data paths.
  • The article’s core message is that layered identities, chained tool use, and runtime intent require a purpose-built architecture for discovery, detection, and enforcement.
  • For practitioners, the practical test is whether their governance model can follow an agent from inventory through execution and still constrain what it can do in context.

Key terms

  • Agent identity surface: The full set of identities, credentials, sessions, and embedded authorisations an AI agent can use during execution. For agent governance, this includes static secrets, dynamic sessions, tool identities, and delegated permissions that may appear across multiple systems at once.
  • 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.
  • 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.
  • Full-lifecycle governance: A control model that covers discovery, policy, runtime enforcement, investigation, and response across the entire life of an AI agent. It is stronger than point-in-time monitoring because it follows the agent from first appearance through active use and remediation.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
NHIMG Editorial Note
Published by the NHIMG editorial team on June 6, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org