Authority Crossing: How DAS-1 Breaks the OpenClaw Breach Class
Local is not a boundary. Approval, revocation, and receipts are.
Give the system a UI, a WebSocket, and a pile of tokens, then act surprised when it behaves like an attacker-controlled control plane. The attack surface is shaped like a convenience feature: remote access, auto-connect, connectors, tools, and “just make it work” defaults. If you run OpenClaw on a machine you care about, or attach it to accounts you cannot casually burn down, this is for you.
Thesis
DAS-1 does not prevent bugs. It prevents silent authority crossing and contains blast radius when bugs or tokens inevitably happen. “Silent” has an operational meaning: execute occurred without an approval artifact in the receipt chain.
This is testable. If you cannot pass D-OC-01, D-OC-02, and D-OC-03, you do not control the system.
DAS-1 repo (spec + overlays): https://github.com/forgedculture/das-1
The threshold: Propose vs execute
Everything that matters operationally is here.
Propose is a suggested action, produced by a model or automation logic, that includes origin, intent, and requested capability. Proposals are allowed to be wrong, manipulative, or adversarial. That is the point.
Execute is a real-world state change: exfiltration, external writes, shell execution, sending as a human principal, modifying tool policy, modifying secrets, installing extensions, changing auth, changing network exposure.
Authority crossing is when a proposal becomes execution without an approval artifact in the path. Influence does not equal authority. Output is not permission. If you anthropomorphize the model, you get liability fog. If you cannot maintain this boundary under adversarial input, you do not have governance. You have good luck and a postmortem template.
The breach class
OpenClaw is the case study. Substitute any agent gateway here.
This is one breach class with three common entry paths. Each path is different at the edges and identical at the center: untrusted input becomes execution authority.
Pattern 1: Topology trust collapse (remote becomes “local”)
Entry
Attacker reaches a surface you assumed was “local-only” because it sits behind a reverse proxy or a convenience tunnel.
Boundary failure
A topology signal (loopback, proxy headers, assumed local) is treated as authority instead of being treated as a hint. Reverse proxy deployments are repeat offenders because the proxy is on the same host and the gateway sees localhost unless provenance is handled correctly.
OpenClaw’s own security guidance is explicit about what this prevents: “This prevents authentication bypass where proxied connections would otherwise appear to come from localhost and receive automatic trust.” [1]
This configuration is not theoretical. Deployers have filed security concerns about Clawdbot control UI exposure via default config and common reverse proxies, including localhost trust bypass behavior. [4]
Exit
Attacker gets unauthenticated or weakly authenticated access to a control surface that can expose config, credentials, and tool policies. If your instance is internet-facing, this becomes “someone else is driving.”
Pattern 2: Token theft becomes master-key takeover
Entry
Attacker gets you to click a crafted link or land on a malicious page that causes the Control UI to connect to an attacker-controlled endpoint.
Boundary failure
A token is treated as unconditional authority without time bounds, scope bounds, or fast revocation semantics.
Exit
Attacker uses the token to connect to the victim’s local gateway, modify config (sandbox, tool policies), and invoke privileged actions, achieving 1-click RCE. The advisory also notes it can be exploitable even when the gateway listens on loopback only because the victim’s browser initiates the outbound connection. [2]
Pattern 3: Indirect prompt injection becomes persistence
Entry
Untrusted content arrives through a channel you connected for convenience: email, chat, webhook payloads, documents, tickets.
Boundary failure
Trusted intent and untrusted content share the same execution-adjacent context. Tool invocation policy does not distinguish between “operator instruction” and “attacker-supplied text embedded in something the system read.” The model sees one blended stream unless the wrapper enforces separation.
Exit
Persistence is created by changing configuration, adding an integration under attacker control, widening tool policy, or setting up recurring listeners. This is the OpenDoor class: durable state change induced via indirect prompt injection without a conventional software exploit. [3]
These are structural attractors, not isolated accidents. Normal deployment pressure (add a tool, connect a channel, skip a gate, expose the UI) converges toward this configuration unless you apply deliberate resistance. The loop is simple and ugly: tools increase authority, authority increases incentives to remove friction, friction removal creates silent crossings, and silent crossings create incidents.
Controls that break the kill chain
Below are five Authority Engineering Controls (AECs). This is not about being careful. It is about mechanical enforcement at the moment where authority would otherwise cross.
Risk tiers used here
R1: low-risk read or local formatting, no secrets, no state mutation
R2: read with limited sensitive exposure, constrained local actions
R3: high-risk actions, state mutation or sensitive access
R4: critical-risk actions, identity-bound actions, broad mutation, execution, or exfil potential
AEC: Approval boundary (R3/R4 approval gate)
What it does
Requires explicit approval before any action that can exfiltrate, mutate external state, execute shell, alter tool policy, alter auth, or impersonate a human principal.
Kill chain step it breaks
Pattern 1: blocks topology collapse from becoming admin execution.
Pattern 2: blocks token possession from becoming immediate takeover.
Pattern 3: blocks injection from turning into state change.
Pass condition
Attacker-controlled content can generate proposals, but every R3 and R4 proposal is blocked without an approval artifact, and the block is recorded in the receipt chain.
Price
Approvals add latency. That is the cost of control.
Operator failure mode: approval theater
Nothing magical stops rubber-stamping. You stop it the same way you stop change control theater anywhere else: approval artifacts must be scoped, time-bounded, attributable, and sampled against receipt outcomes on a drill cadence. For R4, treat rubber-stamping as a defect: two-person approval, out-of-band confirmation for novel targets, and spot-check approval artifacts against receipt outcomes during D-OC-02 and D-OC-03 runs. If you cannot detect rubber-stamps, you cannot claim the boundary exists.
Insider note
If the approver is compromised or malicious, you are in a different threat model. DAS-1 does not abolish insiders. It forces them to leave fingerprints.
AEC: Receipts (receipt chain for every proposed and executed action)
What it does
Binds origin, classification, requested capability, approval, execution outcome, and revocation state into a single audit object.
Kill chain contribution
Receipts reduce detection latency. Silent crossings persist because nobody knows they happened. Receipts turn “execute without approval artifact” into a machine-checkable invariant, which shifts detection from “someone noticed” to “the system flagged it.”
Pass condition
Every tool invocation has a receipt. Every receipt includes origin, risk tier, and approval reference (or explicit denied state). Every executed R3 and R4 receipt includes an approval artifact ID, or it is, by definition, a control failure.
Price
Without receipts, postmortems become narrative. Narrative is how liability evaporates.
Example receipt (redacted, realistic)
receipt_id: rcpt_2026-02-09T14:22:11Z_7f3c
origin: channel=email sender_hash=sha256:9b1d... message_id=msg_18c2...
session: agent=opsbot profile=default turn=184
proposed_action: tool=shell verb=exec
risk: R4
scope: sandbox=oci_runbook_fs net=deny secrets=deny
args_hash: sha256:4a6f... (args elided)
approval: denied reason=no R4 approval artifact
execution: blocked
revocation_state: not_applicable
AEC: Revocation semantics (revocation as an on-call capability)
What it does
Makes authority time-bounded and kill-switchable: tokens, sessions, tool grants, channel pairings, and connector credentials can be revoked quickly and verifiably.
Kill chain step it breaks
Pattern 2: turns token theft into a race the defender can actually win.
Pattern 3: breaks persistence by invalidating the compromised capability set.
Pass condition
You can revoke within minutes, and you can prove the revoke worked by demonstrating failed reuse of the old credential or session.
Price
If revoke is slow, compromise becomes persistence.
AEC: Provenance and topology (provenance preservation and topology hardening)
What it does
Preserves true client origin across proxies and rejects spoofable topology signals. “Local” becomes a derived claim backed by configured trust, not a vibe.
Kill chain step it breaks
Pattern 1: prevents remote traffic from being misattributed as localhost and receiving automatic trust.
Pass condition
Untrusted proxy headers fail closed. Trusted proxy configuration is explicit and tested. OpenClaw’s guidance about trusted proxies and localhost bypass is the anchor here. [1]
Price
Never grant implied trust to topology.
AEC: Scope and blast radius (capability scoping at the boundary)
What it does
Constrains what a compromised session or tool can reach: least-privilege connectors, isolated sandboxes, per-agent separation, minimal channel exposure.
Kill chain step it breaks
All patterns. This is containment, not prevention. When something slips, it limits what “slips” can touch.
Pass condition
Compromise of one channel or one token cannot reach unrelated tools, unrelated secrets, or broad filesystem and network access.
Price
Every connected integration becomes an attacker-owned lever if you let it.
Prevent vs contain
Overclaim is governance debt.
DAS-1 does not prevent vulnerabilities in OpenClaw, browsers, reverse proxies, or runtimes. It prevents silent authority crossing and it contains blast radius.
If a system can execute external state changes, the question is not “can it be hacked.”
The question is “what happens when it is hacked, and can we prove what crossed the boundary.”
The drills (proof, not promises)
Controls are theory until they survive drills. Each drill has a goal, a scenario, and pass and fail conditions. The invariant stays the same throughout: if any execution occurs without an approval artifact in the receipt chain, you have a control failure, not an incident narrative.
Drill D-OC-01: Reverse proxy localhost laundering (AECs: Provenance and topology, Approval boundary, Receipts)
Scenario
Deploy OpenClaw behind a reverse proxy with forwarding headers. Attempt to present remote traffic as local via header manipulation or misconfigured trusted proxy settings, consistent with the failure mode described in OpenClaw’s security guidance and raised by deployers in reverse-proxy Clawdbot setups. [1], [4]
Pass
Gateway does not treat the connection as local unless it comes from an explicitly trusted proxy and the forwarding headers are overwritten correctly. [1]
Any R3 or R4 proposal is blocked without approval and recorded in receipts.
Fail
Remote session is granted local trust.
Any tool executes without an approval artifact in the receipt chain.
Drill D-OC-02: Token exfiltration and takeover attempt (AECs: Revocation semantics, Approval boundary, Receipts, Scope and blast radius)
Scenario
Reproduce GHSA-g8p2-7wf7-98mq behavior: token is exposed through Control UI behavior and attacker attempts to use it to connect and mutate gateway config. [2]
Pass
Token possession cannot perform R3 or R4 actions without approval artifacts.
Revocation invalidates the token quickly, and reuse demonstrably fails.
Scope limits what the stolen token can touch, even before revocation completes.
Fail
Stolen token provides immediate config mutation or execution.
Revocation is slow, ambiguous, or untestable.
Any tool executes without an approval artifact in the receipt chain.
Drill D-OC-03: Indirect prompt injection from an untrusted channel (AECs: Approval boundary, Receipts, Scope and blast radius)
Scenario
Send an injection payload via an untrusted channel (email, webhook, chat) that attempts to induce persistent configuration change or add an attacker-controlled integration, consistent with the OpenDoor class. [3]
Pass
Injection can produce text and proposals, but any R3 or R4 proposal is blocked without approval and logged. Receipts preserve origin and show classification and denial. Tools are scoped so that even approved actions cannot roam.
Fail
Any tool executes based on untrusted content without an approval artifact. Receipt chain is missing origin, missing risk tier, or missing approval linkage.
Hard rule
No incident closes without receipts and a revocation drill pass. If you skip the drill, you ran theater, not operations.
Minimum viable implementation hint
If you need the shortest path, implement the R3/R4 approval boundary and the receipt chain first, then run D-OC-02. If D-OC-02 fails, nothing else you are doing matters yet.
Close
Tool calls are production changes. Authority requires approvals. Compromise requires revocation. Origin is a control, not a suggestion. Claims require receipts. Systems require drills. That is what it looks like when you choose control over theater.
Per ignem, veritas.
References
[1] OpenClaw Docs, “Security - OpenClaw Gateway,” https://docs.openclaw.ai/gateway/security (accessed Feb. 9, 2026)
[2] openclaw/openclaw, “GHSA-g8p2-7wf7-98mq: 1-Click RCE via Authentication Token Exfiltration From gatewayUrl,” GitHub Security Advisory, https://github.com/openclaw/openclaw/security/advisories/GHSA-g8p2-7wf7-98mq (accessed Feb. 9, 2026)
[3] Zenity Labs, “OpenClaw or OpenDoor? Indirect prompt injection makes OpenClaw vulnerable to backdoors and much more,”
https://labs.zenity.io/p/openclaw-or-opendoor-indirect-prompt-injection-makes-openclaw-vulnerable-to-backdoors-and-much-more
(accessed Feb. 9, 2026)
[4] openclaw/openclaw, “Security concerns: Clawdbot control UI can be exposed via default config + reverse proxies,” Issue #2245, GitHub, https://github.com/openclaw/openclaw/issues/2245 (accessed Feb. 9, 2026)
Heavy on the technical side of things - but this a great breakdown on how handle those security gaps.