# OpenAPPA: deterministic information-flow guardrails for AI agents, built in Rust

> OpenAPPA intercepts every AI agent tool call and checks whether the data involved is allowed to travel to that destination, using policy written in TOML. The engine is deterministic and stateless per call, but the project is at preview status and config surfaces may break without migration shims.

**archestra-ai/OpenAPPA** — Deterministic guardrails that don't break agents

- Repository: https://github.com/archestra-ai/OpenAPPA
- Website: https://openappa.com
- Stars: 1,601 · Forks: 68
- Language: Rust
- License: MIT
- Published: 2026-10-09 · Updated: 2026-10-09 · Language: en
- Canonical page: https://hysenlabs.com/projects/archestra-ai-openappa

## APPA evaluates the event log before every tool call with no network or file reads

OpenAPPA sits between an agent and its tools and answers one question before each call: is this data allowed to go to this destination? APPA's engine tracks the sensitivity and trust of everything an agent reads, then checks each planned tool call against those labels before the call executes.

What distinguishes this from classifier-based guardrails is determinism. Classifiers and PII detectors are probabilistic, and the same input can produce different decisions on different runs. APPA's engine makes no network calls and no file reads at decision time, so the same event log always produces the same answer. Replaying a trace gives the same sequence of permit and deny decisions every time, which makes debugging and auditing straightforward.

Policy is written in declarative TOML rather than in code. At startup, the engine reads the policy file and evaluates incoming tool call events against it from that point forward. Both in-process and sidecar deployment modes are available: in-process runs the engine inside the agent, while sidecar runs it as a separate process the agent consults before each tool call. Running in sidecar mode lets multiple agents share one running runtime rather than each embedding their own copy. APPA's formal algebra is described in a paper accepted to the NeurIPS 2026 Workshop on Agents in the Wild (arXiv: 2607.24625).

## appa describe and appa replay test policy decisions before the agent runs a single tool

Two CLI commands let you check policy decisions without starting the agent's actual tools. First, verify that the configuration file loads:

```sh
appa describe --config appa.toml --check
```

Second, replay scripted tool calls against expected decisions:

```sh
appa replay --config appa.toml policy-tests/
```

Both commands are designed to run in CI as required checks that block merges when validation fails. A GitHub Actions workflow and a worked example are documented at openappa.com/validation.

At the repository root, examples/ holds both live-replays/ and tests/ subdirectories. Policy tests capture the expected outcome of specific data flows, so a TOML change that introduces a regression on a documented flow will fail replay before the pull request merges. Maintaining a policy-tests/ directory from the start has lower cost than investigating a live agent that started permitting or denying the wrong flows after a policy update. Without those tests, a policy change that accidentally opens a new data path may not surface until the agent is running in production.

## One curl command installs the Claude Code integration; other agents embed the runtime

Claude Code is the fastest path for watching a policy decision on real work. Installing and activating that integration takes one shell command:

```sh
curl -fsSL https://openappa.com/install.sh | sh &&
  ~/.local/bin/appa plugin install claude-code
```

After installation, a protected session starts with:

```sh
clappa
```

Running `/appa-guide` inside that session triggers the policy setup skill. According to the README, this integration is a playground for the model, not the product itself.

For other agents, 2 paths are available. Embedding the APPA runtime directly works from any language using appa-runtime. Alternatively, connecting an agent through hooks avoids a direct dependency. Archestra's 1.4 Release Candidate takes a third path: implementing OpenAPPA at the LLM proxy level for Claude Code, Claude Desktop, Cursor, Codex, OpenCode, Copilot CLI and n8n.

A Docker demo for the chat-playground service runs on port 8787. Its Dockerfile uses rust:1.96-bookworm as the builder stage and passes the OpenRouter API key at run time rather than baking it into the image.

## Preview status: config and wire surfaces may break without migration shims

OpenAPPA is marked as a preview and an RFC. Its own status badge reads Preview & RFC. Config and wire surfaces may break between versions without migration shims, which the project states explicitly rather than burying in a release note.

According to the README, the algebra is settled enough to build against, and the project deliberately invites argument on the design. That RFC framing means major shifts can happen based on feedback through the issue tracker or Discord, and a policy configuration that works on v0.31.1 may not survive a release that incorporates a significant RFC change.

Three releases shipped in rapid succession around 2026-10-02: v0.30.0 on 2026-09-30, v0.31.0 on 2026-10-02 at 20:28 UTC, and v0.31.1 on 2026-10-02 at 21:28 UTC. A push to the repository followed on 2026-10-06. That cadence reflects active early development rather than a stable maintenance cycle, which reinforces the preview label.

## Bench-Corp and AgentThreatBench: 0% attack success at 89% task completion across 1,320 evaluations

OpenAPPA's own benchmark results cover 2 suites. Bench-Corp consists of 20 multi-step enterprise workflows. AgentThreatBench covers the OWASP Top 10 for Agentic Applications, with both standard and adversarial prompts.

Across 1,320 evaluations, no scored attack succeeded against OpenAPPA, while task completion was 88-90%. Comparing against the same suites, Claude Code auto mode allowed 10% of attacks through at 90% task completion, and Microsoft FIDES allowed 31% of attacks through at 41% task completion, according to the README's table.

