OpenClaw security controls shift agent governance into runtime

At a glance

What this is: Zenity's OpenClaw security infrastructure adds runtime detection and blocking inside agent workflows so teams can evaluate prompts, tool calls, and outputs as they happen.

Why it matters: It matters because IAM, NHI, and AI governance teams need controls that operate at execution time, not just at provisioning time, when agents can change behavior mid-workflow.

👉 Read Zenity's open-source OpenClaw security framework for agent workflows

Context

OpenClaw agent governance fails when security controls only exist outside the execution path. In practice, that means risky prompts, tool calls, and outputs can move through an agent workflow before anyone can inspect or stop them, which leaves identity and privilege decisions too far removed from runtime behavior.

For IAM and NHI teams, the issue is not whether agent activity can be logged after the fact. The question is whether policy can intervene while the agent is still making decisions, especially when tools, prompts, and downstream actions all sit inside the same execution chain.

Key questions

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. Runtime checks matter because risk can appear at each stage of the workflow. The goal is to stop unsafe behavior before it becomes an executed action or a leaked response.

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. A fixed policy can miss unsafe tool use or information leakage that only appears at runtime. Security has to follow the workflow, not sit outside it.

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. At that point, the control is investigative, not preventive. The main failure is losing the chance to intervene while the agent is still deciding.

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.

How it works in practice

Runtime evaluators in OpenClaw agent workflows

OpenClaw's security model centers on evaluators, which are modular checks that inspect agent activity during execution. An evaluator can assess inbound prompts, tool requests, or tool outputs and then decide whether the workflow continues. This matters because agent risk does not live in one place. A prompt may carry sensitive data, a tool call may request unauthorized action, and an output may expose secrets after execution. The architecture is therefore less about one control point and more about a sequence of inspection points embedded in the workflow itself.

Practical implication: place policy decisions inside the agent execution path rather than around it.

Prompt inspection, tool-call control, and output filtering

The framework separates three moments that often get collapsed into one governance conversation. First, prompts can be inspected before they enter context. Second, tool calls can be checked before execution, which prevents an agent from carrying out an unsafe action. Third, outputs can be reviewed after a tool returns, which catches leakage that only appears in the response. That sequencing is important because different identity risks appear at different stages. A single allowlist is not enough when the risk changes from input handling to execution to disclosure.

Practical implication: map different checks to input, execution, and output stages instead of relying on one generic control.

Why agent security needs extensible controls

Zenity presents OpenClaw as a flexible framework rather than a fixed policy engine, which means teams can plug in their own logic and existing tooling. That extensibility matters because agent environments differ widely across models, tools, and workflows. A rigid control that works in one environment may fail in another when tool behavior, context size, or downstream integration changes. The deeper architectural point is that agent security has to adapt to the workflow, not force the workflow to fit one static control model.

Practical implication: build reusable security logic that can adapt across agent workflows, tools, and environments.

NHI Mgmt Group 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.

Prompt, tool, and output checks expose three different trust failures. An inbound prompt can carry hidden data, a tool call can overstep its intended scope, and a tool response can leak information even when the action looked safe. These are not the same control problem, so treating them as one policy domain leaves blind spots. Practitioners need to think in terms of inspection stages, not just entitlement states.

Extensible controls matter because agent workflows are too variable for static security patterns. The article points to a flexible framework that can accept custom logic and integrate existing tooling, which is the right direction for environments where agents differ by model, context, and downstream systems. The field is moving toward workflow-native security rather than one-size-fits-all guardrails. Teams should expect governance to become more composable, not more uniform.

OpenClaw is another sign that agent security is converging with broader NHI governance. Once a software actor can decide when to call tools and how to proceed through a workflow, security teams have to manage it as an identity with operational constraints rather than a simple application feature. That puts agent controls in the same conversation as privilege scope, monitoring, and lifecycle governance. The practitioner takeaway is that AI agent control design now belongs inside identity programmes, not beside them.

From our research:

• 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.
• From our research: Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems, showing how scope discipline changes security outcomes.
• For a broader view of governance maturity, review the NHI Lifecycle Management Guide for lifecycle, offboarding, and control design patterns that translate well to agent oversight.

What this signals

Runtime agent governance is moving from optional hardening to baseline control design. The practical signal for programmes is that prompt filters and workflow blocks now need to be treated as part of identity control, not as a separate AI add-on. With 52% of security leaders already saying AI decision-making power is shifting toward platform and infrastructure teams, the operating model is being pulled closer to the systems that execute it.

Workflow-native controls will become the dividing line between observed and governed agents. Teams that can inspect and stop activity inside the workflow will have better leverage than teams that only review logs after the fact. This is where concepts such as runtime control boundary matter: if policy cannot act before tool execution or output release, it is not governing the agent, only documenting it.

As agent estates expand, the programme question is no longer whether to add more reviews. It is whether your current identity model can express stage-specific controls for prompt intake, tool authorization, and output disclosure without turning every workflow into a manual exception process.

For practitioners

• 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. Treat each checkpoint as a distinct control boundary rather than one combined review step.
• 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. Use the execution phase to stop unsafe behavior instead of relying on post-event investigation.
• 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. This helps avoid duplicated controls that fail to keep pace with workflow changes.
• Separate leakage controls from action controls Do not assume that blocking a bad prompt also prevents a dangerous tool call, or that stopping a tool call prevents data exposure in the result. Build different controls for input filtering, execution blocking, and output inspection.

Key takeaways

• Agent governance has to move into the workflow itself because prompts, tool calls, and outputs each create different control failures.
• Static policy outside the execution path leaves identity teams reacting after unsafe actions or disclosures have already happened.
• Practitioners should design stage-specific runtime controls that can inspect, block, and log agent behaviour where it occurs.

Key terms

• Agent Workflow: An agent workflow is the sequence of steps an AI agent follows as it receives input, decides what to do, calls tools, and produces output. In governance terms, the workflow is where security controls need to inspect, allow, or stop behavior while it is still in motion.
• Evaluator: An evaluator is a runtime inspection component that checks an event inside an agent workflow and decides whether the activity should continue. It can examine prompts, tool requests, or tool outputs, giving security teams a place to enforce policy at the moment of action.
• Runtime Control Boundary: A runtime control boundary is the point in execution where security policy can still change the outcome of an agent action. It is more useful than post-event review because it separates observation from prevention and forces controls to act before a workflow is complete.

Deepen your knowledge

OpenClaw runtime agent controls are a practical example of the issues covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are defining governance for AI agents and non-human identities, it is worth exploring.

This post draws on content published by Zenity: OpenClaw needs real security controls; we built them open source. Read the original.