🤖 AI

SecureClaw: Clawing Back Control of LLM Agents

SecureClaw is a dual-boundary security architecture for tool-using LLM agents that prevents unauthorized external actions and sensitive data exposure by enforcing a trusted gateway for read operations and a PREVIEW-to-COMMIT protocol for write operations, achieving near-zero attack success rates across multiple benchmarks while maintaining task utility.

Original authors: Yuhan Ma, Stefan Schmid

Published 2026-06-09

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Yuhan Ma, Stefan Schmid

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you hire a very smart, but untrustworthy, personal assistant (the LLM Agent) to handle your sensitive tasks, like paying bills, reading private emails, or managing your calendar.

The problem is that this assistant is a bit of a loose cannon. If you give them a document with your bank account number, they might accidentally (or maliciously) read it out loud to a stranger, or they might get tricked by a hidden note inside an email into sending your money to a scammer.

Current security guards usually try to stop the assistant from doing the bad thing (like sending the money), but they often fail to stop the assistant from seeing the secret in the first place. Once the assistant sees the secret, they can whisper it to other programs or write it down in their notes before the guard even gets a chance to stop them.

SecureClaw is a new security system designed to fix both problems at once. It treats the "seeing" and the "doing" as two separate jobs that need two different locks.

Here is how it works, using a simple analogy:

The Two Locks of SecureClaw

1. The "Blindfold" for Reading (The Gateway)

Imagine your assistant needs to look at a secret invoice to know how much to pay.

Old Way: You hand the assistant the actual paper invoice. They can read the numbers, copy them down, or even read them out loud to a hacker listening in.
SecureClaw Way: You don't give them the paper. Instead, you give them a mystery box (an "opaque handle") and a tiny, sanitized note (a "bounded summary").
- The note says: "Invoice from Vendor A, $4,200, due Friday."
- The mystery box is a code that only the secure vault knows how to open.
- The assistant can plan their work using the note and the code, but they cannot open the box to see the real invoice details. They can't copy the real numbers because they never saw them.

2. The "Double-Check" for Doing (The Executor)

Now, imagine the assistant wants to send an email to pay that invoice.

Old Way: The assistant writes the email and hits "Send." If a hacker tricked the assistant into changing the email address to a scammer, the money goes to the scammer.
SecureClaw Way: The assistant can only propose the email. They write a draft and say, "I want to send this."
- A Trusted Guard (the Executor) picks up the draft.
- The Guard checks: "Did you ask to send this? Is the recipient correct? Is the amount right?"
- Crucially, the Guard checks the exact details against a sealed, unchangeable receipt of what was originally approved.
- If the assistant tried to sneakily change the email address to a scammer after getting approval, the Guard sees the mismatch and blocks the email. Only the Guard has the power to actually hit "Send."

Why This is a Big Deal

The paper tested this system against three different "hacking playgrounds" (AgentDojo, AgentLeak, and ASB) where attackers tried to trick agents into stealing data or sending money to the wrong people.

The Result: SecureClaw was the only system that successfully stopped 100% of the unauthorized money transfers (0% attack success) and reduced secret data leaks to almost zero.
The Secret Sauce: The paper proves that you can't just use one lock.
- If you only have the "Double-Check" (stopping the send), the assistant can still read the secret and leak it through their internal notes.
- If you only have the "Blindfold" (hiding the secret), the assistant might still be tricked into sending a message to the wrong person if they don't have the secret to begin with.
- SecureClaw uses both. It keeps the secrets hidden from the assistant and ensures the assistant can't force an action without a final, trusted check.

What Happens When It Says "No"?

Sometimes, the system blocks a request because it looks suspicious. In the past, this might have just stopped the whole workflow, frustrating the user. SecureClaw has a "Safe Recovery" feature.

If the Guard blocks a request, instead of just saying "Error," it gives the assistant a safe, pre-approved path to try again.

Example: "I can't send that email to the stranger. But I can draft a message for you to review first."
This keeps the work moving without lowering the security standards.

The Bottom Line

SecureClaw is like hiring a bodyguard who wears a blindfold when reading your diary (so they don't memorize your secrets) and who holds the keys to your car (so they can't drive you to a dangerous place without checking the map first). It separates the ability to plan from the ability to act, ensuring that even if the assistant is tricked, the damage is contained.

Technical Summary: SecureClaw

Problem Statement

Tool-using Large Language Model (LLM) agents face two distinct and non-interchangeable security failure modes that existing defenses often fail to address simultaneously:

Unauthorized External Effects: The risk that an agent, potentially compromised by prompt injection or adversarial runtime behavior, executes actions (e.g., sending emails, transferring funds) that were not authorized for the specific context, session, or caller.
Runtime Plaintext Exposure: The risk that sensitive data (e.g., invoices, medical records) is exposed to the untrusted LLM runtime in plaintext. Even if a subsequent action is blocked, the runtime may have already "read" the secret and can relay it through internal channels (inter-agent messages, shared memory, logs) that output-only auditing mechanisms miss.

