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.
Editorial analysis by NHI Mgmt Group, based on content published by Zenity: “AI Agents, Enterprise Scale, No Compromises: Now via AWS”.
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.
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.
Q: What breaks when an AI agent can chain identity actions across systems?
A: The main failure is control drift.
Practitioner guidance
- 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.
Bottom line: AI agents change the governance problem because they execute actions, chain tools, and cross boundaries rather than simply generating output.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
AI agent security is no longer a side topic, it is now part of core enterprise control design. Once agents can execute across identity, cloud, and data domains, they cease to fit inside single-point security products or narrow workflow assumptions. The security stack has to treat the agent as an active identity-bearing executor, not as a passive application component. Practitioners should map agent control into the same governance conversations they already use for identity and privileged access.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How can organisations tell whether their AI agent controls are working?
A: They should test whether unsafe tool calls are blocked before execution, whether agent telemetry is visible in the same console as identity and cloud risk, and whether overprivileged connections are identified before deployment. If a control only explains what happened after the session, it is not governing the agent effectively.
👉 Read our full editorial: AWS Security Hub Extended puts AI agent governance into scope
AI agent security is no longer a side topic, it is now part of core enterprise control design. Once agents can execute across identity, cloud, and data domains, they cease to fit inside single-point security products or narrow workflow assumptions. The security stack has to treat the agent as an active identity-bearing executor, not as a passive application component. Practitioners should map agent control into the same governance conversations they already use for identity and privileged access.
A few things that frame the scale:
- 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
A question worth separating out:
Q: How can organisations tell whether their AI agent controls are working?
A: They should test whether unsafe tool calls are blocked before execution, whether agent telemetry is visible in the same console as identity and cloud risk, and whether overprivileged connections are identified before deployment. If a control only explains what happened after the session, it is not governing the agent effectively.
👉 Read our full editorial: AWS Security Hub Extended puts AI agent governance into scope
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AWS Security Hub Extended puts AI agent governance into scope