Notifications
Clear all
Topic starter
09/06/2026 11:44 pm
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.
NHIMG editorial — based on content published by Zenity: AI Agents, Enterprise Scale, No Compromises: Now via AWS Security Hub Extended
Questions worth separating out
Q: How should security teams govern AI agents that can act across multiple systems?
A: Security teams should govern AI agents as active executors with scoped authority, not as passive applications.
Q: Why do AI agents complicate existing IAM and security controls?
A: AI agents complicate IAM because they can chain actions across systems in a single workflow, often faster than human review cycles can react.
Q: What breaks when organisations rely on detection after an agent acts?
A: What breaks is containment.
Practitioner guidance
- Map every agent to its effective authority Inventory which tools, data sources, and downstream systems each agent can reach, then compare that reach with the business task it is supposed to perform.
- Move guardrails to the point of execution Enforce policy when the agent is about to call a tool, share data, or cross a boundary, because alerting after the fact cannot contain a completed action.
- Correlate agent findings with identity and cloud telemetry Feed agent posture, runtime anomalies, and security alerts into the same operational view used for identity and cloud risk so that agent behaviour is analysed as part of the broader attack path.
What's in the full article
Zenity's full research covers the operational detail this post intentionally leaves for the source:
- How Zenity integrates AI agent findings into AWS Security Hub Extended using OCSF for correlated triage
- The runtime guardrail model for blocking unsafe agent actions before data exfiltration or tool misuse
- The Bedrock AgentCore coverage model for continuous exposure management across the agent lifecycle
- Example attack-path correlation across phishing, prompt injection, overprivileged tools, and response blocking
👉 Read Zenity's analysis of AI agent security in AWS Security Hub Extended →
AI agent governance at AWS scale: what changes for security teams?
Explore further
10/06/2026 2:11 am
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
