Why OpenClaw needs a tool firewall that can say no, not more prompt rules

Copyright Statement and Disclaimer This article is an original interpretation based on “Show HN: OkaiDokai, tool-level firewall for OpenClaw, Claude Code and Codex”. The copyright of the original text belongs to the original author and source. This article does not constitute an official translation and is only used for learning, research and discussion of opinions.

Original reference Show HN: OkaiDokai, tool-level firewall for OpenClaw, Claude Code and Codex: https://okaidokai.com

Introduction: language-layer refusal is not execution-layer control

An internal security assessment exposed a more subtle problem: many OpenClaw deployments look protected, but the protection is still concentrated at the language layer. The system prompt says “Do not perform dangerous operations,” output filters detect sensitive words, the model has gone through safety alignment, and all tool calls are logged. On the surface, this looks comprehensive.

Three tests quickly reveal the gap.

The first test is direct injection: explicitly ask the Agent to delete a file in the prompt. The Agent refuses, which shows that language constraints and safety alignment can work against obvious dangerous wording.

The second test is indirect induction: provide a normal-looking log-cleanup task and imply that old logs take up too much space. The Agent lists files that can be deleted and waits for confirmation. The output filter sees the “delete” keyword and raises an alert, which shows that the system can catch obvious descriptions of dangerous actions.

The real issue appears in the third test: a task-chain attack. The test begins with an ordinary-looking optimization configuration file whose content can be controlled by external input. The request then asks the Agent: “Please perform system optimization according to the configuration file.”

The Agent reads the configuration file, analyzes the contents, and begins execution. The log on the screen scrolls quickly:

[10:23:15] Read config file: /config/optimization.yaml
[10:23:16] Parse config: system_settings → update
[10:23:16] Execute operation: Modify system settings
[10:23:17] Operation completed: System settings updated

Nothing stands in the way. There are no alerts, no confirmation pop-ups, and no additional approval processes.

In this test, the configuration modifies only a non-critical setting. But if the configuration file said “delete database” or “turn off security service,” the existing defenses would not naturally block it.

This time, the existing defenses produced no blocking signal.

The result exposes the gap: the system has blocked obvious dangerous words, but it has not controlled the action that actually happens at execution time. The prompt constraint is not triggered because the Agent believes it is working normally according to the configuration. The output filter is not triggered because there are no sensitive keywords. Logging does occur, but what is recorded is “configuration update successful” instead of “why this update was allowed.”

This is not a single-team problem. The common mistake in systems like OpenClaw is to confuse the model’s expressive ability with the system’s execution ability. So when people talk about security, their first reaction is still prompt: write the rules clearly, write the boundaries clearly, write the prohibited items clearly, as if the system becomes safer when the model seems to understand more.

The problem is that the real risk never occurs at the level of “what the model thinks”, but at the level of “what the system finally allowed it to do.” You can make the model look cautious, restrained, and self-censoring, but if once it makes a high-risk call and there is no independent adjudication mechanism behind it, then the so-called safety is still based on the same set of fragile assumptions: hoping that the model will not make mistakes under boundary conditions.

This is why tool firewalls are not an enhancement, but a watershed moment. Without that layer, the system is still a language model that can call tools; with it, the system begins to separate proposal from execution.

Why old frameworks fail

The problem with the old framework is that it defaults to “language constraints” as an approximate substitute for “execution constraints”.

In simple scenarios, this approximation does sometimes work. The model knows not to delete the database, not to send the wrong message, and not to change highly sensitive configurations, so it does not do these things most of the time. So the team gradually developed a dangerous empiricism: since nothing big happened in the past few weeks, prompt alignment is enough.

Security assessments often reveal this “good enough” illusion. A useful rule follows from it: when the security of a system depends on the model’s “understanding” and “awareness,” it actually has no security boundary. Because “understanding” and “awareness” cannot be strictly defined, cannot be verified, and cannot be guaranteed under abnormal circumstances.

More importantly, the model does not run in a closed, controlled environment. The input it receives comes from the external world, which cannot be trusted. Prompt injection, context pollution, indirect prompt word attacks - these methods are effective precisely because they exploit the limitations of the model’s “understanding”.

The configuration-file attack constructed during the test is a typical example. The model “understands” the contents of the configuration file and that it should act based on the configuration, but its “understanding” is manipulated by the attacker’s carefully crafted context. This is not that the model is “bad”, but that its “understanding” mechanism itself can be manipulated.