Published by the project itself, not by a third party, these numbers reflect what the project chose to measure and how it defined success on each axis. Reading the arXiv paper (2607.24625) provides the formal description of the attack and task models. Full results are at openappa.com/evaluation, and the README notes that evaluation numbers are updated on that page. Understanding what a scored attack means in this benchmark context is the prerequisite for interpreting the 0% figure. AgentThreatBench covers prompt injection, tool misuse and data exfiltration scenarios drawn from the OWASP Top 10 for agentic systems, which gives the benchmark coverage beyond simple jailbreak prompts.

## Twelve Rust crates in one workspace, with appa-engine as the hot path

Cargo.toml lists 12 workspace crates: appa-example-agent, appa-agent-python, appa-builtin, appa-engine, appa-package, appa-eventlog, appa-policy, appa-adapter-amp, appa-adapter-claude-code, appa-adapter-kagent, appa-runtime-api and appa-runtime, plus website-chat-playground and bench/corp-agent.

Build profile comments in Cargo.toml explain the optimization choices. Optimized for binary size rather than arithmetic throughput, the default release profile uses opt-level "s" with thin LTO and 16 codegen units, since most of the binary waits on a socket. Two crates are pinned at opt-level 3: appa-engine, because it replays the whole trajectory before every decision and sha2-digests every value it admits, and sha2 itself. Pinning those 2 at level 3 cuts the replay by about a fifth, according to the Cargo.toml comments.

Built with unwind panics rather than abort, appa-builtin needs to contain a panic at its extern C boundary. That choice signals that the runtime is designed to load untrusted policy modules without crashing the host process. Rust edition 2024 is used throughout, and publish = false means no crate ships to crates.io.

## MIT licence, an arXiv paper, and an RFC that stays open to argument

Licensed MIT, OpenAPPA keeps its source terms consistent: the badge in the README, LICENSE.md at the repository root and the Cargo.toml workspace package section all agree. CONTRIBUTORS.md tracks contributions separately, and brand assets are at openappa.com/branding.

Formal treatment of the algebra appears in APPA: Recoverable Information-Flow Control for Real-World LLM Agents, accepted to the NeurIPS 2026 Workshop on Agents in the Wild (arXiv: 2607.24625). The word recoverable in the title points to recovery guarantees that the README references. Reading the paper gives the mathematical model behind the TOML policy, which matters before writing a policy for production data flows.

Not archived, and with the last push on 2026-10-06, OpenAPPA is active. CHANGELOG.md at the repository root tracks version history. Given the rapid release cadence and the explicit preview label, CHANGELOG.md is the first file to read before any upgrade. Upgrading from v0.30.0 to v0.31.1 within 3 days of release is an example of the pace: treat each version bump as potentially introducing a breaking change until the project exits preview.

## Conclusion

OpenAPPA suits teams that need a deterministic check before an AI agent calls any tool and are willing to define that check in TOML. Its benchmark result of 0% attack success is the project's own claim, and the project is at preview status: config and wire surfaces may break without shims. Before adopting it, confirm your agent has an adapter in the workspace (Claude Code, kagent and AMP are present; Cursor and Copilot CLI are covered through Archestra). Run appa describe --config appa.toml --check to validate policy, and appa replay against scripted tests before each merge.

## FAQ

### What is OpenAPPA?

OpenAPPA is an information-flow control engine for AI agents that checks whether data is allowed to travel to a specific tool before each tool call executes. Policy is written in declarative TOML, and the engine decides from the event log alone without network or file calls, returning the same decision for the same log every time.

### Is OpenAPPA ready for production use?

The README marks it as a preview and an RFC, stating that config and wire surfaces may break without migration shims. The formal algebra is accepted to the NeurIPS 2026 Workshop on Agents in the Wild, but the project is deliberately open to change based on feedback.

### Which agent frameworks does OpenAPPA support?

The workspace includes adapters for Claude Code (appa-adapter-claude-code), kagent (appa-adapter-kagent) and AMP (appa-adapter-amp). Archestra's 1.4 Release Candidate extends coverage to Claude Desktop, Cursor, Codex, OpenCode, Copilot CLI and n8n at the LLM proxy level.

### How do I test OpenAPPA policies without running the agent?

The appa CLI provides appa describe --config appa.toml --check to verify the policy file loads, and appa replay --config appa.toml policy-tests/ to check scripted tool calls against expected decisions. Both can run as required CI checks to block merges when validation fails.

### What benchmark results does OpenAPPA report?

The README reports 0% attack success and 88-90% task completion across 1,320 evaluations on Bench-Corp and AgentThreatBench. These are the project's own results; full numbers and methodology are at openappa.com/evaluation.

## Sources

- [archestra-ai/OpenAPPA on GitHub](https://github.com/archestra-ai/OpenAPPA)
- [License: MIT](https://github.com/archestra-ai/OpenAPPA/blob/main/LICENSE)
- [Project website](https://openappa.com)
- [README](https://github.com/archestra-ai/OpenAPPA/blob/main/README.md)
- [Releases](https://github.com/archestra-ai/OpenAPPA/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/archestra-ai-openappa