AI agent security in the enterprise starts with governance

At a glance

What this is: This is an enterprise AI security and governance guide arguing that AI agents are already active, credentialed identities that need runtime controls.

Why it matters: It matters because IAM, IGA, PAM, and NHI programmes now have to govern software entities that can act, call tools, and touch production systems, not just human users or static service accounts.

👉 Read Zenity's analysis of AI agent security and enterprise governance

Context

Enterprise AI security fails when organisations treat AI agents as if they were only another software feature. The central problem is identity and execution authority: an agent that is authorised, credentialed, and allowed to call tools can create security exposure that traditional prompt-centric controls do not address.

For IAM and NHI teams, the issue is not whether AI is present in the enterprise. It is whether the governance model can cope with identities that operate across deployment archetypes, inherit privileges, and act on live systems. The article’s framing is typical of where the market is heading: from model safety discussions toward identity control of agent behaviour.

Key questions

Q: How should security teams govern AI agents that can act on production systems?

A: Treat each agent as a governed identity with a named owner, issued credentials, approved tools, and a clear task boundary. Security teams should evaluate what the agent can do at runtime, not just what it was designed to do. That means access scope, logging, and offboarding must be part of the control set from day one.

Q: Why do AI agents complicate existing IAM and PAM controls?

A: Because IAM and PAM were built around stable identities and predictable approval flows, while agents can make runtime decisions and invoke tools dynamically. The problem is not only privilege level, but the fact that authority can be exercised in ways that are hard to pre-classify. Existing controls need runtime context to stay effective.

Q: What breaks when AI agent access is reviewed only at deployment time?

A: You miss the point at which the agent actually acts. A deployment-time review can approve a configuration that later becomes risky when the agent is repurposed, connected to new tools, or given broader workflow reach. The result is stale authorisation that no longer matches the real operating context.

Q: How can organisations tell whether agent governance is actually working?

A: Look for evidence that every production agent has an owner, a current purpose, a bounded tool set, and a defined retirement path. If agents remain active after the workflow changes, or if nobody can explain which actions they are authorised to take, governance is failing even if logs exist.

Background and context

AI agents as credentialed identities

An AI agent is not just a chatbot with a tool button. In enterprise settings, it can hold credentials, authenticate to systems, and execute actions across APIs, SaaS platforms, and internal workflows. That creates an identity surface that sits between human IAM and machine identity, but with runtime choices that make static review models less effective. The critical technical point is that the agent’s access is not merely observational. It is operational, so the security model has to account for who or what authorises each action, how tools are selected, and whether the agent can persist beyond the intended task boundary.

Practical implication: map every agent to a named identity, issued credential, and approval path before it is allowed to act.

Tool invocation is the real control point

The dangerous moment is not the prompt. It is the tool call. Once an agent can invoke external systems, the security boundary shifts from content moderation to authorisation, context validation, and execution guardrails. In practice, that means a harmful outcome can emerge even when the model output looks benign if the agent is allowed to turn instructions into actions. The architecture problem is that many controls observe the text, not the downstream effect. For agentic systems, runtime policy has to inspect context, destination, and intended effect at the moment of execution.

Practical implication: enforce policy at tool invocation time, not only at the prompt or model output layer.

Lifecycle governance must follow the agent

AI agents inherit the old lifecycle problem from NHI governance, but with more movement and less predictability. Provisioning, access scope, review, and decommissioning all have to follow the agent’s actual operational life, not the project timeline that created it. If an agent is promoted into production, repurposed, or left in place after a workflow changes, its access may outlive the business need. That is the same failure pattern IAM teams know from orphaned service accounts, only faster and harder to notice because the actor can keep working. Governance is therefore about continuous identity state, not one-time setup.

Practical implication: tie agent offboarding and access recertification to the same lifecycle discipline used for other non-human identities.

NHI Mgmt Group analysis

AI agent governance is now an identity problem, not a model problem. The article describes agents that are authorised, credentialed, and active inside enterprise systems, which moves the security question from output quality to identity control. That shift matters because IAM, PAM, and NHI controls were built to govern who can do what, not merely to filter what a model says. Practitioners should treat agent identity as the primary control plane.

