AWS Security Hub Extended puts AI agent governance into scope

At a glance

What this is: AWS Security Hub Extended now includes AI agent security findings, and the core finding is that agent behaviour must be governed at runtime, not after the fact.

Why it matters: That matters because IAM, NHI, and human identity programmes all depend on assumptions about who initiates action, how access is reviewed, and when control is still possible.

👉 Read Zenity's analysis of AI agent security in AWS Security Hub Extended

Context

AI agent governance is the problem space here: an agent does not just answer a request, it executes actions, calls tools, and can move across systems in a single workflow. The security gap appears when organisations treat that behaviour like ordinary automation or ordinary user activity, because neither model captures independent runtime action.

Zenity's point is that enterprise security is already being forced to account for agent behaviour in the same stack that handles identity, endpoint, cloud, and email risk. For IAM and NHI teams, the implication is straightforward: if the actor can act across domains during execution, governance has to follow the action path rather than the application boundary.

Key questions

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. That means mapping tool access, data reach, and downstream system impact for each agent, then enforcing policy at the moment of execution. A control model that only watches logs after the fact will miss the real risk: completed actions.

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. That breaks the assumption that identity is only a requester. When the actor also selects tools and executes timing independently, access governance has to follow behaviour, not just entitlement.

Q: What breaks when organisations rely on detection after an agent acts?

A: What breaks is containment. Once an agent has already moved data, invoked a tool, or triggered a downstream action, the harmful event is committed and the blast radius has expanded. Post-execution detection still matters for investigation, but it is no substitute for controls that stop unsafe agent actions before completion.

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.

Technical breakdown

Runtime agent execution and cross-system tool chaining

AI agents are different from conventional workflows because they do not stop at a generated response. They maintain state, invoke tools, and chain actions across connected systems, which creates an execution path that can cross identity boundaries in a single session. In practical terms, that means a manipulated prompt can become an operational action if the agent has the authority to call CRM, collaboration, or production tools. Traditional controls that focus on network perimeters or endpoint events miss the fact that the risky event is the agent's decision to act, not the request that triggered it.

Practical implication: Instrument agent actions at the point of execution, not only at the application or network edge.

Why post-execution detection fails for AI agents

The article's core security argument is that anomaly detection after exfiltration is too late for agentic systems. Once an agent has executed a tool call, moved data, or expanded its own working context, the blast radius has already increased. This is a timing problem, not just a tooling problem. Security programmes built for human-paced investigations assume there will still be a remediable state after an alert. For agents, the harmful state may already be committed by the time the alert appears.

Practical implication: Design guardrails that stop unsafe tool use before data moves or actions complete.

Configuration-to-runtime drift in AI agent security

The article draws a sharp line between configuring an agent safely and governing it safely in production. Excessive permissions, unnecessary data connections, and missing guardrails create exposure before runtime begins, and those choices are often invisible once the agent is live. This is where agent security overlaps with NHI discipline: access scope, tool permissions, and data reach all become part of the control surface. If the build-time configuration is wrong, runtime monitoring is only limiting damage, not correcting design.

Practical implication: Review agent permissions and data connections before deployment, then continuously verify them after launch.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group 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.

The assumption that humans initiate action and systems only respond has collapsed. That assumption was designed for a world where users click, workflows trigger, and systems wait. It fails when the actor is an agent because the agent can choose actions, chain tools, and continue execution without a human approval gate between decisions. The implication is not merely stronger monitoring, but a rethink of which governance models still depend on human-paced intervention.

Runtime visibility is now a governance requirement, not an operational nice-to-have. The article's strongest point is that configuration risk and runtime risk are joined, not separate. If the platform can correlate posture, anomalies, and threats in the same operating view, then security teams can finally reason about the agent's full attack path rather than isolated alerts. Practitioners should treat runtime agent telemetry as a control layer in its own right.

Named concept: agent action gap. This is the difference between being able to configure an agent and being able to stop it at the moment it acts. The gap appears when governance tools understand the environment but not the agent's execution timing or tool-chaining behaviour. That matters because agent security fails at the exact point where the organisation still believes policy alone is enough.

From our research:

• 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.
• That governance gap is why teams should also review OWASP Agentic AI Top 10 when defining runtime controls and approval boundaries.

What this signals

Agent action gap: security teams need a term for the space between an agent being configured and an agent being stopped at execution time. That space is where policy-only programmes fail, because the organisation can know the permissions and still miss the moment of action. The practical signal is whether your control stack can intercept agent tool use before data leaves the session.

With 52% of companies able to track and audit the data their AI agents access, a large share of the market still lacks even basic agent visibility, per AI Agents: The New Attack Surface report. That makes agent governance a structural programme issue, not a tooling preference. Teams should expect agent findings to sit alongside identity, cloud, and data telemetry, not in a separate console.

For practitioners building on AWS, the next planning question is whether their current identity and access model can describe what an agent is allowed to do at runtime, not just what it was assigned at deployment. The OWASP Top 10 for Agentic Applications 2026 is a useful reference point for mapping those control gaps to actual attack patterns.

For practitioners

• 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. Treat overbroad access as an execution risk, not just a permissions issue.
• 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. Block high-risk actions before the session completes.
• 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.
• Rework approval assumptions for autonomous execution Audit governance processes that assume a human will remain in the loop long enough to review or interrupt a bad action, then redesign those controls for actors that can continue without a review pause.

Key takeaways

• AI agents force security teams to govern execution, not just entitlement, because the risky event is the action the agent takes.
• The evidence point is clear: broad agreement that governance matters has not translated into policy adoption or audit visibility at the same pace.
• Practitioners should move controls to the point of execution and treat agent telemetry as part of the core identity and cloud control plane.

Key terms

• AI Agent: A software entity that can choose actions, call tools, and determine execution timing without a human approval gate for each step. In security governance, that behaviour makes the agent an active identity subject, not just an application feature, because access must be managed against runtime decisions as well as configured permissions.
• Runtime Guardrail: A control that evaluates an agent's planned action at the moment it is about to execute. Runtime guardrails matter because configuration checks alone cannot stop a harmful tool call once the agent has already decided to act, especially when the action crosses system or data boundaries.
• Agent Action Gap: The distance between what an organisation can configure for an agent and what it can actually stop when the agent acts. The gap appears when permissions, data access, and execution timing are not governed together, leaving a window where the agent can complete unsafe actions before detection or review.
• Cross-System Tool Chaining: The pattern where an AI agent moves from one tool or system to another within a single workflow, carrying context and authority across boundaries. This creates a broader attack surface than isolated application calls because one manipulated step can trigger a sequence of connected actions.

Deepen your knowledge

AI agent governance and runtime control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for agentic systems that can act across tools and data, it is a relevant next step.

This post draws on content published by Zenity: AI Agents, Enterprise Scale, No Compromises: Now via AWS Security Hub Extended. Read the original.