Notifications
Clear all
Topic starter
22/06/2026 10:21 am
TL;DR: AI agent posture and runtime findings can now flow into AWS Security Hub Extended, letting organisations correlate AI agent risk with cloud, identity, email and endpoint signals through OCSF, according to Zenity. The deeper issue is that existing security operations were not built for actors that can invoke tools, chain actions and make decisions autonomously.
NHIMG editorial — what this means for AI and NHI governance
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
What's in the full announcement
Zenity's full article covers the operational detail this post intentionally leaves for the source:
- How the AWS Security Hub Extended integration is activated through the console and AWS Marketplace.
- The specific way Zenity formats AI agent findings for OCSF and Security Hub correlation.
- Operational coverage for Amazon Bedrock AgentCore environments and custom AI agents.
- The product detail behind posture management, inline prevention and runtime response workflows.
👉 Read Zenity's integration details for AI agent security in AWS Security Hub →
AI agent governance in AWS Security Hub: what changes now?
Explore further
22/06/2026 11:13 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: AWS Security Hub now folds in AI agent governance