Current defenses typically protect only one boundary: either the planner/runtime (via prompt filtering) or the action sink (via argument checking). The paper argues that protecting the sink does not prevent internal leakage if the runtime has already accessed raw secrets, and protecting the runtime does not prevent unauthorized commits if the sink is unmediated.

Methodology: SecureClaw Architecture

SecureClaw introduces a dual-boundary architecture that separates control of external effects from access to sensitive plaintext. It relies on a trusted infrastructure (Gateway, Handle Store, Policy Engine, Executor) distinct from the untrusted agent runtime.

1. Read Path: Opaque Handle Confinement

Mechanism: When the runtime requests sensitive data, a Trusted Gateway intercepts the read. Instead of returning raw plaintext, the gateway stores the data in a Trusted Handle Store and returns an opaque handle (a high-entropy symbolic reference) to the runtime.
Declassification: If the agent requires task-relevant information to plan, the gateway provides a bounded summary (e.g., "invoice from Vendor A, $4.2k"). This summary is treated as an explicit declassification interface, not a plaintext leak.
Constraint: The runtime can route and store handles but cannot dereference them to recover raw secrets. Internal channels (C2, C5) carry symbolic references, not secrets.

2. Write Path: PREVIEW→COMMIT Protocol

Mechanism: The runtime proposes an effectful action (intent + inputs). A Trusted Gateway appends authenticated context (caller, session, sink fields) and canonicalizes the request into a binding digest ( $h$ ).
Authorization: A Policy Engine authorizes the exact canonical request and returns an authorization artifact bound to $h$ .
Execution: A Trusted Executor is the sole component capable of reaching the external sink. Before committing, it:
1. Recomputes the binding digest $h$ .
2. Verifies the authorization artifact.
3. Checks freshness, replay status, and handle resolution.
4. Commits only if the request matches the authorized canonical form exactly.
Integrity: Any mutation of the request (e.g., changing a recipient) after preview alters the canonical form, invalidating the authorization artifact and causing the executor to fail-closed.

3. Deny-Aware Recovery

To maintain utility when actions are blocked, the system employs a deny-aware recovery mechanism. Instead of terminating the workflow, the system returns a structured denial with a coarse reason and a safe next-step hint (e.g., "draft for confirmation" instead of "send"), preserving workflow continuity without relaxing security invariants.

Key Contributions

Security Decomposition: The paper identifies two non-substitutable security requirements for tool-using agents: request-bound authorization of external effects and confinement of sensitive plaintext away from the untrusted runtime.
Dual-Boundary Architecture: SecureClaw implements these requirements via a trusted gateway (for read confinement) and a trusted executor (for write authorization), utilizing opaque handles and explicit declassification.
Common-Harness Evaluation: The authors evaluate SecureClaw against four baselines (Plain, IPIGuard, DRIFT, Faramesh) across three benchmarks (AgentDojo, AgentLeak, ASB) using a matched harness to ensure fair comparison.

Experimental Results

Evaluated on gpt-4o-mini with temperature 0:

Agent Security Bench (ASB): SecureClaw achieved 0% Attack Success Rate (ASR), significantly outperforming baselines (e.g., DRIFT at 87.75% ASR). It maintained 88.90% utility on benign tasks.
AgentDojo: Achieved 0.64% ASR (4/629 attacks), compared to 2.38% for the next best baseline (DRIFT).
AgentLeak: Achieved 3.23% overall leak on the attacked parity lane. Crucially, it reduced internal relay leaks (C2 and C5) to near zero (0.20% and 0.00% respectively), whereas baselines like Faramesh (which lacks read confinement) showed high internal leakage (92.74% on C2).
Ablation Studies: Removing the handle mechanism caused C2/C5 leakage to reappear, while removing the execution boundary did not affect internal leakage but failed to stop unauthorized commits. This confirms the two mechanisms protect distinct surfaces.
Robustness: In a bypass suite of 29 adversarial scenarios (tampering with artifacts, replay, session mixing), SecureClaw denied all 25 attack attempts while allowing 4 legitimate controls.
Overhead: Executor verification is sub-millisecond; single-service authorization adds ~15ms. These costs are negligible compared to LLM inference latencies (500–2000ms).

Significance and Claims

The paper claims that securing LLM agents requires structural separation rather than runtime-local defenses.

Non-Substitutability: The evaluation demonstrates that sink-side authorization and read-side confinement are complementary; neither can substitute for the other. A blocked commit cannot undo a secret already relayed through memory, and a handle cannot prevent a compromised runtime from attempting unauthorized actions.
Trust Model: SecureClaw shifts trust from the untrusted runtime to a minimal set of trusted components (Gateway, Handle Store, Policy Engine, Executor). It does not claim to guarantee semantic correctness of policy-allowed actions (e.g., if a policy is too coarse, the agent might still act on the wrong object), nor does it survive the compromise of its trusted components.
Residuals: The remaining failures are concentrated on the declassification plane (authorized summaries revealing information) or policy misalignment (authorized actions that are semantically wrong for the user's intent), rather than bypasses of the core security invariants.

The authors conclude that SecureClaw is the only evaluated system in their study that simultaneously drives unauthorized external effects to zero/near-zero and eliminates internal plaintext relay, while retaining high task utility through deny-aware recovery.