Notifications
Clear all
Topic starter
10/06/2026 12:21 am
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.
NHIMG editorial — what this means for NHI practitioners
Questions worth separating out
Q: How should security teams govern agent workflows at runtime?
A: Security teams should govern agent workflows with controls that evaluate prompts, tool calls, and outputs during execution, not only after deployment.
Q: Why do agent workflows need more than static policy enforcement?
A: Agent workflows need more than static policy enforcement because the security problem changes as the workflow moves from input to action to output.
Q: What breaks when agent security only happens after execution?
A: When security only happens after execution, unsafe prompts can shape context, risky tool calls can complete, and sensitive output can already be exposed.
Practitioner guidance
- Instrument runtime checks at every agent checkpoint Define separate evaluations for inbound prompts, tool calls, and tool outputs so policy can intervene before context ingestion, before execution, and before disclosure.
- Classify high-risk agent actions before execution Build rules that flag or block commands, external system interactions, and other actions with security impact before the agent carries them out.
- Integrate existing detections into agent workflows Reuse current security logic where possible, but adapt it to the agent's runtime path so the same policy can evaluate prompts, decisions, and outputs in sequence.
What's in the full announcement
Zenity's full post covers the operational detail this post intentionally leaves for the source:
- How the open-source OpenClaw security infrastructure is structured for implementation in real agent workflows
- Examples of evaluators that inspect prompts, tool calls, and tool outputs at different execution stages
- How teams can plug their own security logic into the framework without redesigning their entire agent stack
- Where Zenity positions the same visibility and control principles across SaaS, cloud, and endpoint environments
👉 Read Zenity's open-source OpenClaw security framework for agent workflows →
OpenClaw runtime controls for agents: what IAM teams need now?
Explore further
11/06/2026 2:06 am
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
12/06/2026 3:40 am
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
