Agentic AI governance needs adaptive controls, not static categories

At a glance

What this is: This is an enterprise framework for governing agentic AI, arguing that traditional AI governance must extend into decision authority, process autonomy, accountability, tool use, and runtime oversight.

Why it matters: IAM, GRC, and security teams need this because agentic systems change how identity, privilege, and accountability work across NHI, autonomous, and human governance programmes.

👉 Read Zenity's framework for governing agentic AI in the enterprise

Context

Agentic AI governance is the problem of controlling software that can decide, act, and chain tools in real time rather than simply producing outputs. The core gap is that most governance programmes were built for static AI risk tiers and human-paced approvals, which do not map cleanly to autonomous tool use or shifting decision authority.

For identity and access teams, the article sits at the intersection of NHI governance, AI governance, and third-party risk. It argues that agent identities need permission boundaries, auditability, and runtime monitoring in the same way service accounts do, but with added attention to tool invocation and contextual autonomy.

The practical challenge is not whether organisations should govern agentic AI, but whether they can do it without creating a separate silo. The article’s starting position is typical of the current market: strong on principles, weak on operationalisation, and increasingly shaped by shadow adoption.

Key questions

Q: How should security teams govern agentic AI in enterprise environments?

A: Security teams should govern agentic AI as a runtime identity and access problem, not as a model-only policy exercise. Define identity boundaries, approved tools, data access limits, and escalation points for each deployment model. Then monitor actual behaviour continuously, because agent authority can change by task and context.

Q: Why do static AI governance frameworks fail for autonomous agents?

A: Static frameworks fail because they assume decision authority, autonomy, and accountability are stable enough to classify in advance. Autonomous agents can shift those states while running, which means periodic review and fixed risk tiers miss the moment when governance should change. The control model has to move with the workload.

Q: What do organisations get wrong about embedded AI agents in SaaS tools?

A: They often treat embedded agents as a feature setting instead of a new access surface. Once a vendor can enable agentic actions inside a product, the enterprise needs to know what the agent can do, what data it can reach, and whether logging is sufficient for audit and response.

Q: Who should own accountability when an agent chains multiple actions and causes harm?

A: Accountability should be assigned through the full decision chain, not only to the model builder or the end user. The practical test is whether the organisation can reconstruct who authorised the agent, what it could access, what tools it used, and when the oversight state changed.

Technical breakdown

Adaptive governance and the 3A model

The article frames agentic AI governance around three shifting dimensions: decision authority, process autonomy, and accountability. Decision authority asks who is making the call, process autonomy asks how independently the agent operates, and accountability asks who owns the outcome when chained tool calls produce a failure. Unlike static AI risk tiers, these dimensions can change by task and environment. That matters because the same agent may deserve different oversight depending on whether it is summarising text, modifying production systems, or invoking external tools. Practical implication: governance must be continuous and context-aware, not limited to periodic approval cycles.

Practical implication: Track authority, autonomy, and accountability as runtime states, not one-time classifications.

Why endpoint and embedded agents change the control model

The article separates homegrown agents, endpoint agents, and SaaS-embedded agents because governance failure looks different in each case. Homegrown agents are controlled through design-time boundaries. Endpoint agents shift the burden to acceptable use, local monitoring, and enterprise data restrictions. Embedded agents are hardest because vendors may enable them by default while keeping visibility and control limited. The technical issue is not just access, but how tool execution, file system interaction, API use, and data movement can occur inside environments the enterprise only partially controls. Practical implication: governance questionnaires, endpoint policy, and third-party risk reviews must all be updated for agentic capability.

Practical implication: Classify agents by deployment model before deciding which control plane owns them.

Tool use, observability, and action boundaries

Agentic systems become risky when tool invocation is treated as a neutral feature rather than a privileged action surface. Once an agent can browse, call APIs, access files, or chain plugins, governance has to define which tools are allowed, which actions are permitted, and what evidence is logged. The article treats runtime observability as mandatory because static assessment cannot capture emergent behaviour or inter-agent communication. This is where least privilege becomes operational, not theoretical. Practical implication: log tool calls, data access, and action sequences at a level that supports both security monitoring and audit review.

Practical implication: Instrument tool use as an access event, not just an application event.

Threat narrative

Attacker objective: The attacker objective is to turn legitimate agent capability into unaudited access and action across enterprise systems.

1. Entry occurs when agentic capability is adopted through sanctioned platforms, local assistants, or embedded SaaS features that are enabled without full governance review.
2. Escalation follows when the agent is granted broader tool access, broader data visibility, or approval-free execution for workflows that were never scoped for autonomous action.
3. Impact appears when chained tool calls, plugin use, or unmanaged autonomy produces unauthorized actions, data exposure, or production-side failures.

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

