SecureClaw: Clawing Back Control of LLM Agents

arXiv:2606.09549 · cs.CR, cs.AI · Submitted 2026-06-08 · Read on arXiv

Listen

Transcript

Introduction to the show: ident: Security Radio. Generated commentary on the latest security and cryptography papers.

Nadia: Today's paper: "SecureClaw: Clawing Back Control of LLM Agents".

Elias: The gist SecureClaw presents a dual-boundary architecture that places authorization at the effect sink and plaintext confinement at the read boundary to secure tool-using LLM agents against unauthorized external actions…

Nadia: First, who's behind it and why it matters.

Paper summary: Nadia: So we're looking at this paper called "SecureClaw: Clawing Back Control of LLM Agents". It tackles two different security problems that happen when you use large language model agents. The big issue is that you get unauthorized actions from the agent, and also sensitive plaintext gets exposed inside the system before any final check can stop it.

Elias: Exactly. Existing defenses usually only protect one side of the problem, either they protect the planner or they protect where external actions happen, but neither of those alone secures both surfaces <ref:2606.09549#pg2>. This paper introduces a dual-boundary architecture that puts authorization at the effect sink and plaintext confinement at the read boundary.

Priya: So what's this about? Are we talking about stopping the agent from doing things it shouldn't do, or keeping secrets from leaking out internally? Because those feel like two very different kinds of failures <ref:2606.09549#pg2>.

Nadia: It’s both at once. The core idea is that the untrusted agent runtime should control neither when external effects happen nor where raw protected values reside <ref:2606.09549#pg2>. They want to separate planning from security enforcement so the runtime can reason about symbolic references but not have control over authorization or confidentiality <ref:2606.09549#pg3>.

Elias: The architecture sets up five logical roles, which is the untrusted runtime R, a trusted gateway G, a trusted handle store S, a trusted policy engine P, and a trusted executor X <ref:2606.09549#pg3>. It’s about separating the planning from the actual security enforcement mechanisms.

Priya: That sounds like they are trying to build two separate walls for different kinds of threats. One wall for actions, one wall for data leakage, right?

Nadia: Right. The effect surface handles whether the exact request reaching an external sink was authorized for the caller and context <ref:2606.09549#pg2>. They use a PREVIEW→COMMIT protocol where only a trusted executor can commit the exact canonical request authorized by policy <ref:2606.09549#pg3>.

Elias: That write path involves a PREVIEW→COMMIT protocol where only a trusted executor may commit the exact canonical request authorized by policy <ref:2606.09549#pg3>. But the runtime can still plan over summaries and symbolic references, but it cannot directly resolve those IDs into secrets or perform side effects <ref:2606.09549#pg3>.

Priya: So the writing part is very strict—only a trusted executor gets to commit what's authorized—but what about when the agent needs to read something? That’s where I imagine things get tricky with data.

Nadia: That’s where the plaintext surface comes in, which addresses whether the untrusted runtime ever receives raw secrets that it can relay through user-visible outputs or memory <ref:2606.09549#pg2>. They protect this by putting a trusted gateway on the read path that replaces raw values with an opaque handle <ref:2606.09549#pg3>.

Elias: This handle is defined as a high-entropy symbolic reference associated with caller, session, time-to-live, object version, and the set of sinks at which dereference is allowed <ref:2606.09549#pg5>. The runtime can’t resolve this handle into plaintext directly <ref:2606.09549#pg3>.

Paper summary: Priya: So instead of getting the actual secret, the agent gets this symbolic handle, and maybe a summary if it needs to plan something else <ref:2606.09549#pg3>? That sounds like a way to keep the sensitive data confined away from where the untrusted agent runs <ref:2606.09549#pg3>.

Nadia: Exactly. The handle layer prevents raw plaintext from re-entering those runtime channels because inter-agent messages and memory carry symbolic references rather than newly dereferenced secrets <ref:2606.09549#pg3>. They also include a bounded summary when necessary for planning, which they call declassification <ref:2606.09549#pg3>.

