TL;DR: Enterprise security is shifting toward AI agent governance as organizations move from isolated copilots to systems that act, decide, and learn across SaaS, cloud, and endpoint surfaces, according to Zenity. The underlying issue is that existing IAM and security controls assume bounded, reviewable access, but autonomous agent behaviour compresses that control window beyond what traditional governance can observe.
At a glance
What this is: This is a vendor milestone article arguing that AI security is moving from model protection to governance of agents, integrations, and runtime behaviour across the enterprise.
Why it matters: It matters because IAM, PAM, and NHI programmes now need to govern not just credentials and access, but the decision-making surfaces where AI agents can create new privilege and data exposure paths.
👉 Read Zenity's Cyber 60 analysis of AI security and agent governance
Context
AI agent governance starts with a simple distinction: agents do not just automate tasks, they can make runtime decisions about what to do next, which tools to use, and when to act. That shifts the security problem from static access control to governing behaviour across buildtime and runtime in a way most identity programmes were not designed to handle.
Zenity's recognition is really a signal that the market is moving toward full-lifecycle governance for AI agents, including discovery, posture assessment, and runtime detection. For IAM, IGA, and PAM teams, the question is no longer whether AI will touch identity controls, but how to extend those controls to software that can initiate action across multiple enterprise surfaces.
That puts AI agent security in the same governance conversation as NHI sprawl, delegated third-party access, and least-privilege enforcement. The practical challenge is not just inventorying identities, but understanding which identities can act with enough autonomy to bypass traditional human-paced review cycles.
Key questions
Q: How should security teams govern AI agents that can act across multiple systems?
A: Security teams should govern AI agents as privileged non-human identities with discovery, permission review, and runtime monitoring. The key is to control what the agent can reach before deployment, then monitor what it actually does after deployment. That approach gives IAM and security teams a single model for visibility, entitlement reduction, and response across the full lifecycle.
Q: Why do AI agents create a different governance problem from ordinary automation?
A: AI agents create a different governance problem because they can choose actions at runtime instead of following only fixed rules. Ordinary automation stays within a predefined workflow, but an agent can vary tool use, sequence, and timing. That means governance must focus on observed behaviour, not only on the approved configuration or script.
Q: What breaks when organisations cannot see all of their AI agents?
A: When organisations cannot see all of their AI agents, they lose the ability to assess privilege, data access, and accountability. Hidden agents can connect to sensitive systems without clear ownership or review, which creates blind spots similar to shadow IT but with faster runtime impact. Visibility is the prerequisite for any meaningful control.
Q: Who should own AI agent governance inside the enterprise?
A: AI agent governance should sit across IAM, security architecture, and platform teams rather than with one isolated function. Ownership needs to cover identity, permissions, data access, and response because agents cut across all of those control planes. The most effective model assigns clear accountability for inventory, approval, and monitoring before the agent is allowed to operate.
Technical breakdown
AI agent discovery and runtime visibility
AI agent discovery is the process of mapping agents, integrations, and connections across SaaS, cloud, and endpoint environments so security teams can see what exists before deciding how to govern it. In practice, this is closer to identity inventory than model monitoring. Once agents can call tools, access data, and chain tasks, the core control issue becomes observability across the full execution path, not just authentication at the front door. Without that map, posture management and response are blind to where authority is actually exercised.
Practical implication: build an authoritative inventory of agents, integrations, and connected data sources before attempting policy enforcement.
Posture management for agent permissions and data access
Agent posture management focuses on how an AI system is configured, what data it can reach, and which actions it is allowed to take before deployment. This is the governance layer that tries to prevent overbroad access from becoming a default state. The technical distinction matters because an agent may be securely authenticated and still be unsafe if its reachable tools, datasets, or execution scopes are too broad. For identity teams, this is an entitlement problem as much as an AI problem.
Practical implication: treat every agent integration like a privileged workload and review permissions before the system is allowed into production.
Real-time detection of agent misuse and policy violations
Runtime detection is needed because AI agents can drift from intended use after deployment, especially when they combine multiple actions in one session. That includes data leakage, policy violations, and unexpected tool use. In identity terms, this resembles the gap between provisioning and governance, except the actor can move much faster than traditional certification cycles. If controls only exist at setup time, they will miss the moment when the agent crosses from approved behaviour into harmful execution.
Practical implication: pair deployment-time approval with telemetry that can detect and halt risky agent behaviour while it is still active.
NHI Mgmt Group analysis
AI agent governance is now an identity problem, not only a security tooling problem. Once agents can choose actions across SaaS, cloud, and endpoint environments, the boundary between identity, access, and workflow begins to blur. That means IGA and PAM teams cannot treat agent oversight as a separate AI initiative. The practitioner conclusion is that agent governance must be folded into core identity operations.
Full-lifecycle visibility is the new minimum control for autonomous systems. Discovery, posture, and runtime response are not optional layers, they are the structure of control itself. If an organisation cannot see every agent, integration, and connected surface, it cannot reason about blast radius or accountability. The practitioner conclusion is that inventory gaps create governance gaps immediately.
Automation alone is not enough when the actor can act, decide, and learn. Traditional workflow automation stays within predetermined rules, but agentic systems can vary their behaviour at runtime. That makes old assumptions about stable intent and reviewable access fragile. The practitioner conclusion is that policy must be tied to observed behaviour, not just approved configuration.
Identity blast radius is the right named concept for this category. An AI agent can amplify a small configuration mistake into cross-system exposure because one identity may touch multiple enterprise surfaces in a single operational path. That is different from a simple account compromise, because the path of harm is embedded in the agent's permissions and reach. The practitioner conclusion is that teams should measure how far one agent can move, not just whether it is authenticated.
OWASP-NHI and AI governance frameworks become relevant together once agents operate as non-human identities. The more an agent behaves like a workload with decision power, the more NHI governance patterns matter alongside AI risk management. That is why the category is converging on shared controls for identity, permissions, logging, and response. The practitioner conclusion is that identity architecture, not just model policy, will define the next control baseline.
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.
- 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 same research.
- That confidence gap is why teams should also read Ultimate Guide to NHIs , Key Challenges and Risks to connect visibility failures with privilege and lifecycle controls.
What this signals
Identity blast radius: AI agent programmes should be measured by how far a single identity can move across systems, not just by how many users adopt the platform. Once agents can initiate actions across SaaS and cloud, the governance question becomes whether the enterprise can bound their reach before they become operational defaults.
With 1 in 4 organisations already investing in dedicated NHI security capabilities, the governance market is clearly shifting toward identity controls that can handle machine and agent behaviour together, according to The State of Non-Human Identity Security. That is a signal for IAM leaders to align AI oversight with NHI lifecycle controls rather than build a separate silo.
Enterprises that already struggle with OAuth visibility and over-privilege will feel the same pressure in AI agent programmes, only faster. The practical response is to extend inventory, entitlement review, and runtime telemetry into one operating model before autonomous behaviour outpaces review cycles.
For practitioners
- Map every agent, integration, and connection Build a current inventory of AI agents across SaaS, cloud, and endpoint environments, then tie each one to the data sources and tools it can reach. Without that map, posture reviews and incident response will miss the real control points.
- Review agent permissions before deployment Treat each agent as a privileged workload and validate what it can read, write, and invoke before it is allowed into production. Remove broad data access and unnecessary tool reach at the configuration stage.
- Add runtime policy enforcement for agent behaviour Instrument detection for misuse, leakage, and policy violations while the agent is active, not only during approval workflows. Use telemetry that can identify unexpected tool chaining or data movement in-session.
- Extend identity governance to AI decision paths Update access review and ownership processes so they cover the actions an agent can initiate, not just the account used to authenticate it. This is where identity governance starts to overlap with behaviour governance.
Key takeaways
- AI agent governance is converging on identity controls because agents can act across multiple enterprise surfaces, not just inside a single application boundary.
- Visibility, permission review, and runtime monitoring form the basic control stack for agents whose behaviour can change after deployment.
- IAM, IGA, and PAM teams need to govern agent decision paths as part of the identity programme, or they will miss the real blast radius.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | AG-02 | Agent discovery and runtime misuse map to agentic attack surfaces. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Agent permissions and lifecycle governance mirror non-human identity controls. |
| NIST AI RMF | AI governance and accountability are central when agents act autonomously. |
Treat each agent like a non-human identity and review access, rotation, and ownership continuously.
Key terms
- AI Agent Governance: AI agent governance is the set of policies, controls, and review processes used to manage software that can choose actions at runtime. It extends identity and access thinking into behaviour, tool use, and accountability across the agent's full operating lifecycle.
- Identity Blast Radius: Identity blast radius is the maximum operational harm one identity can create if misconfigured, abused, or over-privileged. For AI agents and other non-human identities, it includes the number of systems, data sets, and actions reachable from a single account or token.
- Runtime Visibility: Runtime visibility is the ability to observe what an identity or agent is doing while it is actively executing. It goes beyond inventory and configuration by capturing tool calls, data access, and policy violations in real time, which is critical when behaviour can change after deployment.
- Agent Posture Management: Agent posture management is the practice of assessing how an AI agent is configured before it is allowed to operate. It focuses on permissions, reachable data, and allowed actions so that unsafe defaults can be removed before runtime behaviour creates exposure.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.
This post draws on content published by Zenity: Fortune names Zenity to the Cyber 60 and its analysis of AI security governance. Read the original.
Published by the NHIMG editorial team on 2025-10-30.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org