AWS Security Hub now folds in AI agent governance

At a glance

What this is: This is an integration that brings AI agent security signals into AWS Security Hub so practitioners can govern agent posture, runtime behaviour and correlated threats from one operations view.

Why it matters: It matters because AI agents behave like non-human identities with tool use and runtime decision paths, which means IAM, SOC and governance teams must treat them as a distinct security layer.

👉 Read Zenity's integration details for AI agent security in AWS Security Hub

Context

AI agent governance is becoming a security operations problem, not just a product configuration problem. When an agent can access systems, invoke tools and chain actions, traditional identity and alerting models need a way to see posture, runtime behaviour and adjacent enterprise threats together. This integration is aimed at that visibility gap, especially for teams already running AWS-centric operations.

The practical issue is that AI agents inherit identity, privilege and telemetry questions that sit across IAM, cloud security and detection engineering. If those signals stay fragmented, security teams cannot reliably tell whether an agent is merely present, overprivileged, or actively crossing a trust boundary during execution.

Key questions

Q: How should security teams govern AI agents that can invoke tools and chain actions?

A: Security teams should govern AI agents as non-human identities with both posture and runtime controls. That means discovering the agent, defining its intended access, monitoring live behaviour and correlating its activity with cloud and identity signals. If the agent can act independently, governance has to cover what it can do while it is running, not only what was approved at design time.

Q: Why do AI agents create different identity risks than ordinary automation?

A: AI agents create different risks because they can choose actions, invoke tools and adapt behaviour during execution. Ordinary automation follows a fixed path, but an agent can drift into unsafe scope if prompts, memory or external context change. That makes runtime authorisation and behavioural monitoring essential, not optional, for security teams.

Q: What should organisations look for when evaluating AI agent security controls?

A: Organisations should look for discovery, privilege assessment, runtime detection and integration with existing security operations. A useful control set shows what agents exist, what they can reach, when they exceed intended behaviour and how those findings connect to broader enterprise threats. Without all four, agent governance remains partial and hard to operationalise.

Q: Who should own AI agent governance in an enterprise security programme?

A: AI agent governance should sit across identity, cloud and security operations rather than in a single silo. Identity teams own entitlements, cloud teams own environment exposure and SOC teams own correlation and response. The practical ownership model is shared, because an agent risk can start as an identity issue and end as an incident response problem.

How it works in practice

How AI agent findings enter Security Hub through OCSF

The integration maps AI agent posture and runtime findings into the Open Cybersecurity Schema Framework, or OCSF, so they can appear alongside other enterprise security signals in AWS Security Hub. That matters because OCSF standardises event structure, making agent events easier to correlate with cloud, identity and endpoint findings without building a separate analyst workflow. The architecture is not just ingestion. It is about making agent risk queryable in the same operational plane as the rest of the security stack, which changes how investigations are triaged.

Practical implication: normalise agent telemetry into your existing security schema so AI agent activity can be investigated alongside cloud and identity events.

Why posture and runtime monitoring both matter for AI agents

AI agent security is not just about discovering that an agent exists. Posture management identifies overprivileged agents, unsafe configurations and missing controls before execution, while runtime monitoring looks for behaviours such as indirect prompt injection, unsafe tool use and unexpected memory access. For agents, those two views are inseparable because the risk often emerges only after the agent begins acting on live context. A posture-only programme misses active abuse. A runtime-only programme misses the privilege conditions that made the abuse possible.

Practical implication: pair discovery and posture review with runtime detections so agent risk is assessed before and during execution.

Correlating AI agent risk with broader enterprise attack paths

The operational value here is correlation. By placing AI agent findings next to cloud, identity, email and endpoint alerts, analysts can treat an agent as part of a larger attack path rather than as an isolated workload. That is especially relevant when an agent can reach SaaS apps, invoke tools and consume memory that influences later actions. The security question becomes whether the agent is a standalone concern or a pivot point inside a wider compromise chain.

Practical implication: investigate AI agent alerts in the context of broader attack-path analysis, not as isolated point detections.

NHI Mgmt Group analysis

AI agent security is now a governance layer, not a point control. Once an agent can access systems, invoke tools and chain actions, it behaves like a non-human identity that needs lifecycle visibility, runtime oversight and incident correlation. Treating it as a feature of another platform hides the governance problem inside tooling. Practitioners should recognise that agent behaviour must be governed as part of the identity stack, not only the detection stack.