Elias: And on the write path, every effectful request has to pass through Protocol one where the runtime proposes inputs, and then the trusted gateway appends authenticated caller, session, and context to form rho <ref:2606.09549#pg5>. That canonicalized request gets hashed into a binding digest using HMAC-SHA256 with a key bind <ref:2606.09549#pg5>.

Priya: So the runtime is only sending symbolic inputs that get verified against an authorization artifact from the policy engine before anything happens externally <ref:2606.09549#pg3>? That sounds like a very strict check on every single action.

Nadia: It is very strict. The executor verifies this digest against an authorization artifact obtained from the policy engine <ref:2606.09549#pg5>. This mechanism handles the effect surface, ensuring only authorized requests commit to external sinks <ref:2606.09549#pg3>.

Elias: The research evaluated this SecureClaw system across AgentDojo, AgentLeak, and the Agent Security Bench or ASB using a common harness <ref:2606.09549#pg1>. The results show it’s the only defense they tested in that setup that achieves zero attack success rate on ASB <ref:2606.09549#pg1>.

Priya: What does that mean for the real world? If it can achieve zero success on ASB, is this something we can actually trust when we deploy these agents in high-stakes environments?

Nadia: It means it’s only one defense they tested that simultaneously maintains usable task utility while achieving zero attack success rate on ASB <ref:2606.09549#pg1>. They also got a zero point six four percent ASR on AgentDojo and a three point two three percent overall leak on AgentLeak’s attacked parity lane, which measures final-output and internal-relay leakage <ref:2606.09549#pg1>.

Elias: The ablation studies show the two controls are complementary; removing the handles leaves C2 and C5 at zero leakage because the confidentiality gain comes from handle confinement, not from write boundary masking it <ref:2606.09549#pg7>.

Priya: So if you remove the handles, you lose that protection against internal relay leakage but still have the effect surface protection intact? That sounds like a trade-off they are showing.

Nadia: It is a trade-off. Removing handles while keeping the boundary leaves C2 and C5 at zero because the confidentiality gain comes from handle confinement, not from the write boundary accidentally masking it <ref:2606.09549#pg7>. The residual failures they found are concentrated on authorized-yet-misaligned behavior inside the policy-allowed region <ref:2606.09549#pg8>.

Elias: Those residual failures show what remains once both surfaces are controlled; the dominant one is authorized-yet-misaligned behavior inside the policy-allowed region <ref:2606.09549#pg8>. On AgentLeak, they found fifteen cases remain on C1 final-output cases and one on C2, but no C5 relay reappears <ref:2606.09549#pg16>.

Paper summary: Priya: So even with this dual boundary architecture, there are still some failures where the agent does something it’s allowed to do but it’s not what we wanted? That feels like a real-world problem for auditing.

Nadia: It is a real-world problem. The authors conclude that the residual remains concentrated on the final authorized-output plane rather than on reopened internal relay <ref:2606.09549#pg16>. They suggest that securing LLM agents requires separating control of external effects from access to sensitive plaintext <ref:2606.09549#pg7>.

Elias: The paper formalizes this through theorems, like Theorem one formalizing request-bound authorization integrity for the commit path <ref:2606.09549#pg2>, and Theorem three quantifying exposure limited to one bounded summary per authorized read <ref:2606.09549#pg2>.

Priya: So what does this mean for someone who just listens to the show? It means we need both a strong check on what the agent *does* and a way to keep its secrets locked away when it reads data, even if those two things don't perfectly cover every single failure mode.

Nadia: The architecture shows that these two pillars protect different failure modes, and neither subsumes the other <ref:2606.09549#pg8>. High-assurance deployments should pair this with hardening, audit logging, key isolation, and independent monitoring of the gateway, handle store, policy service, and executor <ref:2606.09549#pg26>.

Elias: The overhead is practical for deployment; executor-side verification is sub-millisecond and single-service authorization adds about fifteen milliseconds <ref:2606.09549#pg8>. But the research concludes that SecureClaw trusts the gateway, policy engine, and executor <ref:2606.09549#pg7>.

