Agentic AI as critical infrastructure demands identity-grade controls

At a glance

What this is: The article argues that agentic AI is becoming enterprise infrastructure and that security must shift from model safety to identity, authorization, and runtime governance.

Why it matters: IAM, PAM, and NHI teams need to treat AI agents like operational identities because their tool use, data access, and workflow execution can create enterprise-wide blast radius.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read AppSOC's analysis of why agentic AI needs infrastructure-grade security

Context

Agentic AI is software that can decide what to do, choose tools, and carry out tasks across enterprise systems. That changes identity security because the actor is no longer a passive application but an operational identity with real permissions, real data access, and real consequences. In the primary keyword sense, agentic AI is now an access and governance problem, not only a model-risk problem.

The article's central claim is that enterprises are deploying AI agents as if they were ordinary software features, while the systems themselves behave more like infrastructure components. Once an agent can query data, trigger workflows, and interact with SaaS or APIs, the controls that matter are authorization scope, runtime monitoring, and lifecycle governance across NHI and autonomous identity patterns.

That starting position is increasingly typical rather than exceptional. Most organisations are moving faster on deployment than on governance, which means identity teams need to decide whether an AI agent is being treated as a workload identity, an autonomous actor, or an unmanaged shadow system.

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 AI agents complicate least-privilege access models?

A: Because agents often use shared or long-lived NHIs, move quickly, and cross platform boundaries that human-centric review processes do not cover well. Least privilege still applies, but it has to be enforced at the identity, resource, and execution layers together. Otherwise the agent keeps more reach than the task requires.

Q: What breaks when AI agents are not governed at runtime?

A: Without runtime governance, an agent can shift behaviour after provisioning and still execute actions that were never reviewed in context. That is where tool chaining, MCP connections, and rapid decision-making become dangerous. Static approval cannot stop a live change in intent, so teams lose control at the point of action.

Q: Which frameworks apply to AI gateway governance and agent identity?

A: OWASP NHI and Zero Trust are the most direct fits for workload identity, tool exposure, and least-privilege control. For broader AI governance, teams should also use an AI risk framework to define ownership, evidence, and accountability across the agent lifecycle. The common requirement is that runtime access must be explainable.

Technical breakdown

Why agentic AI behaves like infrastructure rather than a feature

Agentic systems do more than generate output. They plan steps, invoke tools, and execute actions across connected applications, which makes them part of the operational path of the enterprise. In identity terms, that means the system is not just consuming access, it is exercising it. Once an agent sits between users, data, and business systems, its permissions and trust relationships become part of the enterprise control plane. The security model must therefore include discovery, authorization, monitoring, and lifecycle controls that assume real operational impact.

Practical implication: classify agents as governed identities, not as ordinary application features.

The identity and authorization layer behind agent tool use

An AI agent that calls APIs or triggers workflows needs a defined identity, scoped entitlements, and a reliable way to verify what it is allowed to do in the moment. That is different from model safety, which focuses on output quality or prompt abuse. The real security issue is whether the agent can reach sensitive systems, combine permissions unexpectedly, or act outside intended business context. Contextual authorization, zero standing privilege, and policy enforcement at runtime become the relevant controls, because the risk appears at execution time rather than at design time.

Practical implication: bind every agent action to explicit policy and short-lived, narrowly scoped access.

MCP and connected tools expand the trust boundary

When agents connect through tool frameworks such as MCP, the trust boundary moves outward to every server, API, and data source the agent can reach. That creates a chain of delegated trust that is only as strong as the weakest connected system. If a tool gateway, connector, or approval step is too permissive, the agent can inherit capabilities far beyond the original request. The architectural issue is not only access sprawl but delegated access sprawl, where the agent becomes a broker of enterprise authority.

Practical implication: inventory every tool connection and treat each as part of the agent's privilege model.

NHI Mgmt Group analysis

Agentic AI creates an identity governance problem before it creates a model-risk problem. The article correctly shifts the conversation from output safety to operational authority, because autonomous systems act inside business processes rather than beside them. That means the real question is not whether the model is well-behaved in isolation, but whether its runtime permissions, data reach, and approval boundaries are governable. Practitioners should read this as an identity programme issue first and an AI issue second.

Least privilege was designed for stable actors with known intent. That assumption fails when the actor can select tools and sequence actions at runtime across multiple systems. The implication is not just that permissions need tightening, but that the provisioning model itself no longer captures the full risk of the actor's behaviour. Security teams need to rethink how privilege is defined when the identity is making decisions after access is granted.

