TL;DR: AI agents break the security model built for human-initiated action, because they execute, chain tools across systems, and expand blast radius before traditional tools can react, according to Zenity. The issue is not visibility alone, but a governance model that assumes action can be reviewed after it happens.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Zenity's blog post: AWS Security Hub Extended now treats AI agent governance as part of the enterprise security stack, because agents execute actions, chain tools, and cross identity boundaries faster than conventional review-based controls can respond.
Why it matters: That matters for IAM, PAM, and NHI teams because AI agents are no longer a niche edge case; they are acting across cloud, identity, and data layers, so governance has to move to configuration, runtime guardrails, and continuous correlation.
Context
AI agent governance is the practice of controlling what autonomous or semi-autonomous software actors can access, invoke, and do across enterprise systems. The governance problem appears when the agent can maintain state, invoke tools, and cross identity boundaries in a single workflow, while traditional controls still assume a human initiates the action.
Zenity's article frames AWS Security Hub Extended as evidence that AI agent risk has moved into mainstream security operations, not because the threat is theoretical, but because the operational gap is now visible at enterprise scale. The core issue is that configuration-time approval and after-the-fact review do not keep pace with runtime execution.
For IAM and NHI programmes, the article's message is straightforward: AI agents should be treated as governed identities with scoped permissions, observable behaviour, and clear revocation paths. Once an agent can chain actions across cloud and identity domains, the security model has to follow the actor rather than the application boundary.
Key questions
Q: How should security teams govern semiautonomous AI agents before they go live?
A: Start with task-scoped permissions, explicit credential lifecycles, and human oversight points before deployment volume makes retrofits impractical. Semiautonomous agents need pre-authorization for irreversible actions, auditable delegation chains, and revocation that matches task completion or compromise. If those controls are missing at launch, the programme will scale the gap instead of the capability.
Q: Why do user access reviews miss the real risk from AI agents?
A: They only test the user’s direct entitlements, not the broader actions the user can trigger through an agent. If the agent holds wider privileges in finance, ERP, or operations, the effective access is much larger than the review shows. That is why auditors need to examine delegated execution paths, not just the human account.
Q: What breaks when an AI agent can chain identity actions across systems?
A: The main failure is control drift. Once one request can create tickets, update records, and trigger follow-on actions, a single prompt can become a multi-step execution path with a much larger blast radius. Teams lose the ability to reason about the request as one bounded event unless each step is separately authorized and audited.
Q: What should teams do when agent findings appear alongside cloud and identity alerts?
A: Teams should investigate the alerts as one attack path, not separate tickets. Correlating agent telemetry with identity, email, and cloud events helps reveal whether a manipulated prompt led to an overprivileged action, which is the sequence that determines containment priorities and ownership.
Technical breakdown
Why AI agents break the review-after-the-fact model
AI agents are different from conventional automation because they do not simply run a fixed script. They hold state, choose tools during execution, and continue across multiple turns or sessions while acting on behalf of a user, workflow, or another agent. That means the security event is not only the action, but the sequence of decisions leading to it. If an agent can be induced by prompt injection or mis-scoped context to take a harmful action, the control problem has already moved into runtime. Detection that arrives after data has moved only documents the impact. Practical implication: govern the agent before execution, not after the fact.
Practical implication: shift controls from post-action review to runtime authorisation and guardrail enforcement.
How exposure accumulates between configuration and runtime
The article separates configuration risk from runtime risk. An agent configured with excess permissions, sensitive data connections, or broad tool integrations carries exploitable exposure before it ever executes a task. That exposure is not hypothetical, because the permissions and context are already present when the agent enters production. In NHI terms, this is a governed identity problem, not just an application bug. The security question is whether the agent's access boundary was established with the same care used for any privileged workload. Practical implication: treat permissions, data connections, and integrations as part of the identity lifecycle.
Practical implication: review agent permissions and integrations as lifecycle controls, not one-time deployment settings.
Why cross-domain correlation matters for AI agent governance
AI agent findings become more actionable when they are correlated with identity, cloud, endpoint, and email signals in one operational view. The article's example is a phishing email that reaches an employee, followed by prompt injection against an agent, followed by attempted exfiltration through an overprivileged tool integration. That is not a single product problem. It is a chain spanning several control planes, which is why isolated tooling misses the operational picture. Practical implication: connect agent telemetry to the rest of the security stack so the attack path is visible as one event, not three disconnected alerts.
Practical implication: integrate agent telemetry into existing security operations rather than running it as a standalone monitoring stream.
Threat narrative
Attacker objective: The attacker aims to turn a trusted AI agent into a path for unauthorized data movement and broader blast-radius expansion across enterprise systems.
- Entry occurs when a phishing email reaches a user and the user interacts with an agent that has access to production systems.
- Escalation happens when prompt injection influences the agent's runtime behaviour and it attempts to use an overprivileged tool integration.
- Impact is the attempted exfiltration of data across identity and cloud boundaries before the security stack can fully intervene.
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.
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
AI agent governance is now a security stack problem, not a niche AI side issue. Zenity's placement of agent risk inside AWS Security Hub Extended signals that the control plane has moved from specialist tooling into mainstream security operations. That matters because agent behaviour cuts across identity, cloud, email, and data, so no single domain team can govern it alone. Practitioners should treat agent governance as part of the enterprise security stack.
Access review processes assume access persists long enough to be reviewed, but agentic execution can collapse that assumption inside a single workflow. The article's core flaw is not visibility alone; it is the belief that action can be safely inspected after the agent has already executed it. Once an agent can select tools and chain actions in runtime, the old review cadence no longer maps to the real decision window. Practitioners need to rethink the assumption, not just add monitoring.
Continuous exposure management is the named concept that best captures this category shift. The article shows that the risk starts at configuration, because permissions, data connections, and integrations are already exploitable before runtime begins. That means agent security is not a point-in-time control problem but a lifecycle problem spanning onboarding, permission scope, and execution guardrails. Practitioners should govern the full lifecycle of each agent identity.
Overprivileged tool integration is the blast-radius amplifier for AI agents. The example attack path works because an agent with broad access can move from a manipulated prompt to action across production systems and data stores. That turns ordinary misconfiguration into cross-domain exposure, which is why identity, cloud, and SOC teams need a shared model of agent entitlements. Practitioners should measure privilege by reachable action paths, not just assigned roles.
Security Hub correlation only matters if the underlying agent identity is already scoped correctly. Joining a broader security platform helps surface the attack path, but it does not solve the governance problem if the agent was created with excessive permissions or loose data reach. The market signal is that AI agent security is becoming operational infrastructure, and practitioners should evaluate whether their current identity governance model can express that reality.
From our research library:
- 69% of security leaders agree identity management must fundamentally shift to address agentic AI systems, according to the 2026 Infrastructure Identity Survey.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job, according to the 2026 Infrastructure Identity Survey.
- Read next: AI Agent Identity Security Buyer's Guide
What this signals
Continuous exposure management: AI agent governance is shifting from periodic approval to continuous visibility over permissions, integrations, and runtime behaviour. That change matters because the risk is created long before an agent acts, then compounded when the same identity can cross cloud and data boundaries in a single session.
Enterprises that already treat NHI lifecycle control as a governance discipline will find the transition easier than teams trying to bolt agent oversight onto endpoint or SOC tooling. The practical test is whether the programme can answer who owns the agent, what it can reach, and when its access can be withdrawn.
For practitioners
- Define agent identities as governed entities Inventory every AI agent with a unique identity record, named owner, scoped permissions, and explicit revocation path before broad deployment.
- Tighten tool and data integrations at configuration time Review every connected system, knowledge base, and tool integration for necessity, then remove any access that is not required for the agent's task.
- Correlate agent telemetry with security operations Feed agent posture violations, runtime anomalies, and detected threats into the SOC view alongside identity, cloud, and email findings.
- Redesign guardrails for runtime execution Move from post-action review to execution-time controls that constrain what the agent can do during each turn and session.
Key takeaways
- AI agents change the governance problem because they execute actions, chain tools, and cross boundaries rather than simply generating output.
- The article's example shows that a manipulated prompt can become a cross-domain attack path when the agent has overprivileged integrations.
- Effective controls need to move from after-the-fact review to configuration discipline, runtime guardrails, and security correlation across the stack.
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 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | The article centers on agent behaviour across permissions and tool use. |
| ASI02 — Tool Misuse | Prompt injection and overprivileged integrations drive the attack path described. | |
| ASI01 — Agent Goal Hijack | The article describes manipulated prompts steering agent actions. | |
| Recommendation — Apply ASI03 to constrain agent privileges and block excess action paths across tools. Map agent tool chains to ASI02 and remove any integration not required for task execution. Use ASI01 controls to detect when prompts redirect agents toward unintended actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | AI agents acting across systems still depend on governed machine authentication. |
| NHI-05 — Overprivileged NHI | Overprivileged tool integrations are the central exposure in the article. | |
| Recommendation — Enforce NHI-04 by scoping how agent identities authenticate to tools and data sources. Reduce reachable action paths under NHI-05 by trimming agent permissions to task minimums. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about governing what agents are authorised to do. |
| Recommendation — Apply PR.AA-05 to review and constrain agent entitlements before deployment and at change time. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | The attack path moves from manipulated access into harmful action and data movement. |
| Recommendation — Map agent attack paths to TA0006 and TA0040 to prioritise detection of misuse and downstream impact. | ||
| NIST Zero Trust (SP 800-207) | Policy-driven access control — Policy-driven access control | The article argues for runtime enforcement across agent actions and sessions. |
| Recommendation — Apply zero trust policy checks at execution time for every agent action and tool call. | ||
Key terms
- AI Agent Governance: AI Agent Governance is the set of policies, controls, and oversight practices used to direct how autonomous software agents behave. It defines allowed actions, approval paths, identity boundaries, logging, monitoring, and accountability so agent decisions remain traceable, constrained, and aligned with business, security, legal, and ethical requirements.
- Runtime Guardrail: A control applied while an AI agent is operating, not just during configuration or review. Guardrails can block dangerous tool calls, require approval for sensitive actions, or stop data leakage before it reaches systems or users.
- Continuous Threat Exposure Management: Continuous Threat Exposure Management is the ongoing process of finding which assets, identities, and paths are actually reachable from the current environment. It moves risk assessment away from static inventories and toward live exposure, so security teams can prioritise what an attacker or misuse path can reach now.
- Reachable Action Path: The set of actions an AI agent can actually perform once its permissions, tools, and data connections are combined. This is more useful than static role labels because it shows the real blast radius available to the agent during execution.
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 June 9, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org