Priya: So to wrap up, this paper gives us a practical dual-boundary architecture for securing LLM agents by separating control of external effects from access to sensitive plaintext <ref:2606.09549#pg7>. It’s about having a strict boundary for writes and a different mechanism for reads <ref:2606.09549#pg3>.

Nadia: Right. SecureClaw is the only defense they tested in that common harness that simultaneously achieves zero attack success rate on ASB and reduces AgentLeak’s attacked parity lane leakage to three point two three percent <ref:2606.09549#pg1>. It demonstrates how these complementary controls address both external effects and internal leakage <ref:2606.09549#pg10>.

Elias: The paper’s main contribution is presenting a practical dual-boundary architecture that mediates sensitive reads with opaque handles and effectful writes with a PREVIEW→COMMIT executor <ref:2606.09549#pg2>. It's built on the claim that the untrusted agent runtime should control neither when external effects happen nor where raw protected values reside <ref:2606.09549#pg3>.

Priya: The implication is that for building robust agent systems, we need to explicitly separate how we control external actions from how we manage access to sensitive data <ref:2606.09549#pg7>. It’s a framework for understanding those two non-substitutable security requirements <ref:2606.09549#pg7>.

Nadia: The authors suggest that SecureClaw should be deployed with explicit sink inventories, schema audits, and conservative confirmation policies for irreversible actions <ref:2606.09549#pg26>. It’s a practical architecture that aims to reduce unsafe agentic effects and plaintext exposure in high-stakes workflows without making the untrusted runtime a trusted security monitor <ref:2606.09549#pg26>.

Conclusion: Nadia: So we're wrapping up with the conclusion of this paper on SecureClaw, and it really boils down to taking two separate security problems—unauthorized external actions and raw data leakage—and building a dual-boundary system to handle them separately.

Elias: Yeah, the title itself, "SecureClaw," just suggests they’re clawing back control over those two distinct failure modes <ref:2606.09549#pg1>. They’ve got this architecture where the runtime doesn't get to decide when external stuff happens or where sensitive data lives.

Priya: So, what does that actually mean for us? It means we're not relying on just one defense mechanism anymore, which is pretty significant <ref:2606.09549#pg7>. We've got this effect surface protection and this plaintext surface protection working together.

Nadia: Exactly. The authors show that they can actually keep the agent useful while getting zero attack success rate on the ASB benchmark, which is a solid result <ref:2606.09549#pg1>. They also managed to reduce that AgentLeak leakage down to three point two three percent on a specific test lane <ref:2606.09549#pg1>.

Elias: The authors really focus on the separation of concerns, proving that you can control authorization integrity for the commit path and handle-only raw plaintext confinement as separate things <ref:2606.09549#pg21>. That's a lot of formal proof work behind it.

Priya: I like how they show the ablation studies, where removing just the handles still leaves those two surfaces at zero leakage because the gain actually comes from confining that handle layer <ref:2606.09549#pg7>. That tells us exactly what's providing that safety <ref:2606.09549#pg7>.

Nadia: And while they show strong results, the residual failures are still there, concentrated on authorized-yet-misaligned behavior inside the policy-allowed region <ref:2606.09549#pg8>. That’s where we need to keep an eye <ref:2606.09549#pg8>.

Elias: The authors conclude that this separation—the effect boundary and the plaintext boundary—is what secures LLM agents, and it’s a practical architecture <ref:2606.09549#pg7>. It’s not a magic fix, but it's a framework for building robust systems.

Nadia: So the big picture is that securing these agentic workflows means designing systems where you explicitly separate control over external actions from access to sensitive plaintext <ref:2606.09549#pg7>. It’s about having strict boundaries for what the agent can do and how it can read data, even if those two things don't cover every single failure mode.

Elias: And that leads us next to how we actually put this into practice, looking at the deployment and the necessary safeguards required for these kinds of systems <ref:2606.09549#pg26>.

TU Berlin

cs.CR, cs.AI

Submitted: 2026-06-08

Updated: 2026-10-15

Comments: Accepted at NeurIPS 2026 (poster). Revised presentation and additional evaluation; 29 pages including appendices

