TL;DR: Agentic AI is moving from content generation into autonomous workflow execution, meaning enterprise risk now sits in what these systems are allowed to do, not just what they produce, according to AppSOC. The governance gap is that critical infrastructure is being deployed without identity, authorization, and runtime controls built for autonomous actors.
At a glance
What this is: AppSOC argues that agentic AI is becoming enterprise infrastructure and that the real security issue is governed access, not just model output.
Why it matters: IAM, PAM, and NHI teams need to treat AI agents as operational actors whose permissions, runtime actions, and oversight must be controlled like other critical systems.
Context
Agentic AI changes the identity problem because the system is no longer only producing content. It is planning, selecting tools, and executing workflows inside enterprise applications, which means the security model has to govern action, not just output.
That shift matters for identity programmes because an AI agent with access to APIs, SaaS platforms, and data repositories behaves like an operational actor in the environment. Existing controls built for static application access or human approval loops do not fully cover that behaviour.
The article frames this as an infrastructure question, not a model-safety question. Once agentic systems sit in the middle of business processes, identity, authorisation, and runtime governance become the control plane that determines whether the deployment is trustworthy or simply powerful.
Key questions
Q: What breaks when agentic AI is deployed without formal security policies?
A: Without formal policies, agentic AI can accumulate access, generate defects, and trigger unsafe actions faster than security teams can govern them. The result is not just more alerts but an expanding remediation backlog, unclear accountability, and higher breach exposure when agents reach code, secrets, or production systems. Governance has to exist before scale, not after incidents prove the gap.
Q: Why do autonomous AI agents increase infrastructure risk?
A: They can spend operational privilege at machine speed without a human deciding each step. That means a single poisoned input can become an infrastructure change, a privileged workload, or a destructive action before traditional review cycles have any chance to intervene.
Q: How do security teams know if agentic runtime controls are working?
A: They are working when investigators can reconstruct each session, see tool use and action sequencing, and verify that unsafe behaviour was blocked before sensitive data was exposed. If teams can only say an agent was active, the controls are too shallow. Effective governance produces evidence of containment, not just activity logs.
Q: When should organisations require human approval for an AI agent action?
A: Require human approval when the action could change infrastructure, expose sensitive data, move laterally across systems, or trigger a business-critical workflow that is hard to reverse. Approval is also warranted when the agent’s decision depends on ambiguous input or external data that cannot be trusted at face value. High-consequence actions need a human stop point.
Technical breakdown
Why agentic AI behaves like infrastructure
Generative AI produces outputs in response to prompts, but agentic AI can plan tasks, call tools, and execute workflows. That makes the system more like a platform component than a chatbot because other services depend on it to complete operational work. In identity terms, the important shift is from read-only interaction to action-bearing access. Once an agent can query data, trigger SaaS actions, or chain tool calls, the security boundary is no longer the model alone. It is the combination of identity, authorisation, and runtime context around each action.
Practical implication: model the agent as an operational actor with scoped permissions, not as a passive application feature.
Identity and authorisation for AI agents
An agent that can act across systems needs a verifiable identity and a policy boundary around what it may do. The article points to discovery, contextual policy, and zero-trust authorisation at the gateway layer as the core control pattern. That matters because agent permission is not just authentication at login. It is continuous authorisation across tools, APIs, and data systems as tasks unfold. Without that separation, the agent inherits broad trust from the environment and can move from one allowed action to another without meaningful guardrails.
Practical implication: separate agent identity from tool access and enforce policy decisions at runtime, not only at provisioning.
Runtime governance for autonomous workflows
Autonomous workflows create risk because the security question becomes what the system is allowed to do at runtime, not only what it can generate. The article’s examples include unintended actions, unsafe process triggers, and exposure of sensitive data through agent access. These are governance failures when the control plane does not see the request, context, or downstream effect clearly enough. In practice, runtime governance has to observe behaviour, not just configuration, because an agent can move through multiple enterprise systems inside one workflow.
Practical implication: monitor agent actions continuously and block unsafe workflow steps before they propagate across systems.
Threat narrative
Attacker objective: The objective is to abuse agent autonomy to reach enterprise data, workflows, or downstream business actions that were not intended to be exposed to that level of access.
- Entry occurs when an agent is granted broad access to enterprise tools, APIs, or data systems as part of a workflow deployment.
- Escalation happens when the same agent is allowed to chain actions across applications without a sufficiently narrow policy boundary.
- Impact follows when an unsafe or unintended action reaches operational systems, exposing sensitive data or triggering business processes that should have been blocked.
Breaches seen in the wild
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
- Gemini CLI prompt injection flaw 2025: Tracebit showed a poisoned README could make Gemini CLI run hidden commands and exfiltrate developer secrets; Google fixed it in 0.1.14.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Agentic AI is not a feature layer, it is an identity layer. Once agents plan tasks, call tools, and execute workflows, they stop behaving like passive software and start behaving like operational actors. That means access scope, runtime context, and downstream authorization decisions become the real control surface. Practitioners should stop asking only what the model produces and start asking what the agent can do inside the enterprise.
The assumption that permissions are fixed at provisioning time collapses when the actor is autonomous. That assumption was designed for identities whose access can be reviewed after the fact. It fails when the system decides which tool to use and when to use it during runtime, because least privilege is no longer a static state. The implication is that governance must move from periodic review to policy enforced at the moment of action.
Agentic AI demands the same governance discipline as cloud infrastructure and privileged access. Cloud platforms are not trusted because they are powerful, but because their boundaries are engineered, monitored, and audited. The same standard now applies to AI agents coordinating enterprise work. If identity controls are absent, the organisation has created a production automation layer without a control plane.
Identity-grade controls: the missing concept is a security model that treats agent identity, tool access, and runtime authorisation as a single governed plane. This is broader than secrets handling or prompt safety. The article shows that the governing problem is whether the system can be trusted to act inside business processes at all. Practitioners should evaluate agent deployments by control plane maturity, not by model capability.
McKinsey-style AI platforms show the concentration risk in operational AI hubs. When an AI platform sits between employees, internal knowledge, and enterprise workflows, a single failure can expose more than a single application boundary would. That concentration effect is why agentic systems should be reviewed like critical infrastructure dependencies. The practitioner conclusion is simple: centralisation without identity governance multiplies blast radius.
From our research library:
- 53% of security leaders expect AI to run major portions of their infrastructure autonomously within the next three years, according to the 2026 Infrastructure Identity Survey.
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- Read next: Agentic AI Security Guide
What this signals
Critical infrastructure logic now applies to agentic AI: if the system coordinates workflows, touches data, and triggers action, it needs the same control expectations as other production layers. That means security teams should evaluate agentic deployments by identity, authorisation, observability, and blast radius, not by model sophistication alone.
The practical shift for IAM and NHI programmes is from provisioning accounts to governing behaviour. Access that can be exercised autonomously must be bounded at the point of use, because periodic review cannot catch decisions made and completed inside a single workflow.
For practitioners
- Inventory every agent, model, and tool chain Map where agentic AI is embedded across the environment, including direct access to SaaS platforms, APIs, and data repositories. Do not rely on application owners to self-report usage because shadow AI tends to appear first in workflow automations and embedded assistants.
- Separate agent identity from tool authorization Assign each agent a distinct identity and evaluate its access to applications and data as a runtime policy problem. The goal is to avoid inherited trust from the surrounding platform and to make each action subject to explicit authorisation.
- Enforce runtime policy at the gateway Use a control point in front of enterprise tools and APIs so every agent request can be checked against role, context, behavioural history, and trust relationship. This is where unsafe actions are denied before they reach business systems.
- Constrain high-risk actions with human approval Require explicit human approval for actions that can change records, trigger transactions, or expose sensitive data. Treat approval as a boundary for irreversible operations, not as a generic oversight checkbox.
Key takeaways
- Agentic AI changes the security problem from content generation to action execution inside enterprise systems.
- The strongest failure mode is over-trust in autonomous access paths that were never designed for runtime decision-making.
- Identity-grade controls, runtime policy, and human gates for high-risk actions are the governance levers that matter most.
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, OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centres on autonomous agents acting with enterprise permissions and needing runtime authorisation. |
| Recommendation — Apply ASI03 controls to bound agent privileges and prevent runtime privilege abuse across tool chains. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | AI agents need identity-grade controls because they authenticate to tools, APIs, and data systems as non-human actors. |
| NHI-05 — Overprivileged NHI | The article warns that agent permissions often exceed what the workflow actually requires. | |
| Recommendation — Use NHI-04 to verify how agent identities authenticate before they are allowed to access enterprise resources. Use NHI-05 to reduce agent access scope and remove unnecessary permissions from autonomous workflows. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The article describes agents moving across systems and accessing multiple enterprise resources. |
| Recommendation — Map agent tool reach to TA0006 and TA0008 to detect overly broad access paths and cross-system movement. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The piece argues that agentic AI needs governed permissions, entitlements, and runtime authorisation. |
| Recommendation — Apply PR.AA-05 to enforce least-privilege authorisation for every agent action. | ||
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-grade controls: Identity-grade controls are governance and enforcement mechanisms that treat an AI system like a privileged operational actor. They cover authentication, authorisation, monitoring, and approval boundaries so the system cannot act beyond its intended scope across enterprise tools and data.
- 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.
- Operational hub: An operational hub is a system that sits between users, data, and business workflows and therefore concentrates access and control. When an AI platform becomes an operational hub, a single failure can expose many downstream systems and amplify the impact of misconfiguration or compromise.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on August 15, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org