OpenClaw security controls shift agent governance into runtime

At a glance

What this is: This is Zenity's open-source OpenClaw security infrastructure for inspecting agent prompts, tool calls, and outputs so activity can be allowed, flagged, or blocked during execution.

Why it matters: It matters because agent governance is moving from static policy to runtime control, which changes how IAM, security, and identity teams think about visibility, privilege, and intervention for AI agents.

Context

Agent security fails when controls exist only on paper and do not operate at the moment an agent decides, calls tools, or emits output. In an OpenClaw environment, the identity problem is not just who built the agent, but what the agent is allowed to do while it is running.

Zenity's article argues for security checks inside the execution path, which is the right place to catch sensitive prompts, risky tool calls, and unsafe output before they become actions. For identity programmes, that pushes governance closer to runtime authorisation than traditional review-based control models.

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. In that model, governance becomes observation rather than control. The safer pattern is to enforce decisions at ingress, before tool execution, and before output is accepted back into the workflow.

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. The risk is not only who is authenticated, but whether the agent's observed activity still fits its declared purpose, data scope, and operating environment at the moment it executes.

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. If controls only exist in documentation or dashboards, the agent can still act faster than the governance cycle. That is a runtime gap, not a policy gap.

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.

How it works in practice

Runtime evaluators for agent workflows

OpenClaw's security model centers on evaluators, modular checks that inspect events as an agent runs. An evaluator can look at inbound prompts, a planned tool call, or output from a downstream tool and decide whether the activity should proceed. That matters because the security decision is made on the live execution path, not after the workflow has already consumed context or triggered an action. In identity terms, the control boundary shifts from provisioning-time trust to session-time inspection. The framework is designed to be extended, so teams can insert their own logic rather than rely on a fixed policy set.

Practical implication: Treat agent workflows as runtime decision surfaces and place control logic where actions are still stoppable.

Prompt, tool-call, and output inspection points

The article describes three checkpoints that map cleanly to agent risk. First, inbound messages can be checked before they enter the agent context. Second, tool calls can be evaluated before execution, which is where unauthorized interactions or risky commands can be blocked. Third, output can be inspected after tool execution, because unsafe responses may still reveal secrets or sensitive information even when the action itself looked legitimate. This is a practical control pattern for agentic systems because risk is distributed across the whole execution chain, not concentrated in one authentication event.

Practical implication: Instrument all three checkpoints so the agent cannot move from input to action to disclosure without inspection.

Why static policy is not enough for agent governance

The article's core argument is that agent tooling is evolving faster than its security controls. When the agent can interact with external systems through tools, a static allowlist or paper policy is too blunt to handle real execution paths, especially when risk depends on the content of the prompt or the output produced in-session. That makes governance more like continuous authorisation than one-time approval. For autonomous or semi-autonomous systems, the control must understand context, not just identity, because the dangerous event is often the combination of valid access and unexpected runtime behaviour.

Practical implication: Replace policy-only governance with context-aware runtime enforcement for agent actions and disclosures.

NHI Mgmt Group analysis

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.

Agent governance cannot depend on post-hoc review when the risky decision happens mid-session. Prompts, tool calls, and outputs each create separate failure modes, and any one of them can leak data or trigger an unsafe action. That means review-oriented models from human IAM or conventional NHI oversight are incomplete unless they move closer to execution time. The practical lesson is that control placement matters as much as control design.

OpenClaw-style instrumentation exposes the limit of policy-only agent security. The framework does not solve governance by naming a policy; it solves it by making the workflow inspectable and interceptable. That is the right design pattern for a category where identity, authorisation, and action collapse into one runtime loop. Teams should re-evaluate every agent control that assumes decisions can be safely deferred until after execution.

Continuous authorisation is the right concept for agentic systems, not just continuous monitoring. Monitoring tells you what happened; the article is about deciding whether something should happen at all while the workflow is still active. That distinction matters because an agent can become dangerous without ever violating a traditional login control. Practitioners need enforcement points that can deny or contain the action before the workflow completes.

Agent workflow security creates a new form of identity blast radius. When prompts, tool calls, and outputs are all inspection points, the scope of trust is no longer the account alone but the entire execution chain. That expands governance from credential protection to action containment. The implication is that agent identity programmes must be built around runtime scope, not just around who or what holds access.

From our research library:

• 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.
• Read next: Agentic AI Security Guide

What this signals

Continuous authorisation is the relevant model for agent workflows. Traditional identity programmes often assume a discrete access event, but agentic systems make decisions repeatedly during a single run. Security teams should therefore design controls that can intervene at the moment of action, not only at login or approval time.

Runtime inspectability becomes a governance requirement, not an observability nice-to-have. If prompts, tool calls, and outputs are not all inspectable, teams will miss the exact stage where an unsafe action or disclosure occurs. The practical shift is to treat agent execution as a controlled identity boundary rather than a passive telemetry stream.

For practitioners

• 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.
• Move agent governance to runtime Map every control that still depends on post-run review and replace it with an execution-time decision point that can allow, flag, or block activity.

Key takeaways

• Agent governance now has to operate during execution, because policy written ahead of time cannot stop a live workflow from taking an unsafe turn.
• The control surface spans ingress, tool execution, and output review, so teams need enforcement at each stage rather than a single checkpoint.
• The practical implication is a move from review-based oversight to runtime containment, where agent actions can be allowed, flagged, or blocked before completion.

Key terms

• Runtime Authorisation: Runtime authorisation is the practice of deciding access while a task is in progress, rather than only at provisioning time. It matters for NHIs because credentials and entitlements can change risk mid-session, especially when automation or AI agents interact with sensitive systems.
• 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.
• Agent Workflow: An agent workflow is a machine-driven sequence where an AI system can call tools, access data, and continue execution with limited human involvement. These workflows need governance that sees API activity and tool use, not just browser sessions or user clicks.
• Continuous authorization: Continuous authorization is the practice of rechecking access as a session unfolds instead of trusting a single login decision. It matters for AI workflows because the request, context, retrieved data, and downstream action can all change between prompt and execution, making static approval too blunt.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.