Code: https://github.com/ponyyuhan/SecureClaw

License: http://creativecommons.org/licenses/by/4.0/

Importance score: 92/100

The gist: The gist SecureClaw presents a dual-boundary architecture that places authorization at the effect sink and plaintext confinement at the read boundary to secure tool-using LLM agents against

Key concepts

Effect Surface: This boundary secures whether an external request reaching a tool sink was authorized for the caller, session, inputs, and context. It prevents unauthorized actions by requiring a trusted executor to commit requests only after verifying policy authorization via a PREVIEW->COMMIT protocol.
Plaintext Surface: This boundary protects raw secrets from being relayed through user-visible outputs or memory. It is secured by a trusted gateway that replaces sensitive values with opaque handles, preventing the untrusted runtime from ever seeing or directly resolving these secrets.
Opaque Handle: A handle is a high-entropy symbolic reference used to store plaintext securely. The runtime receives this handle instead of the raw secret, meaning it cannot resolve the handle into plaintext directly. This confinement prevents raw data from re-entering untrusted channels.
PREVIEW->COMMIT Protocol: This protocol governs writes that change external state. It requires the runtime to propose an intent, which is then authenticated and hashed by a trusted gateway. Only a trusted executor can commit this canonical request if it matches the authorization artifact from the policy engine.

Terminology

Agent Security Bench — 1× in this paper
Attack Success Rate (ASR) — 1× in this paper · explained in 3 episodes
Large Language Model (LLM) — 1× in this paper · explained in 3 episodes

Summary

The gist SecureClaw presents a dual-boundary architecture that places authorization at the effect sink and plaintext confinement at the read boundary to secure tool-using LLM agents against unauthorized external actions and runtime plaintext exposure.

How it works

SecureClaw is built around a simple systems claim: the untrusted agent runtime should control neither when external effects happen nor where raw protected values reside (Page 2). This architecture separates planning from security enforcement, allowing the runtime to reason over symbolic references while being untrusted for both authorization and confidentiality (Page 3). The system consists of five logical roles: an untrusted runtime R, a trusted gateway G, a trusted handle store S, a trusted policy engine P, and a trusted executor X (Page 3).

The architecture enforces two distinct security surfaces: the effect surface and the plaintext surface. The effect surface addresses whether the exact request that reaches an external sink was authorized for the current caller, session, inputs, and context (Page 2). This is protected by the PREVIEW→COMMIT protocol in which only a trusted executor may commit the exact canonical request authorized by policy (Page 2). The write path involves a PREVIEW→COMMIT protocol where only a trusted executor may commit the exact canonical request authorized by policy (Page 3).

The plaintext surface addresses whether the untrusted runtime ever receives raw secrets that it can relay through user-visible outputs, inter-agent messages, memory, logs, or later tool calls (Page 2). This is protected by a trusted gateway on the read path which returns an opaque handle and provides a bounded summary when necessary for planning (Page 3). The handle layer prevents raw plaintext from re-entering the runtime channels because inter-agent messages and memory carry symbolic references rather than newly dereferenced secrets (Page 3).

Key Mechanisms

The architecture utilizes specific mechanisms to enforce these boundaries. On the read path, the gateway stores the plaintext in a protected handle table and returns an opaque handle to the runtime (Page 5). A handle is defined as a high-entropy symbolic reference associated with caller, session, time-to-live, object version, and the set of sinks at which dereference is allowed (Page 5). The runtime cannot resolve this handle into plaintext directly (Page 3).

On the write path, every effectful request must pass through Protocol 1: The runtime proposes (intent, inputs); the trusted gateway appends authenticated caller, session, and ctx to form ρ (Page 5). This canonicalized request is then hashed to create a binding digest h ← HMAC-SHA256(kbind, Canon(ρ)) (Page 5). The executor verifies this digest against an authorization artifact obtained from the policy engine (Page 5).

Evaluation and Results