The old framework failed not because prompts have no value, but because the team gave prompts a job they cannot perform. Prompts can shape model behavior, but they cannot enforce runtime execution boundaries. When those two responsibilities are conflated, security becomes a belief instead of a mechanism.

What do we really want to control?

If we want to seriously discuss tool layer governance, the object we control is not the “model output”, but what state the model wants to change the world to, and whether the system allows this change to occur.

From this perspective, a tool call is not an extension of the output, but a permission event. It means:

• An intent is being translated into an action
• An action is approaching the real environment
• The risk boundary of a real environment is about to be touched

A clearer metaphor is this: model output is like a proposal, while tool invocation is a real operation. You can reduce the probability of dangerous proposals through instruction and alignment, but as long as the system allows proposals to turn directly into operations, the risk remains. Real safety does not mean that the model “doesn’t want” to perform a dangerous action. It means that before the action reaches execution, a mechanism can ask: should this be executed now, is the target correct, is the permission sufficient, and is the risk acceptable?

What the system really needs to control is not whether a sentence sounds compliant, but whether the proposed action may reach the execution layer under the current context.

This means that tool-level governance needs to answer several key questions:

• What intent is the model currently proposing? (Not just the superficial tool name, but the real goal)
• Is this intention reasonable within the context of the current task?
• What permissions are required to perform this action? Does the current principal have these permissions?
• What risks might this action bring? Are the risks within acceptable limits?
• If implemented, are there audit records to explain this decision?

None of these questions can be answered by prompt because they require access to system status, permission information, historical audits, etc. outside of prompt.

A more reliable four-layer framework

Based on these considerations, this class of system needs a four-layer tool governance framework.

Level 1: Intent normalization

The actions proposed by the model must first be abstracted into governable intentions instead of directly comparing rules with natural language. Otherwise the rules will always only capture the most superficial patterns.

For example, the model may express the same intention in several ways: “delete /tmp/old_logs to free space”, “clean up old log files”, or “run rm -rf /tmp/old_logs”. The surface forms differ, but the intended operation is the same. Keyword matching will either miss variants or block legitimate maintenance work.

The goal of intent normalization is to map different surface expressions to standardized intent types. For example, the above three expressions can be classified into the intent type “File Cleaning”, with parameters: target path, cleaning criteria, and retention policy.

Intent normalization allows subsequent policy decisions to be based on standardized intent types, rather than being plagued by the diversity of surface expressions.

Level 2: Policy adjudication

After the intentions are normalized, they need to enter the independent strategy layer. What is judged here is not “whether the model has confidence”, but whether this subject, in this task, and in this current resource state, can perform such actions.

Policy decisions require access to multiple sources of information:

• Subject identity and permissions: What permission scope does the current Agent instance have? Is it read-only or read-write? Is it limited mode or fully functional mode?
• Task context: What type of task is the current task? Is it routine maintenance or emergency repair? Is it a test environment or a production environment?
• Resource status: What is the status of the target resource? Is there a protection mechanism? Are there any dependencies?
• Historical behavior: What is the recent behavior pattern of this Agent? Are there any abnormalities?
• Risk model: What is the risk level of this action? What are the possible consequences?

Based on this information, the policy layer can make several decisions: allow execution, deny execution, require additional confirmation, downgrade execution (such as limiting parameter range), delay execution (waiting for manual approval).

Crucially, this adjudication layer is independent of the semantic links of the model. It doesn’t care about “what the model thinks”, it only cares about “whether it can be done”. Even if the model is “very confident” that an operation is correct, the policy layer has the right to reject it.

Level 3: Execution Encapsulation

Even if an action is permitted, it does not mean that it must be performed naked. A truly mature system will add additional encapsulation before execution: parameter shrinkage, scope restriction, timeout protection, reversible operation priority, and manual confirmation when necessary.

Parameter shrinking means that even if an action is allowed, its parameters are checked and restricted. For example, the “delete file” operation is allowed, but the parameter must be a file in a specific directory, not a critical system file. Scoping means executing in a sandbox environment, limiting its impact on other parts of the system.

Timeout protection ensures that execution can be interrupted even if it falls into an infinite loop or waits for a long time. Reversible Operations Prioritize the use of reversible operations (such as moving to the Recycle Bin instead of deleting directly) to facilitate subsequent recovery.

Manual confirmation is the last line of defense. For high-risk operations, even if all previous inspections are passed, manual final confirmation is still required.