Prompt-based security is the wrong abstraction for agentic systems. Zenity’s framing shows that the risky event is the execution of a tool action, not the text that precedes it. A prompt can be harmless while the resulting API call is destructive, which means the security boundary has moved to runtime authorisation. Practitioners need governance that evaluates action intent, destination, and scope at the moment of execution.

Lifecycle assumptions that work for service accounts are already straining under agent behaviour. Access review processes were designed for identities whose privileges remain stable long enough to be recertified. That assumption weakens when an agent can be created, repurposed, or retired across fast-moving workflows without a clean human analogue. The implication is that recertification and offboarding logic must be rebuilt around agent state, not human cadence.

Named concept: agentic runtime governance gap. This is the gap between authorising an AI agent at setup and governing its actions while it is operating in production. The gap exists because the control model still assumes the risky part happens before deployment, when the real risk is often created at runtime through tool use and delegated action. Practitioners should recognise that static approval is no longer enough to describe the threat surface.

Enterprise AI programmes need a unified identity model across human, NHI, and agentic actors. The article implicitly reinforces that AI governance cannot be isolated from IAM operations. Human users, service accounts, and agents now intersect in the same workflows, which makes fragmented control ownership a liability. The practical conclusion is that identity governance must be designed across actor types, with the agentic layer treated as a first-class identity class.

From our research:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
• For a broader control lens, review Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs for lifecycle governance patterns that also apply to agent identities.

What this signals

Agentic AI is pushing identity teams toward runtime governance models that combine IAM, PAM, and NHI thinking. With 72% of organisations already experiencing or suspecting an NHI breach in our research, the boundary problem is no longer academic.

Agentic runtime governance gap: the gap between approving an AI agent and controlling its live actions will become the category that matters most in enterprise AI security. Teams that keep treating agents as a model-risk issue will miss the identity and authority layer where failures actually happen.

The practical signal is that recertification, tool approval, and offboarding now need to move in lockstep across human, machine, and agentic identities. A useful reference point is Top 10 NHI Issues, which helps teams map the operational failures that surface when non-human identities outgrow manual governance.

For practitioners

• Inventory every production AI agent Record the agent owner, issuing system, credential type, connected tools, and the business process it can affect. Without that inventory, you cannot tell whether the agent is operating inside its intended scope.
• Move authorisation to the tool layer Evaluate each agent action at execution time, with policy based on destination system, data sensitivity, and task context. Do not rely on prompt review as a substitute for runtime decision control.
• Apply lifecycle controls to agent identities Require joiner, mover, and leaver handling for agents, including prompt changes, permission changes, workflow changes, and retirement. An agent that is no longer needed should lose access the same way any other identity does.
• Separate experiment access from production authority Keep sandboxed agents, pilot agents, and production agents on distinct credentials and distinct approval paths. Mixing them creates hidden privilege transfer and makes later recertification unreliable.

Key takeaways

• AI agents are already operating as governed identities inside enterprise systems, which makes identity control the core security issue.
• The real risk sits at runtime, where tool invocation and delegated action can bypass prompt-centric security thinking.
• IAM, PAM, and lifecycle governance all need to be extended so that agent access can be reviewed, constrained, and removed like any other identity.

Key terms

• AI Agent Identity: The identity assigned to an AI system that can authenticate, hold credentials, and perform actions across connected tools or services. In practice, this is a governed software identity that needs ownership, scope, logging, and retirement just like other non-human identities.
• Runtime Authorisation: Authorisation checked at the moment an action is about to happen, rather than only when access is first granted. For agentic systems, runtime authorisation matters because the risk is created by what the agent does next, not just by what it was allowed to do in advance.
• Agentic Runtime Governance Gap: The distance between approving an AI agent as a project artefact and controlling its actual production behaviour. This gap appears when static approvals, access reviews, or policy documents do not keep pace with the agent’s live tool use and changing operational context.

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 NHI governance in your organisation, it is worth exploring.

This post draws on content published by Zenity: AIDR Unpacked: A Conversation with Claude Mythos Tenant AWS. Read the original.