SecureClaw was evaluated across AgentDojo, AgentLeak, and ASB using a common harness (Page 1). Across these benchmarks, SecureClaw is the only defense we evaluate in a common-harness that simultaneously retains usable task utility and achieves 0% attack success rate (ASR) on ASB (Page 1). Specifically, it achieved 0.64% ASR on AgentDojo, and 3.23% overall leak on AgentLeak’s attacked parity lane (Page 1).

The ablation studies demonstrate the complementary nature of the two controls:

-Boundary Handles C2 Leak C5 Leak Full 0.0% 0.0% (Page 7).

-Handles × 20.8% 8.3% (Page 14).

Removing handles while keeping the boundary leaves C2 and C5 at zero because the confidentiality gain comes from handle confinement, not from the write boundary accidentally masking it (Page 4).

Residual Failures

The residual failures show what remains once both target surfaces are controlled. The dominant residual is authorized-yet-misaligned behavior inside the policy-allowed region (Page 8). On AgentLeak, fifteen cases remain on C1 final-output cases and one on C2; no C5 relay reappears (Page 16). The paper concludes that the residual remains concentrated on the final authorized-output plane rather than on reopened internal relay (Page 16).

The architecture shows that the two pillars protect different failure modes, and neither subsumes the other (Page 8). High-assurance deployments should pair this architecture with hardening, audit logging, key isolation, and independent monitoring of the gateway, handle store, policy service, and executor (Page 26).

The system's overhead is practical: Executor-side verification is sub-millisecond; single-service authorization adds about 15 ms (Page 8). The research concludes that SecureClaw trusts the gateway, policy engine, and executor (Page 7).

The paper formalizes its guarantees through Theorems that quantify request-bound authorization integrity and handle-only raw-plaintext confinement (Page 19). Theorem 1 formalizes request-bound authorization integrity for the commit path (Page 20). Theorem 2 formalizes handle-only raw-plaintext confinement as a reference case (Page 21). The deployed read interface is quantified by Theorem 3, which shows that exposure is limited to one bounded summary per authorized read (Page 23). The final proposition states that under the stated assumptions, no unauthorized side effect can commit; the internal relay channels C2 and C5 do not newly expose raw protected values beyond what was already released through the authorized bounded-summary interface (Page 24).

The paper's findings are supported by empirical evidence showing that SecureClaw is the only same-harness configuration that jointly drives unauthorized commits to zero/near-zero on the effect benchmarks and reduces AgentLeak’s attacked parity-lane leakage to 3.23% (Page 7). The architecture effectively addresses both external effects and internal leakage through complementary controls (Page 10).

The paper's conclusion is that securing LLM agents requires separating control of external effects from access to sensitive plaintext (Page 7). This separation is achieved by the executor-side PREVIEW→COMMIT boundary and the gateway-side opaque-handle layer (Page 7). The system remains usable because safe continuation raises matched-sample ASB utility from 70% to 86% without increasing ASR (Page 8). SecureClaw reduces unsafe agentic effects and plaintext exposure in high-stakes workflows without requiring the untrusted runtime to become a trusted security monitor (Page 26). The paper's main contribution is presenting a practical dual-boundary architecture that mediates sensitive reads with opaque handles and effectful writes with a PREVIEW→COMMIT executor (Page 2). The architectural design is based on the claim that the untrusted agent runtime should control neither when external effects happen nor where raw protected values reside (Page 2).

The paper's scope includes analyzing the failure modes of different components, noting that Gateway G Read confidentiality fails because the gateway can disclose plaintext directly (Page 26). The final recommendation is that SecureClaw should be deployed with explicit sink inventories, schema audits, and conservative confirmation policies for irreversible actions (Page 26). The paper's work is supported by research in areas like information flow control and capability systems (Page 5).