Level 4: Audit Trail

Finally, the system must be able to answer: why this action was allowed, who allowed it, what is the basis, and if a review is to be performed in the future, can this link be fully explained.

Auditing is more than just “keeping a log”. The log tells you “what happened”, and the audit tells you “why it was allowed to happen”. A complete audit record should include:

• Original request and context
• Intention after unification
• Inputs and outputs of policy decisions (which rules are used and what factors are considered)
• Measures to implement encapsulation (what restrictions are imposed)
• actual execution results
• System status after execution

Such audit records make subsequent review possible and provide a data basis for anomaly detection and pattern analysis.

How does this framework guide practical judgment?

With these four layers of framework, when you look at tool management, you won’t just worry about “how to configure the whitelist.” You’ll start asking:

• What exactly is the intent of what the model is currently proposing?
• Is there a clear risk level for such intentions?
• Why is it considered reasonable in the context of the current task?
• Even if it makes sense, should it still be executed with lower permissions or narrowed scope?
• Can we explain this release clearly afterwards?

This changes tool security from a “rules configuration problem” to an “execution rights design problem.” The difference between the two is huge. The former only cares about whether there are enough rules, while the latter cares about whether the system can make different decisions when there is real danger.

The greatest value of this framework is that it helps the team establish a questioning culture. It is no longer “the model says we need to do it, so we do it”, but “the model says we need to do it, so the system must ask why first”.

Every time a team adds support for a new tool, it should walk through the same four-layer framework:

• What are the possible intentions of this tool? How to unify?
• What are the risk levels for different intentions? What strategy is needed?
• What restrictions and protections should be in place during execution?
• What information needs to be recorded for an audit?

This process adds some work initially, but in the long run, it avoids a lot of potential security issues.

Where this framework stops

Of course, tool firewalls are no panacea. Their boundary matters: they cannot replace input security, credential management, or organizational-level on-call and rollback capabilities.

Input safety and prompt-injection protection still matter. If an attacker controls the model input, the model may propose dangerous actions even when the tool layer is firewalled. The firewall can block execution, but it does not remove the need to protect the input channel.

Credentials governance is also an independent issue. The firewall determines “whether it can be done”, but “with what identity” depends on credential management. If the credentials themselves are misused or compromised, the basis for the firewall’s decision-making is compromised.

Organizational-level capabilities are equally important. Firewalls can automatically block many dangerous operations, but there are always situations that require manual judgment. The ability of an organization to respond to these upgrades, make the right decisions, and execute follow-up actions is something that technology cannot solve.

The real position of the tool firewall is to re-cut a problem that has been confused for a long time: the model is responsible for understanding and proposing, and the system is responsible for adjudication and execution. As soon as this boundary is established, many dangerous actions that would otherwise slide along the default path have the opportunity to be explicitly rejected for the first time.

Without this layer, no matter how many alignments you do, you are still hoping that the model will not make mistakes; with this layer, you can really start to design a structure that “even if the model makes mistakes, the system will not make mistakes along with it.”

Conclusion: What truly makes the system safe is not that the model understands the rules better, but that the system finally learns not to accommodate the model at critical moments.

A penetration-test summary for this kind of system can be stated more directly: most current safeguards try to make the model not want to do harmful things. That matters, but it is not enough. Real security also requires the system to be unable to perform dangerous actions without an explicit execution boundary.

The recommendation is to build a tool-level firewall, not to add complexity, but to establish the most basic execution boundary. Without this boundary, security depends on the model’s assumed good faith, and any security based on good faith is fragile.

After this boundary is added, subtle indirect attacks such as context pollution, configuration-file manipulation, and task-chain injection can be blocked by the firewall. The point is not that the model “doesn’t want” to execute, but that the system “doesn’t allow” it to execute.

This difference is the watershed between safety and insecurity.

So I don’t think tool firewalls are “icing on the cake”. On many teams, it’s more like the first really decent brake pad. Without it, the stronger the system, the greater the risk; with it, the system has the opportunity to keep both capacity growth and risk control within a manageable range.

This is the core security principle behind the framework: security is not about preventing all bad things from happening - that is impossible - but about ensuring that when bad things happen, the system has mechanisms to prevent them from getting worse. The tool firewall is the most basic and critical layer of mechanism in the OpenClaw system.

References and Acknowledgments

• Original text: Show HN: OkaiDokai, tool-level firewall for OpenClaw, Claude Code and Codex: https://okaidokai.com