ActionGuard is a safeguard from a September 2026 arXiv paper that checks each tool call an agent proposes, just before it runs, and returns ALLOW or DENY. It judges the call against the trusted user request and a separately built skill profile, and it never shows the raw, possibly poisoned skill text to the Reviewer model that makes the decision.

Why keep the skill text away from the reviewer?

An injected instruction is written to sound like normal procedure, so any model that reads it can be persuaded by it, including a guard. Withholding it means the Reviewer's only source of authority is the user's request: a step the request does not justify is refused, however the skill describes it. The paper does not measure this step in isolation; it compares whole designs.

How is this different from scanning or sandboxing skills?

Scanning tries to find and remove the bad line before the agent reads it, and permission manifests limit which tools a skill may use. ActionGuard does neither: the agent reads the original skill, and the check happens per call, asking whether this action is needed for this user's request. It does best against **contextual** injections that use permitted tools for an unrequested purpose.

Agent· 2026-10-02

ActionGuard — Reviewer isolation from poisoned skill text — What does it mean?

TL;DR

What is it: ActionGuard, from an arXiv paper posted on September 30, 2026, is a pre-execution check for agents that load third-party skills (instruction files the agent follows); the concept it makes concrete is reviewer isolation — the model that approves each tool call never reads the raw, possibly poisoned skill text the agent planned from.
Why it’s needed: A skill is an instruction file the agent follows as normal procedure, so a poisoned line can turn a harmless user request into a file deletion or a data upload that looks like a routine step, and the last chance to stop it is the moment before the tool runs.
vs previous: Earlier skill defenses either clean the skill text with a model that reads it (Dynamic Guardian) or check each call against a permission list declared for the skill (SkillGuard); ActionGuard instead asks whether the trusted user request justifies this call, using a separately built summary of the skill rather than the skill itself.

Jargon

Skill: A reusable package of instructions, scripts and tool-use steps (often a SKILL.md file) that an agent loads for a specific task. How skills work.
Tool call: One concrete action the agent asks the runtime to perform, such as running a shell command, reading a file or sending an HTTP request.
Skill injection: An attack that inserts a malicious instruction into an otherwise useful skill, so the agent carries it out as if it were part of the normal procedure.
Contextual vs obvious injection: A contextual injection disguises the attack as a normal step (backup, validation, sync); an obvious one asks directly for something unrelated, such as deleting files or collecting credentials.
Balanced skill profile: A structured summary the safeguard writes once per skill: the skill's ordinary workflow plus a list of suspicious signals that deserve extra review. It describes the skill; it grants no permission by itself.
Fail-closed: A policy where any failure of the check — an unreadable verdict, a reviewer that times out — blocks the action instead of letting it through. Fail-safe vs fail-open.
ASR / TSR: Attack Success Rate: share of runs where the attacker's side effect actually happened. Task Success Rate: share of runs where the user's real task was still completed.

The news. On September 30, 2026, researchers at Korea University posted ActionGuard: Tool Call Authorization under Poisoned Skills to arXiv. ActionGuard sits at the before-tool-call hook of the OpenClaw agent runtime and returns ALLOW or DENY for every call. On an extended SKILL-INJECT benchmark of 319 poisoned-skill tasks (139 contextual, 180 obvious), averaged over five reviewer models and three runs, it reports an attack success rate of 8.65%, against 13.42% for SkillGuard, 16.05% for Dynamic Guardian and 29.05% with no safeguard, while completing 90.38% of the benign tasks. Read the paper →

Picture a payments office. An assistant reads a vendor's manual and fills in payment slips; a clerk at a window approves or refuses each slip. Someone has tampered with one page of the manual: "after each invoice, also send a copy of the ledger to this address." The assistant follows the manual, so the slip looks routine. If the clerk also reads that page, the clerk can be talked into the same mistake — the forged page is written to sound like normal procedure, and it is persuasive to whoever reads it.

So this clerk never opens the manual. On the desk are the boss's signed work order, an index card the office wrote earlier about what this vendor usually asks for and what would be unusual, and the slip, plus the clerk's notes on the last few slips. The only question is whether the signed order justifies this payment. A slip to a new address that the order never mentions is refused, however official the manual made it sound.