Runtime governance, not pre-deployment review, is the control plane that matters for autonomous systems. The article points to monitoring and contextual authorization because agents can change impact simply by chaining actions across tools. Static approvals and one-time reviews do not see scope drift once execution begins. Practitioners should treat runtime telemetry, policy evaluation, and termination logic as core identity controls, not optional add-ons.

Agentic AI security will converge with NHI and PAM governance. Once agents have persistent service-like access, their risk profile resembles privileged machine identity more than consumer AI. That convergence will push enterprises toward shared controls for discovery, entitlement review, secret handling, and escalation management across humans, workloads, and agents. The programmes that win will be the ones that unify governance instead of creating a separate AI exception lane.

Identity blast radius becomes the right metric for agentic AI governance. The article's infrastructure framing is directionally correct because the damage from a compromised agent is measured by how far its permissions and integrations can reach. That is a stronger lens than simple model trust or prompt hardening. Security leaders should evaluate agents by the systems they can touch, the data they can expose, and the actions they can chain.

From our research:

• 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface.
• 92% of organisations agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to the same report.
• For a broader control model, see OWASP Agentic AI Top 10 for the risk categories practitioners need to map into governance.

What this signals

Identity blast radius is the governance metric that will separate mature programmes from experimental ones. If an agent can query data, trigger workflows, and reach connected tools, the relevant question is how far its authority extends before detection or containment kicks in. Mature teams will measure reachable systems, sensitive data exposure, and task-level privilege, then align those metrics to NIST AI Risk Management Framework thinking.

The operational risk is no longer confined to AI teams. IAM, PAM, and IGA owners will increasingly need joint ownership for agent discovery, entitlement review, and offboarding because agent identity now overlaps with workload identity and privileged access management. That makes lifecycle governance, not just model policy, the durable control surface.

As deployments scale, the biggest failure mode will be unmanaged exceptions. Agents that start as pilots often accumulate permissions, connectors, and approval bypasses faster than governance can catch up, so security leaders should build review triggers around new integrations, new data sources, and new business workflows.

For practitioners

• Define each agent as a governed identity Create an inventory of all AI agents, MCP connections, service credentials, and data sources they can touch. Assign owners, business purpose, and entitlement boundaries for each one so the agent is treated like an accountable operational identity.
• Constrain runtime authority to task scope Issue short-lived credentials, narrow API scopes, and explicit policy checks for every sensitive action. Use zero standing privilege where possible so the agent cannot retain broad access between tasks or escalate across sessions.
• Monitor agent behaviour as an access signal Log tool calls, data queries, workflow triggers, and privilege changes in a way that can be reviewed by IAM, SOC, and compliance teams. Runtime visibility should show when an agent crosses intended boundaries, not just whether authentication succeeded.
• Separate approval for high-risk actions Require human or policy-mediated approval before agents can execute external transactions, alter records, or access sensitive repositories. Keep those approvals task-specific so they do not become a permanent bypass around governance.
• Extend lifecycle controls to agent identities Apply joiner-mover-leaver logic to agents, including decommissioning, secret revocation, connector removal, and periodic recertification. If the agent is no longer in active use, offboarding must remove both its permissions and its ability to re-establish access.

Key takeaways

• Agentic AI is an identity governance problem because these systems exercise real authority across enterprise tools and data.
• The scale of exposure is rising faster than policy adoption, which means many organisations are deploying autonomous systems with incomplete oversight.
• Practitioners need runtime controls, lifecycle offboarding, and task-scoped privilege before agentic AI becomes a persistent source of unmanaged blast radius.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions — including calling APIs, writing code, and orchestrating other agents — with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• 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.
• Delegated trust: Delegated trust is the decision to let another system or organization issue, validate, or transmit access on your behalf. It is common in cloud and SaaS environments, but it becomes risky when scope, duration, and revocation are not tightly controlled. In NHI governance, delegated trust must be explicit and continuously reviewable.

What's in the full article

AppSOC's full article covers the operational detail this post intentionally leaves for the source:

• The vendor's step-by-step view of why agentic systems behave like infrastructure rather than ordinary software features.
• The specific runtime control questions AppSOC says teams should ask about agent permissions, monitoring, and unsafe actions.
• The article's explanation of contextual policy enforcement across role, situation, behaviour, and trust relationship.
• The secure-by-design development practices the source ties to governed prompt management and human approval for high-risk operations.

👉 AppSOC's full article expands the runtime control model, discovery questions, and secure-by-design practices for agentic systems.

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