Agentic control planes define runtime governance for enterprise AI

At a glance

What this is: This is a blog on agentic control planes that says enterprise AI needs runtime governance for agent actions, not just employee authentication.

Why it matters: It matters because IAM, PAM, and data controls must now decide what an agent can do inside enterprise systems, not just who the employee is.

Context

Enterprise AI governance fails when organisations assume that authenticating the human is enough to govern the work the agent performs after login. In practice, the control problem moves from identity proof to runtime authorisation, because a single prompt can fan out into tool calls, data retrieval, exports, and delegation across multiple systems.

That shift creates a new governance layer between the IdP and the business application. The article frames this as an agentic control plane, which sits around the workflow and evaluates the user, agent, tool, action, data, and context before execution.

For identity teams, the important change is that the governed subject is no longer only the employee or the workload. The real subject is the decision path created when an AI agent acts on behalf of a person inside Salesforce, Jira, Snowflake, or internal APIs.

Key questions

Q: How should security teams govern AI agents that can access enterprise systems?

A: Security teams should govern AI agents as non-human identities with explicit ownership, scoped privileges, and continuous monitoring. The control set should include inventory, task-bound credentials, audit trails, and revocation paths. If an agent can call tools or touch production systems, it belongs in the same governance model as service accounts and other machine identities.

Q: Why do shared service accounts make agent governance harder?

A: Shared service accounts make it harder to prove which employee initiated the work and which agent actually performed it. They blur identity lineage, weaken audit evidence, and can grant more access than the task requires. In agent workflows, that creates accountability debt because the organisation loses a clear chain from human intent to machine action.

Q: What breaks when agent approval workflows are the only control on autonomous actions?

A: Approval-only models fail when the agent can assemble and execute a sequence too quickly for review to be meaningful. The review happens too late if the policy boundary is not enforced before action. In practice, teams end up auditing behaviour after the fact instead of preventing risky execution at the point of decision.

Q: What should teams do after an agent completes a sensitive action?

A: Teams should retain a full audit trail of the initiating employee, agent identity, machine account, policy decision, target tool, data touched, and result. That record supports incident review, compliance evidence, and internal accountability. Without it, organisations can see that an action happened but not who authorised it, which policy applied, or where control failed.

Technical breakdown

What an agentic control plane governs at runtime

An agentic control plane is a runtime enforcement layer that decides whether an agent may perform a specific operation in a specific context. It does not replace the identity provider, the model gateway, or the agent framework. Instead, it joins identity, tool access, policy, and audit so that the authorisation decision happens at the moment of action, not only at sign-in. That matters because agent behaviour is not a single access event. It is a sequence of tool calls, data pulls, and output generation that can cross systems and shift scope mid-workflow. See the AI Agent Authorisation Guide.

Practical implication: Treat agent authorisation as a per-action control problem rather than a one-time login decision.

How action-level permissions constrain tool use and data movement

Action-level permissions separate permission to access a tool from permission to use every function inside it. That distinction matters for AI agents because a read on Salesforce does not imply export rights, write rights, or cross-region transfer rights. Runtime policy can evaluate user, agent, tool, action, data, and context together, then allow, deny, narrow, redact, or route a request through approval. This is where least privilege becomes operational rather than abstract. It also narrows the blast radius of prompt injection, because malicious instructions in retrieved content should not expand the agent’s authority. See the MCP Security Guide.

Practical implication: Define separate policy decisions for read, write, export, and destructive actions inside each governed tool.

Why delegation and audit need identity continuity

Delegation is the hardest part of agent governance because the original human intent must remain traceable as work moves through agents, connectors, and machine users. If that chain breaks, accountability collapses and shared credentials become a liability. The article’s model keeps the employee identity, the agent identity, the backend execution account, and the target tool tied together through execution context and correlation identifiers. Audit records then become evidence, not just logs, because they show who initiated the action, which policy fired, what data was touched, and whether approval was required. See the AI Agent Observability, Audit and Incident Response Guide.

Practical implication: Preserve identity lineage across every delegated step so investigations can reconstruct who caused the action.

NHI Mgmt Group analysis

