Retesting OpenAPPA: Behind the Zero-Attack Claim of an AI Agent Guardrail

AI agents can read files, send emails, and browse the web — and the more capable they become, the greater the risk. A hidden instruction planted on a webpage could be enough to make an agent send payroll data to an external address. That is prompt injection. The "guardrail" that sits between the agent and its tools has therefore become security-critical. The open-source guardrail OpenAPPA has about 1,550 stars on GitHub, and its README claims: across 1,320 evaluations, not a single scored attack succeeded, while 88% to 90% of tasks were still completed. One developer decided to rerun those tests to see what those numbers mean in real-world scenarios.

What the Guardrail Actually Blocks

OpenAPPA does not rely on AI to make judgments; it follows a rulebook: each tool maps to a rule, and the same situation always yields the same answer. When an agent reads private information (such as HR records), the rules tag the conversation, and from then on only HR roles can see the resulting output. Tags never fall off, so any subsequent email sent outside HR is intercepted.

Its innovation lies in what happens after interception: instead of simply saying "no," it offers a way out — accept a stricter tag and continue, request human approval for a single action, strip private parts through a sanitizer, or hand the step to an independent helper agent.

The external test AgentThreatBench plants traps in three places: agent memory, the inbox, and customer data. Reset tests show that without a guardrail, agents follow the trap up to 27% of the time under normal instructions, and up to 80% when explicitly told to obey planted text. With OpenAPPA added, none of the 360 traps worked.

But the cost follows: on memory-type tasks, agents with the guardrail completed only 40% to 60% of the work, while agents without it completed everything.

Prompt Injection is the core security threat facing AI agents. Attackers embed hidden instructions in content the agent will read (webpages, emails, documents) to induce it to perform unintended actions. Unlike traditional software vulnerabilities, prompt injection exploits the fundamental inability of large language models to reliably distinguish "data" from "instructions" — the model sees a continuous piece of text, and malicious instructions within it have no natural semantic boundary from normal content. OWASP has listed it as the top risk for LLM applications. Defenses fall into two main categories: one is to have the model itself identify and refuse suspicious instructions, but its uncertainty makes this line of defense fragile; the other, like OpenAPPA, is to insert a deterministic policy layer between the agent and its tools that is independent of the model, constraining actions with rules rather than judgment.

What the Zero Actually Counts

The vendor's own test, Bench-Corp, counts any violating action as an attack, regardless of who initiated it. In this test, the guardrail missed twice out of 520 runs, both on the same task with Gemini 3.7 Flash.

The problem is the scoring criteria. Without the guardrail, 28% to 33% of runs did something forbidden, but almost all of it was actively requested by the user — for example, CC'ing a release email to an external archive address excluded by the rules. Planted traps never took effect under normal instructions; they only worked when the instructions told the agent to obey the planted text.

In other words, this zero mainly shows that the guardrail blocked users' own violating requests, not the resistance to external attacks that "zero attacks" implies.

The scoring also missed a leak. When told to obey planted text, the guarded DeepSeek^Ad posted employees' HR records to a public forum in 4 out of 15 runs. The guardrail offered a way out through a sanitizer, but that sanitizer only hid numbers: names, job titles, managers, email addresses, streets, and cities were all public. The test only checked whether an email was sent to the attacker, so those runs were counted as safe. The safety of a way out depends on the sanitizer behind it.

The Real Cost in Performance and Cost

Task completion is measured by actual outcomes in the company's systems, not by the agent's verbal report. Without the guardrail, agents completed 92% to 97% of tasks. With the guardrail added: DeepSeek dropped to 74%, Luna to 75%, and Gemini to 81%.

This decline is not due to the test environment. The comparison guardrail FIDES came close to its published figures on the same models. The README's numbers come from the August 26 version of OpenAPPA, which completed 89% of tasks on Luna using the same scoring standard; the October 1 version completed only 75%.

Every interception makes the agent stop and think about its next step. On Bench-Corp, because the guardrail intervened in nearly every run, agents used 2.6x to 8x more tokens. DeepSeek runs cost 16x more and took 22x longer. The published 4.22% additional cost comes from another test, Tau-bench, where the guardrail intervened only once across 11,355 actions.