Static AI governance categories are already obsolete for agentic systems. Risk tiers and fixed oversight models were designed for systems whose behaviour is bounded at design time. Agentic AI shifts decision authority and autonomy by context, which means governance has to move with the workload rather than sit above it. The implication is that enterprise programmes need dimensional governance, not another static policy layer.

Agentic AI is an NHI governance problem before it is a model governance problem. Once an agent can invoke tools, access data, and operate with machine identities, the core control questions become identity scope, privilege boundaries, auditability, and lifecycle management. That is squarely in NHI territory even when the business use case is AI. Practitioners should treat agent identity as an access problem with behavioural variance, not as a model-only concern.

Decision authority is the named governance concept that best explains the failure mode here. It was designed for workflows where humans or predefined policies remain the primary decision gate. That assumption fails when the actor can choose actions, tools, and timing at runtime. The implication is that governance has to re-evaluate where authority actually sits, because the old boundary between recommendation and execution no longer holds.

Endpoint agents and embedded SaaS agents create a shadow governance layer that enterprises often do not see. The article shows that risk is not concentrated in bespoke builds. It also lives in developer desktops, browser-native assistants, and SaaS products that quietly gain agentic features. Practitioners need to assume that the hardest governance problem may be the one introduced by ordinary software already in production.

Adaptive trust thresholds are more useful than fixed autonomy labels. The article’s strongest contribution is the argument that oversight should change as context changes. That is the correct direction for the market, because the same agent can be low-risk in one task and high-risk in another. Security teams should interpret this as a mandate to measure behaviour, not just classify technology.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, 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 State of Non-Human Identity Security.
• Read OWASP Agentic AI Top 10 for the agent-specific risks that make runtime governance and tool boundaries harder to get right.

What this signals

Adaptive trust thresholds: governance for agentic AI should be measured in behavioural states, not policy documents. With 1 in 4 organisations already investing in dedicated NHI security capabilities, per The State of Non-Human Identity Security, the market is moving toward runtime identity controls that can keep pace with machine-speed decisions.

Agentic AI will push more enterprises to collapse separate AI, IAM, and third-party risk workstreams into one operational control model. That shift matters because embedded agents inside SaaS and endpoint tools can expand the attack surface without ever passing through a formal architecture review.

If your programme still treats approval workflows as the main governance control, it is already behind. The practical signal to watch is whether you can prove what an agent touched, what it was allowed to do, and who could have stopped it before execution.

For practitioners

• Define agent identity boundaries Assign each agent a named identity, explicit permission scope, and owner before any production use. Treat tool access, data reach, and execution rights as governance objects that must be approved and reviewed together.
• Map controls by deployment model Separate homegrown agents, endpoint agents, and embedded SaaS agents in your policy model. Use different control owners for each, because the enterprise does not govern them through the same technical choke points.
• Instrument runtime tool use Log tool calls, data access, inter-agent communication, and approval states so that behaviour can be reconstructed after the fact. Without those records, auditability and accountability collapse as soon as an agent chains actions.
• Update third-party risk questionnaires Add questions about autonomous actions, default-enabled agent features, logging depth, and whether the vendor can disable or constrain agentic behaviour. Static SaaS questions do not expose this risk surface.
• Replace fixed oversight with contextual gates Use approval thresholds that change with task sensitivity, data type, and system impact. Low-risk summarisation may tolerate autonomy, while production change or financial execution should not.

Key takeaways

• Agentic AI exposes a governance mismatch because static AI policies do not track runtime authority, autonomy, and accountability.
• The strongest evidence in the article is that enterprises are already using full-auto agent modes, which means governance gaps are no longer hypothetical.
• Security teams should govern agents by deployment model, identity boundary, and runtime observability rather than by broad AI labels.

Key terms

• Agentic AI governance: Agentic AI governance is the set of controls used to manage software that can decide and act at runtime. It extends beyond model oversight to include identity, access, tool boundaries, auditability, and accountability for actions that may have real-world consequences.
• Decision authority: Decision authority is the right to choose what action happens next. In agentic systems, it can shift between human, policy, and machine during a workflow, which makes it a moving control point rather than a fixed design property.
• Process autonomy: Process autonomy is the degree to which a system can progress through tasks without human intervention. For autonomous or agentic systems, the practical question is not whether autonomy exists, but how far it can extend before controls or approvals must change.
• Accountability chain: An accountability chain is the sequence of people and systems responsible for an identity-driven action from authorisation to outcome. In agentic AI, it must include the agent owner, the control owner, the vendor if applicable, and the records needed to reconstruct execution.

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 building or maturing identity security capability, it is worth exploring.

This post draws on content published by Zenity: Governing Agentic AI, a practical framework for the enterprise. Read the original.