TL;DR: AI agents now need lifecycle governance across discovery, policy, detection, prevention, and response, according to Zenity, underscoring Zenity’s recognition in the CyberSecurity Breakthrough Awards. The bigger signal is that agent behaviour, tool invocation, and access scope are becoming identity governance problems, not just application security problems.
At a glance
What this is: This is Zenity’s award announcement, and its key finding is that securing AI agents requires end-to-end governance from buildtime through runtime.
Why it matters: It matters because IAM, NHI, and security teams are being pushed to govern agent behaviour, access, and tooling as one control problem rather than three separate ones.
By the numbers:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.
👉 Read Zenity's announcement on agentic AI security recognition
Context
Agentic AI security is the control problem that appears when software can choose tools, act on data, and change state without a human approving every step. The governance gap is not just runtime detection. It is that many identity programmes still assume access can be granted, reviewed, and revoked on a human-paced cycle, while agents may create and consume privilege far faster than that model can observe.
Zenity’s award framing reflects a wider shift in the market: AI agent security is moving from point controls to lifecycle governance. For practitioners, that means discovery, posture, policy enforcement, monitoring, and response need to line up across SaaS, cloud, and endpoint environments. The useful question is no longer whether an AI tool can be secured in isolation, but whether the identity model can follow how the agent behaves across its full workflow.
Key questions
Q: How should security teams govern AI agents that can use multiple tools across environments?
A: Treat the agent as an identity with explicit ownership, scoped entitlements, and a monitored action path. Each tool should map to a business purpose, and cross-environment workflows should be reviewed for privilege chaining. If the same agent can move across SaaS, cloud, and endpoint without a consistent policy layer, governance is incomplete.
Q: Why do AI agents create governance risk for IAM and NHI programmes?
A: AI agents can act within delegated access while changing what they do at runtime, which breaks assumptions built around stable, reviewable access. IAM and NHI programmes are then forced to govern not only credentials, but behaviour, tool invocation, and downstream actions. That makes identity control a lifecycle problem rather than a login problem.
Q: How do teams know whether agent governance is actually working?
A: Look for evidence that the organisation can inventory agents, trace tool use, and explain each action after the fact. If teams can name the agent but cannot reconstruct which data it touched or which systems it called, governance is not working in practice.
Q: What is the difference between securing an AI model and governing an AI agent?
A: Securing a model focuses on the model itself, while governing an agent means controlling what it can access, which tools it can invoke, and what actions it can trigger. The latter is broader because the risk sits in execution, not just output. That is why agent governance belongs alongside IAM and NHI controls.
Technical breakdown
AI agent lifecycle governance from buildtime to runtime
AI agent security spans the entire identity lifecycle, not just a single authorization check. Buildtime controls cover inventory, configuration, and posture. Runtime controls cover what the agent reads, which tools it calls, what actions it takes, and whether those actions stay within policy. The architectural challenge is that agents can move from permitted access to harmful action without a clear boundary between request and execution. That makes audit trails, policy consistency, and response logic part of the identity layer, not separate security add-ons.
Practical implication: treat agent discovery, policy enforcement, and runtime monitoring as one governance chain.
Why tool invocation is the real control boundary
For agentic systems, the important security boundary is often the tool call, not the model response. A model can appear harmless in isolation, but when it is allowed to invoke APIs, query data, or trigger workflows, the identity risk becomes operational. That means access control must cover not just who or what authenticated, but which tools are available, under what context, and with what downstream effects. In practice, the dangerous step is usually the combination of access plus autonomy plus external action.
Practical implication: map every agent tool to a specific entitlement and review the downstream action it can trigger.
Policy consistency across SaaS, cloud, and endpoint agents
AI agent deployments often fragment across platforms, which creates policy drift. An agent in SaaS may have different visibility and controls than one in cloud or endpoint tooling, even when the underlying risk is the same. A governance model that works only in one environment leaves blind spots in the others. Consistent policy matters because attackers and misconfigurations do not respect platform boundaries, and neither do legitimate agent workflows when they chain actions across services.
Practical implication: standardise agent policy evaluation across environments before scaling deployment.
NHI Mgmt Group analysis
AI agent security is becoming an identity governance problem, not just an application security problem. The award matters because it reflects market recognition that agents must be governed as identities with lifecycle, tool, and access boundaries. Once an agent can decide which tool to invoke and when to invoke it, the control plane shifts from software behaviour to entitlement governance. Practitioners should stop treating agent security as a separate domain and fold it into IAM, NHI, and PAM governance.
Agent-centric security exposes a named gap: runtime governance drift. Zenity’s framing highlights that controls can exist at buildtime yet still fail at runtime when agents behave differently than planned. That is the point at which posture, policy, and response diverge from actual execution. The implication is that security teams must measure whether governance stays aligned with agent behaviour after deployment, not just before release.
Consistent policy across SaaS, cloud, and endpoint agents is now a baseline requirement. The article points to a multi-environment control problem where agent workflows span several operational surfaces. When governance differs by platform, the weakest surface becomes the practical policy boundary. Practitioners should assume that a fragmented control model will be bypassed by ordinary workflow chaining, not just adversarial abuse.
AI agent governance will increasingly converge with NHI governance patterns already familiar to security teams. The same discipline that applies to service accounts, API keys, and workloads now applies to agents that act with delegated access. The difference is that agent behaviour can change at runtime, which raises the bar for auditability and response. Security leaders should expect identity teams to own more of the agent security conversation as deployments scale.
Recognition programmes are a signal of category formation, not proof of operational completeness. Awards can indicate where the market is heading, but they do not resolve the harder question of how enterprises actually govern agents at scale. The practical takeaway is to evaluate whether current identity controls can describe, constrain, and audit agent action across the full lifecycle. If they cannot, the programme is already behind the deployment curve.
From our research:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- A separate finding shows that 80% of organisations report their AI agents have already acted beyond intended scope, including unauthorised system access, sensitive data sharing, and credential exposure.
- For a broader view of how these controls map to agentic risk, see OWASP Agentic AI Top 10 for the control patterns practitioners should benchmark against.
What this signals
Runtime agent governance will become a standard IAM workstream rather than a niche AI security task. As deployments spread, teams will need policy models that can describe agent ownership, tool scope, and approval boundaries in the same language they already use for privileged identities. The programme impact is clear: if you cannot audit an agent’s tool path, you cannot claim durable governance.
Agent policy drift is the operational risk most likely to surface first. A control model that works in one environment but not another will create hidden exceptions as agents move across SaaS, cloud, and endpoint workflows. Practitioners should expect audit and incident response teams to ask for a single evidence trail, not a platform-by-platform explanation.
The market is moving toward lifecycle controls that look a lot like machine identity governance, but with stronger behavioural requirements. That means inventory, ownership, access scope, and review cadence are necessary but not sufficient. Security teams should prepare for a new baseline where tool invocation and action logs become core governance artefacts.
For practitioners
- Inventory every agent and its delegated tools Create a complete register of agent identities, connected data sources, and tool permissions across SaaS, cloud, and endpoint environments. Include owners, business purpose, and escalation paths so each agent can be governed as a distinct identity rather than as generic automation.
- Bind tool use to explicit policy and entitlement records Map each agent tool invocation to an approved entitlement and context rule. Review whether the agent can reach sensitive systems through chained actions that were never intended to be granted together.
- Unify monitoring and response across all agent environments Make sure alerts, logs, and response workflows are consistent across the platforms where agents operate. A fragmented monitoring model creates the blind spots that make autonomous or semi-autonomous behaviour hard to investigate.
- Rework access reviews for agent behaviour, not just static access lists Review whether your current certification process can show what an agent actually did with its access. If it only records entitlement at approval time, it will miss the risk created by tool chaining and runtime drift.
Key takeaways
- AI agent security now sits at the intersection of identity governance, tool control, and runtime monitoring.
- The evidence points to a maturity gap: organisations recognise the risk, but many have not implemented the policy and audit controls needed to govern it.
- Practitioners should manage agents as identities with traceable tools, scoped access, and cross-environment policy consistency.
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 address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A3 | Agent tool use and runtime actions create the core risk discussed here. |
| NIST AI RMF | The article centers on governance, measurement, and oversight for AI behaviour. | |
| NIST CSF 2.0 | PR.AA-01 | Identity and access assurance apply to agent identities and delegated privileges. |
Define ownership, monitoring, and accountability for agent behaviour across its lifecycle.
Key terms
- Agent Identity: An agent identity is the set of credentials, permissions, and ownership used to govern software that can act on its own behalf. In practice, it includes what the agent can access, which tools it can invoke, and who is responsible for its behaviour and outcomes.
- Runtime Governance Drift: Runtime governance drift is the gap between what policy says an AI system may do and what it actually does once it starts operating. For agentic systems, the drift can appear when tool use, data access, or action chaining changes after approval or deployment.
- Tool Invocation Control: Tool invocation control is the discipline of limiting which external actions an agent can trigger and under what conditions. It is a core boundary for agentic AI because the security risk often appears when a model is allowed to execute actions, not just generate text.
- Delegated Access: Delegated access is permission granted to an identity to act within another system or environment on behalf of a user, service, or process. For AI agents, delegated access must be tightly scoped because the agent may choose how to use it at runtime, not just follow a fixed script.
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 responsible for identity security strategy or programme maturity, it is worth exploring.
This post draws on content published by Zenity: Zenity Named “Agentic AI Security Solution of the Year” in 9th Annual CyberSecurity Breakthrough Awards Program. Read the original.
Published by the NHIMG editorial team on 2025-10-09.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org