Runtime governance is the new control plane for enterprise AI: once an agent can choose tools, move context, and complete actions before a human reviews the output, classic identity governance stops at the wrong layer. The article correctly reframes the problem as action governance, not just authentication. That is the level where policy, context, and audit must meet if organisations want usable AI without open-ended privilege. Practitioners should treat runtime enforcement as a first-class identity function, not an integration detail.

Shared credentials create accountability debt in agent workflows: the article is right to flag that broadly privileged service accounts and shared API keys weaken attribution when agents work across enterprise systems. Those identities make it difficult to prove which employee initiated a request, which agent executed it, and which tool moved the data. This is not just an audit gap, it is a governance gap that erodes trust in the whole workflow. Practitioners should assume that weak identity lineage will become a control failure before it becomes a compliance finding.

Approval-only governance cannot keep up with agent speed: the article shows why manual review gates become bottlenecks when agents are expected to operate continuously across tools. If policy waits for a person to review every edge case, the organisation either slows to a crawl or grants excessive standing access. The meaningful shift is toward scoped, inline decisions with explicit bounds on action, data, and context. Practitioners should design governance for execution speed, not for after-the-fact exceptions.

Agentic control planes are converging identity, policy, and observability into one operating model: the most useful concept here is not the individual MCP gateway or audit log, but the runtime control plane that binds them together. That model recognises that identity alone does not secure AI workflows, and observability alone does not contain them. The governance pattern now spans access intent, delegated action, and evidence capture in one loop. Practitioners should evaluate whether their current architecture can enforce policy at the same speed the agent executes.

From our research library:

• 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
• Enterprise AI use rose from 55% of organisations in 2023 to 88% in 2025, according to McKinsey’s Global Surveys on the State of AI.
• Read next: AI Agent Authorisation Guide

What this signals

Runtime policy will become the operating norm for governed AI: organisations that keep treating agent permissions as static entitlements will struggle as workflows move across tools in real time. The better model is to decide at execution time, because that is where tool choice, context, and data movement actually happen.

The next governance boundary is not the model endpoint but the action boundary. Once agents can retrieve, transform, and export enterprise data inside one task, identity teams need controls that follow the workflow rather than the login event.

A practical maturity marker is whether an organisation can stop a risky agent action before the action completes, not after the data has already moved. That is the point at which agent observability and incident response becomes part of the governance stack rather than a post-incident tool.

For practitioners

• Map every agent execution path Inventory the employee, agent, machine user, tool, data class, and approval path for each workflow so governance can follow the full chain.
• Separate tool access from action rights Grant read, create, update, export, and delete rights independently so access to a system never implies full use of its functions.
• Require inline policy checks before execution Evaluate user, agent, tool, action, data, and context before the agent calls the backend system, then block or narrow the request when policy fails.
• Preserve audit lineage across delegation Record the initiating employee, agent identity, machine account, policy decision, and output state for every action so investigations can trace responsibility.

Key takeaways

• The article’s central claim is that enterprise AI needs runtime governance for actions, not just authentication for people.
• Its control model ties the employee, agent, tool, data, and context together so policy can decide before execution.
• For practitioners, the key shift is from static access review to inline authorisation, auditability, and delegation control.

Related NHI Mgmt Group resources: AI Agent Authorisation Guide · MCP Security Guide · AI Agent Observability, Audit and Incident Response Guide · Agentic AI Identity Guide

Key terms

• Agentic Data Control Plane: An Agentic Data Control Plane is the governance layer that manages how AI agents discover, request, use, and protect data while acting on behalf of a user or system. It coordinates policy enforcement, authorization, logging, and data boundaries across tools, APIs, and repositories, so agent actions remain traceable, constrained, and auditable.
• Function-Level Permissions: Function-level permissions restrict access to individual tool actions rather than an entire application or dataset. For MCP, this is the difference between allowing a client to read a resource and allowing it to delete or modify that same resource, which is where most of the governance risk emerges.
• Identity Lineage: Identity lineage is the traceable relationship between a human owner and the non-human identities that person creates, authorises, or depends on. It allows security teams to connect service accounts, API keys, tokens, and AI agents back to accountable ownership for review, audit, and retirement decisions.
• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.

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.