TL;DR: CSA’s Autonomous Action Runtime Management initiative frames runtime governance as the control point where agentic systems turn intent into real-world action, with open specification features such as action interception, policy evaluation, approval routing, and tamper-evident receipts described in the source article from Noma Security. The practical challenge is not model quality alone but whether enterprises can govern autonomous action without fragmented proprietary architectures that will be hard to operationalize later.
NHIMG editorial — based on content published by Noma Security: why co-chairing CSA’s Autonomous Action Runtime Management initiative matters
By the numbers:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security.
- 70% of organisations grant AI systems more access than they would give a human employee performing the exact same job.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, making over-privileged systems 4.5x more likely to experience a security incident.
Questions worth separating out
Q: How should security teams govern AI agents that can change behaviour at runtime?
A: Security teams should govern AI agents with runtime monitoring, behavioural baselines, and identity-triggered response, not just static approval workflows.
Q: Why do AI agents make non-human identity governance harder?
A: AI agents make governance harder because they can request tools, act autonomously, and change behaviour across sessions while still relying on machine credentials.
Q: What do organisations get wrong about AI agent authorisation?
A: They often treat agent access as a tooling problem instead of an identity problem.
Practitioner guidance
- Define the agent action boundary Map which AI-driven actions count as security-relevant events in your environment, then require policy evaluation before execution rather than after the fact.
- Separate upstream controls from runtime controls Keep prompt security, retrieval protection, and orchestration hardening in place, but add a distinct runtime enforcement layer for tool use, escalation, and deferral.
- Classify agent pathways by enforcement depth Differentiate self-hosted agents, SaaS agents, and delegated workflows so you can choose network, code, host, or policy-only controls where they actually fit.
What's in the full article
Noma Security's full post covers the operational detail this analysis intentionally leaves for the source:
- The full AARM component model and how action mediation, context accumulation, and deferral are intended to work together.
- The threat categories the specification is designed to address, including prompt injection, confused deputy behaviour, and intent drift.
- The implementation options for different environments, including network, code, host, and policy-only enforcement paths.
- The governance implications of joining the CSAAI Foundation under vendor-neutral oversight.
👉 Read Noma Security's analysis of CSA AARM and runtime governance for agentic AI →
Agentic AI runtime governance: what practitioners need to know?
Explore further
Runtime governance is becoming the missing control plane for agentic AI. Upstream model safety, data protection, and orchestration hardening remain necessary, but they do not answer the question of what an agent is allowed to do at the moment of action. The article is right to position the action boundary as the point where AI becomes operational risk. For identity programmes, this means the control problem shifts from access granted at setup to authorisation enforced at runtime, which is a different governance model entirely.
A few things that frame the scale:
- Only 44% of organisations have implemented any policies to manage their AI agents, despite 92% agreeing that governing AI agents is critical to enterprise security, according to The 2026 Infrastructure Identity Survey.
- With 70% of organisations granting AI systems more access than they would give a human employee doing the same job, the access model itself is already out of sync with current practice.
A question worth separating out:
Q: How do teams know if runtime governance for agents is working?
A: Look for evidence that sensitive actions are being intercepted, evaluated, and either approved, modified, deferred, or denied before execution. You should also see tamper-evident receipts, consistent telemetry into SIEM and SOAR, and a clear reduction in unsafe autonomous actions crossing policy boundaries.
👉 Read our full editorial: Runtime governance for agentic AI needs a shared control model