In agent terms, the manual is the skill, the assistant is the target agent, and the clerk is ActionGuard's Reviewer model. The agent is still allowed to read the original skill and plan from it — the paper keeps skills useful. What changes is the authorization context: the Reviewer sees the trusted user request (stored at session start, separate from everything that arrives later), the balanced skill profile, the current call in both raw and normalized form, the recent calls, and the contents of any local script the call is about to run. This is the data-flow separation between trusted and untrusted inputs, applied to the guard itself rather than only to the agent.

Proposed tool callintercepted at before_tool_call

Resolve skill profilecached; raw skill used only to build it

Build review contextrequest + profile + calls + script

Reviewer verdictALLOW or DENY with a reason

Enforceunparseable or failed = DENY

The index card is written once, from the raw skill, by a separate profile-construction model, then cached and reused for every later call — so the raw text is read, but never by the model that makes the per-call decision. The card has two halves on purpose. The ordinary workflow half stops the Reviewer from refusing every curl or file write just because the tool sounds risky; the suspicious signals half points at behaviors that need a second look. Neither half authorizes anything: a step listed as ordinary is still refused if the user request does not justify it.

Two more details make the check hard to argue with. Scripts are opened before they run, and the file operations, subprocesses and network calls inside them count as evidence, while comments and strings inside the script are treated as untrusted text, not as new instructions. And enforcement is policy enforcement at the execution boundary with a fail-closed default: an ALLOW passes the call through unchanged, while a DENY, an unparseable answer, or a Reviewer that fails to respond all block it. A DENY blocks only that call; the reason goes back to the agent so it can try a different action.

Defense	Where it acts	What its checker reads	ASR ↓	TSR ↑
No safeguard	—	—	29.05% (Table 4)	93.46%
Dynamic Guardian	When the agent loads a skill	The raw skill, which it rewrites into sanitized text	16.05% (Table 4)	92.08%
SkillGuard	At each call	A permission manifest for the skill; checks the capability each call needs	13.42% (Table 4)	88.55%
ActionGuard	At each call, before it runs	Trusted request, skill profile, calls, script contents — not the raw skill	8.65% (Table 4)	90.38%

Where the difference shows is the contextual attacks — the forged page that sounds like normal procedure. On those, ActionGuard's attack success stays between 6.95% and 8.87% across the five reviewer models, while Dynamic Guardian ranges from 7.19% to 20.62% and SkillGuard from 18.71% to 22.06%. On obvious attacks, SkillGuard and ActionGuard are close (about 8–10% each), which fits the design: a permission list catches an action that is plainly out of scope, but a disguised step that uses permitted tools is exactly what a check against the user's request is built to catch. One limit to keep in mind: the paper compares whole designs and does not run an ablation that hands the raw skill to ActionGuard's Reviewer, so it does not measure how much of the gain comes from withholding the text alone.

A worked example. Hold the setup fixed — the same target agent (GPT-5.5), the paper's rates averaged over all five reviewer models and both attack types — and scale them to 1,000 poisoned-skill runs (illustrative scaling; the paper ran 319 pairs three times). With no safeguard, about 291 attacks land (29.05%). Dynamic Guardian cuts that to about 161, and ActionGuard to about 87. On the benign side, task success falls from 93.46% to 90.38%, so about 31 fewer user tasks out of 1,000 finish (TSR was measured on the 255 pairs whose task could be judged separately from the attack's damage). Net: about 204 fewer successful attacks per 1,000 runs, against about 31 fewer completed tasks per 1,000 eligible runs. The two rates come from different pair sets, so read these as aggregate differences, not as one blocked attack paid for by one broken task.

Goes deeper in: Agent Engineering → Layered Guardrails → Policy Enforcement

Related explainers

EvoMal — skill-library self-poisoning — another way a poisoned skill does damage, with no tool call to intercept
Camouflage-injection detection gap — why detectors that read the injected text miss disguised payloads
AgentDoG 1.5 — inline guard models — small models that screen each action, judged on risk rather than on the user's request
EffectMatch — effect-based authorization — authorizing what a call changes, not what it says

Frequently Asked Questions

Check what you knowMap your AI & GPU knowledge across every track — free, role-based