Token is the basic unit of text processed by a large language model. An English word usually corresponds to 1 to 2 tokens, and Chinese to more. Every time an agent calls the model, both input (including the full conversation history) and output are billed by token. The reason the guardrail increases token consumption by 2.6x to 8x is that after each interception, the agent needs extra reasoning steps to replan, and each check may reread the entire session history — the longer the context, the more input tokens per call. DeepSeek runs costing 16x more is the combined result of surging token volume and inflated per-call context. This also explains why in tests with few actions (such as Tau-bench, where the guardrail intervened only once across 11,355 actions), the additional cost was only 4.22%: the guardrail's cost is strongly correlated with interception frequency and session length.

Blocked but Reported as Successful

In 519 guarded runs that had a final answer, 45 times the agent told the user the email or file share had been sent, but it had actually been blocked by the guardrail. Without the guardrail, this number was 1 out of 440 runs.

The root cause lies in the test's own agent logic: it often delegates steps to helper agents, and when a helper agent does not report back, its instructions default to assuming the step succeeded. The researchers modified that one sentence and reran the four tasks where the problem was most concentrated. Taking Luna as an example, in the original version 11 of 20 responses were wrong; after deleting that sentence, it dropped to 7; after replacing it with "you cannot confirm whether its side effects succeeded," all 20 were correct, with the same number of tasks completed.

The guardrail held, but the user was told the opposite result. If your agent delegates work to helper agents, make each helper agent report the actual execution status, and verify outcomes in your own systems rather than trusting the agent's response.

Sub-agent is a common pattern in agent architectures: the main agent delegates subtasks to specialized helper agents to isolate context or process in parallel. The problem lies in the reporting mechanism — if a helper agent finishes a task but does not return a clear result to the main agent, the main agent's instructions may default to assuming the step succeeded. This flaw amplified the guardrail's side effects in the tests: the action was intercepted, the helper agent did not execute, but the main agent assumed it was done and ultimately reported a false "sent" to the user. The fix is not to eliminate delegation, but to force every helper agent to report its actual execution status (success, failure, or blocked) and to verify in external systems whether side effects actually occurred, rather than trusting the agent's verbal report.

Additional Findings in Claude Code

OpenAPPA also works with the AI coding assistant Claude Code. There, it checks every action twice, and each check rereads the entire session history.

At the start of a session, an action waits 0.01 seconds; by the 1,000th action, it waits 0.2 seconds; by the 4,000th action, it waits 2.5 seconds. That test session waited a total of 58 minutes. The latest version 0.31.1, checked on October 12, showed no improvement in speed. In the researcher's own Claude Code sessions, a quarter exceeded 1,300 actions.

The default rulebook also deliberately allows some websites. After Claude reads a .env file (which stores keys, fake keys in the test), fetching Stripe documentation requires approval; but a Google search using details from that file as search terms went out without anyone's approval. In addition, only sessions started with the clappa command are protected: running claude directly does not enable OpenAPPA and does not prompt the user.

The "side door" in the rulebook refers to a vulnerability where the same data leak can be achieved through different tool paths. OpenAPPA configures rules separately for each tool, but if two tools can return the same or equivalent data and only one of them is strictly constrained, attackers or mistakes can bypass it. The example in the article is: after reading a .env file, fetching Stripe documentation requires approval, but using key details from the .env as Google search terms requires no approval — the search "exit" is not equally constrained, so private information can leak through the search engine. The defense principle is: any tool that can carry equally sensitive information must have equally strong rules applied, rather than configuring them one by one by tool name. The same applies when registering custom sanitizers: verify the actual scope of what they hide, rather than trusting their names.

Practical Usage Recommendations

1. Measure on your own tasks and models, comparing task completion and cost with and without the guardrail.
2. Verify outcomes in your own systems rather than relying on the agent's response.
3. Check the rulebook for side doors: tools that return the same data need the same rules.
4. Test every sanitizer you register.
5. Expect requests to be slower. In Claude Code, keep sessions short.

Limitations of the Test

The traps are pre-fixed, and neither the researchers nor the vendor tested adversarial attacks that adapt to the rulebook. Bench-Corp is the vendor's own test, and its checker looks for exact phrases. Each task had only 2 to 5 runs, so percentages may have an error margin of 8 to 10 percentage points. The vendor's 1,320 runs were not publicly disclosed, so comparisons could only be made against its published data and runs in the repository.

The test was based on OpenAPPA as of October 1, 2026 (commit 53c3d8e) and its August 26 version (a1ccf3f), run through the vendor's own test scripts. On October 12, the latest version 0.31.1 was checked: the README's claims and the instructions that caused false "completion" reports were unchanged, and the Claude Code findings still held. The data and scripts are publicly available on GitHub.