TL;DR: OpenClaw now has open-source security infrastructure that lets teams inspect agent prompts, tool calls, and outputs, then allow, flag, or block activity during execution, according to Zenity. The bigger lesson is that agent governance is moving from policy-on-paper to runtime control, and that shift matters for identity, privilege, and accountability.
Editorial analysis by NHI Mgmt Group, based on content published by Zenity: “OpenClaw Needs Real Security Controls; We Built Them Open Source”.
Key questions
Q: Where do agent controls fail if they only run after execution?
A: They fail when the agent has already consumed context, called tools, or exposed output before anyone can intervene.
Q: Why does runtime context matter more than access checks for AI agents?
A: Runtime context matters because AI agents can change behaviour after access is granted.
Q: What are the signs that agent governance is too shallow?
A: Common signs include prompts being accepted without inspection, tool calls executing without pre-checks, and outputs being trusted before disclosure review.
Practitioner guidance
- Instrument prompts at ingress Inspect inbound messages before they enter agent context, and block sensitive patterns such as credentials, internal identifiers, or disallowed data before reasoning begins.
- Gate tool calls before execution Place enforcement on planned commands and external interactions so unauthorized or risky actions are denied before the agent can carry them out.
- Scan downstream output for disclosure risk Evaluate tool output before it is accepted by the workflow, because safe-looking actions can still expose secrets or sensitive information in the response.
Bottom line: Agent governance now has to operate during execution, because policy written ahead of time cannot stop a live workflow from taking an unsafe turn.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
Runtime agent controls are becoming the governance boundary for AI systems. OpenClaw's model reflects a wider shift in which the security decision has to happen inside the workflow, not only at provisioning or approval time. That matters because agents create risk through sequence, not just through access. The practical conclusion is that identity governance for agents now depends on runtime enforcement points that can see and stop behavior before completion.
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.
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, showing how scope discipline changes security outcomes.
A question worth separating out:
Q: How do teams decide where to block agent activity?
A: Teams should block agent activity at the stage where the risk appears. Prompts need input filtering, tool calls need execution checks, and outputs need disclosure review. That staged approach prevents a single control from being asked to do three different jobs and missing all three.
👉 Read our full editorial: OpenClaw security controls shift agent governance into runtime
Runtime enforcement is now the governance boundary for agent identity. Static policy does not control an agent that can evaluate context, choose tools, and act inside a live workflow. The article shows that the real question is not whether the agent was approved, but whether its current execution can still be stopped. Practitioners should treat runtime inspection as the point where identity governance becomes real.
A few things that frame the scale:
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to the State of Secrets in AppSec.
- Software supply chain attacks were projected to cost organisations $60 billion in 2025.
A question worth separating out:
Q: How should security teams decide where to place agent authorization controls?
A: Teams should place authorization controls at the point where the action becomes consequential, such as a vault, transfer rail, production record, or sensitive tool call. That is where the system can evaluate current context, purpose, and delegated authority before damage occurs. Inventory helps, but runtime control decides.
👉 Read our full editorial: OpenClaw security controls shift agent governance into runtime