The paper's reliance on the bounded-summary interface is justified by the fact that the deployed benchmark configuration uses a bounded-summary interface (Page 23). This interface quantifies exposure, showing that a high-∆ summary category weakens the per-read confidentiality term of Theorem 3, but it does not reopen unauthorized commit or a fresh raw-plaintext relay from trusted storage into C2/C5 (Page 24). The overall utility gain from deny-aware recovery is significant: it raises utility by 16.0 points on ASB and 26.7 points on the matched AgentLeak-style subset, with no ASR cost in either case (Page 8). SecureClaw's success is demonstrated across multiple benchmarks using a common harness (Page 1). The paper's work provides a framework for understanding the 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 (Page 2). SecureClaw is the only defense evaluated that simultaneously achieves 0% ASR on ASB, 0.64% ASR on AgentDojo, and 3.23% overall leak on AgentLeak’s attacked parity lane (Page 1). The paper's work establishes a concrete empirical pattern: sink-side enforcement should stop unauthorized commits without closing internal relay channels, while read-side confinement should close relay channels without authorizing commits (Page 2). SecureClaw is built on the simple claim that securing LLM agents requires separating control of external effects from access to sensitive plaintext (Page 7). The paper's work provides a decomposition of security into effect and plaintext surfaces, which is crucial for designing robust agent systems (Page 3). SecureClaw’s residual failures are concentrated on policy-allowed misalignment and user-visible declassification pressure, not bypasses of the core invariants (Page 8). The paper's work provides a formal contract for the architecture, isolating assumptions needed for each guarantee (Page 25). The paper's work is supported by research in areas like information flow control and capability systems (Page 5).

Improvements for AI systems

The AI system can be architected with SecureClaw to achieve request-bound authorization integrity by placing authorization at the effect sink and using a trusted executor on the write path, ensuring the executor is the sole component that can commit an exact canonical request authorized by policy. This prevents unauthorized external actions even if the runtime attempts to mutate inputs after preview.
The system can confine sensitive data from the untrusted runtime by implementing a trusted gateway on the read path that returns an opaque handle, thereby ensuring that the runtime may route the handle through later computation, memory, or tool calls, but it cannot resolve the handle into plaintext. This prevents internal leakage paths like inter-agent messages (C2) and shared memory (C5) from exposing raw secrets.
The system can maintain usability after a denial by implementing deny-aware recovery which returns a structured denial drawn from a fixed template family with only a coarse action class, a reason code, and safe nextstep hints that do not reveal dereferenced protected content. This ensures the workflow continues safely without relaxing the commit invariant.
The system can be enhanced by using explicit bounded declassification via a summary interface where the runtime receives an opaque handle plus a bounded summary computed by a fixed schema-aware operator with explicit item and character caps, treating this as an explicit declassification interface rather than an incidental copy of the original value. This allows the runtime to reason over summaries while restricting access to raw data.
The system's security posture can be verified across multiple benchmarks, as SecureClaw is noted as "the only defense we evaluate in a common harness that simultaneously retains usable task utility and achieves 0% attack success rate on ASB, 0.64% ASR on AgentDojo, and 3.23% overall leak on AgentLeak’s attacked parity lane."

Abstract

Tool-using large language model (LLM) agents face two distinct security failures: unauthorized external actions and exposure of sensitive plaintext inside the runtime before any final output check can intervene. Existing defenses usually protect one boundary, either the planner/runtime or the point where external actions are executed, and therefore do not by themselves secure both surfaces. We present SecureClaw, a dual-boundary architecture that enforces authorization in a trusted executor and keeps raw protected data outside the LLM runtime. Sensitive reads pass through a trusted gateway that replaces raw values with reference IDs. In the evaluated deployment, the gateway also provides short planning summaries that deliberately release selected information, a process called declassification. Writes that change external state follow a PREVIEW to COMMIT protocol in which only a trusted executor may execute the exact request authorized by policy. The runtime can still plan over summaries and reference IDs, but cannot directly resolve the IDs into secrets or perform side effects. Across the AgentDojo, AgentLeak, and Agent Security Bench (ASB) benchmarks, SecureClaw is the only defense we evaluate in a common harness that simultaneously retains usable task utility and achieves 0% attack success rate (ASR) on ASB, 0.64% ASR on AgentDojo, and 3.23% overall leak on AgentLeak's attacked parity lane, which measures final-output and internal-relay leakage. Code is available at https://github.com/ponyyuhan/SecureClaw.