Posture and runtime are the two sides of the same AI agent risk model. Continuous discovery tells you what exists and what is overprivileged, while runtime telemetry shows whether that privilege is being used safely. Separating the two creates blind spots because unsafe tool use and prompt injection often only become visible after the agent has already acted. The implication is that AI agent governance cannot be reduced to static inventory or alerting alone.

Identity operations need a shared control plane for cloud, human, and agent signals. This integration reflects a broader market direction in which security teams will expect identity, endpoint and workload findings to converge. That trend validates the idea that AI agents are part of enterprise identity governance, but it also complicates existing programme boundaries because the same control plane now has to explain human, machine and agent behaviour together. Practitioners should prepare for governance models that cross those boundaries by design.

Runtime authorisation for AI agents is becoming the decisive concept. The central question is no longer whether an agent was approved at build time, but whether its live actions remain within the intended scope once tools, memory and external context are in play. That shifts focus from static entitlement review to operational containment. Security teams should treat runtime authorisation as a distinct governance problem for autonomous behaviour.

Assumption collapse: access review processes were designed for actors whose privileges persist long enough to be reviewed. That assumption fails when an AI agent can acquire context, invoke tools and complete actions in the same runtime window. The implication is not simply that reviews must happen faster. It is that the review model itself no longer captures the moment when the risky behaviour occurs.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• Another finding in the same research shows that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% reporting only partial visibility.
• That visibility gap is why our Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs is useful for teams turning identity discovery into lifecycle control.

What this signals

Runtime authorisation for AI agents is becoming a programme design issue. Security teams that treat AI agents as just another workload will miss the fact that their risk changes during execution. The next step is to align identity, detection and response around agent behaviour, not only around provisioning events, and to anchor that model in the NIST Cybersecurity Framework 2.0.

AI agent governance will pull IAM and SOC into the same operating model. Discovery alone will not be enough once agents can invoke tools and chain actions across environments. Teams should expect more pressure to unify entitlement review, runtime detection and incident triage in one control plane, especially where OWASP Agentic AI Top 10 risks are already shaping review criteria.

For practitioners

• Map AI agent telemetry into your security data model Use OCSF or an equivalent normalised schema so posture, runtime and detection events for AI agents can be correlated with cloud, identity and endpoint findings.
• Separate discovery from runtime control Track which agents exist, which entitlements they hold and which tools they invoke, then use that inventory to drive live policy and alerting.
• Review agent privilege like workload identity Assess whether each agent has only the access needed for its task, and remove standing access that is not required for execution.
• Add prompt-injection and memory-access detections Create detections for indirect prompt injection, unexpected memory reads and unauthorised tool calls so runtime misuse is visible before business impact.
• Investigate agent events inside broader attack paths When an agent alert fires, trace adjacent cloud, identity and endpoint activity so the incident is analysed as a cross-domain compromise path, not an isolated alert.

Key takeaways

• AI agents are now part of the identity governance problem because they can act, choose tools and change behaviour at runtime.
• The operational risk is not just discovery failure, but the combination of overprivilege, runtime misuse and poor correlation with existing security signals.
• Practitioners should treat agent posture, runtime detection and enterprise attack-path correlation as one control plane, not three separate projects.

Key terms

• AI Agent Posture: The standing condition of an AI agent before it begins acting, including its assigned access, configuration, and policy boundaries. In practice, posture tells security teams whether the agent is overprivileged, misconfigured, or missing guardrails before runtime behaviour creates exposure.
• Runtime Authorisation: The decision boundary that governs what an AI agent is allowed to do while it is actively executing. Unlike static provisioning, runtime authorisation has to account for tool use, changing context, and behaviour that can drift during a session, which makes it central to autonomous governance.
• OCSF Normalisation: The process of translating different security events into a common schema so they can be searched and correlated consistently. For AI agents, this helps posture, detection, and response data sit beside cloud and identity telemetry instead of remaining isolated in a separate product view.
• Agent Scope Drift: A condition where an AI agent’s live behaviour exceeds the intent defined for it at setup or approval time. This can happen when prompts, tools, memory, or external context alter execution, making the original permission model an incomplete picture of real risk.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Zenity: Zenity selected for AWS Security Hub extended to secure enterprise AI agents. Read the original.