Cybersecurity WATCH CLOSELY OPPORTUNITY

OpenAPPA: an open-source gate that stops AI agents leaking sensitive data

ShiniFrontiers · Source: Archestra

Section 1 of 6 FREE PREVIEW

What problem does it solve?

Build or run AI agents that touch sensitive data? OpenAPPA is a free, open-source check that blocks an agent from sending the wrong data to the wrong place — and in the makers' tests it stopped every attack while still finishing the work.

What it is: A free, open-source tool (MIT licence) from Archestra that sits between an AI agent — a program that uses a large language model to take actions through outside tools — and those tools, and answers one question before each action: is this data allowed to go to this destination? The rules live in a plain config file, and the check is deterministic — the same situation always produces the same decision, unlike the probabilistic classifiers and PII detectors teams use today, which can vary run to run.

Who it's for: Teams building or running AI agents that handle private data — customer records, source code, internal documents — especially where one agent can both read sensitive data and reach external services.

The catch: It is a preview and a request-for-comments, not a finished product; the makers say its config and interfaces may change without compatibility shims. The headline numbers are the makers' own benchmarks, not an independent test.

A deterministic gate between your agent and its tools — for teams building or running AI agents on private data

Problem: An AI agent — a program that uses a large language model to plan and act — does its work through tool calls: it invokes outside tools to read a file, send an email, post to a repository. The danger is that one agent can both read something private and reach an outside service, so a mistake or a planted instruction can send the wrong data to the wrong place. The usual guards — content classifiers and PII detectors — guess from the wording and can answer differently from one run to the next.

What it does: OpenAPPA puts a check in front of every tool call and asks one question: is this data allowed to go to this destination? It tracks where each piece of data came from and how sensitive it is, and blocks a call that would send sensitive data somewhere unapproved. The check is deterministic — decided from the record of what the agent has done, with no network or file calls — so the same situation always gives the same answer, and you can test it before you ship. Think of a mailroom that checks the classification stamp on every envelope against where it is addressed before letting it leave the building.

Note: It governs where data flows, not whether content is harmful — keep your content-safety tools for that.

See the difference

The situation	Today (a typical agent)	With OpenAPPA
Asked to summarise a private meeting recording and post it to a public GitHub repo	Posts it — private content leaks to a public place	Blocks the post and explains why: private data may not go to a public destination
A hidden instruction in a web page tells the agent to email a customer list outside (a prompt-injection attack)	May obey and send the data	Blocked — the customer list was never allowed to reach an external email tool
Normal multi-step work across approved internal tools	Works, but you can't prove it won't also leak	Completes (88-90% of tasks in tests), and every allow/block decision is logged
You change the policy and want to be sure real work still passes	You find out when the agent breaks in production	appa replay checks scripted tool calls against expected decisions before you merge

Figures and scenarios from the makers' README and benchmarks: 0 of 1,320 attack attempts succeeded; 88-90% of tasks completed. The GitHub-repo scenario is the makers' own demo.

What it saves: A deterministic block on sensitive data reaching the wrong tool — so one injected instruction or one over-eager agent can't quietly send private data out. In the makers' tests, 0 of 1,320 attack attempts got through, while 88-90% of real tasks still finished.
What it costs: Free and MIT-licensed; engineering time to write the policy and wire the gate in (in-process or as a sidecar beside the agent); it is preview software whose interfaces may change.
How ready: Proven in the lab

Installable and benchmarked now, but labelled a preview and RFC — the makers warn config and interfaces may break, and the numbers are their own.

Join free to unlock: how it works, a step-by-step setup with its costs, what you gain, and where it falls short, for every Friday idea.

Join free to read it all →

Section 2 of 6 MEMBERS

How does it work?

Join free to read this section

OpenAPPA — how it fits together.

Join free to unlock: how it works, a step-by-step setup with its costs, what you gain, and where it falls short, for every Friday idea.

See the problem

What the agent tries to do	What the gate checks	Decision
Post text that came from a private file to a public repo	The text's source is private; the destination is public	Blocked
Send a reply through the approved customer-email tool	Customer data heading to its approved destination	Allowed
Email a customer list to an outside address (from a hidden instruction it read)	Customer data heading to an unapproved external tool	Blocked

Everything the agent reads — a file, a web page, an email — is tagged with how sensitive it is and how much it can be trusted. Before each tool call runs, OpenAPPA checks that tag against the destination. Because the decision comes only from that record, with no network or file lookups, it is deterministic: the same situation always gives the same answer, so you can test it before you ship.

Where OpenAPPA sits in your agent

Three layers: what the agent reads, the gate, and the tools it can act through.

What the agent reads. Data sources: files, emails, web pages and databases the agent reads — each carries a sensitivity and a trust level. Know what is sensitive before the agent acts, not after it has already sent it.

The gate. OpenAPPA (the APPA engine): checks each tool call against the policy and the record of what the agent has read, then allows or blocks it. A deterministic block: 0 of 1,320 attack attempts got through in the makers' tests.

The tools and destinations. Approved tools: the CRM, the internal store, the ticketing system the agent is allowed to use. Sensitive data reaches an outside destination only when the policy permits it.

Because the decision is deterministic, you can replay it in a test and get the same answer every time — so a policy can be checked in CI before it ships, which a probabilistic filter cannot promise.

Why not just use a content filter?

Teams already screen agent output with content classifiers and PII detectors. Those read the words and guess whether something looks sensitive. OpenAPPA decides instead from where the data came from and where it is going.

	A content filter / PII detector	OpenAPPA
How it decides	Guesses from the content whether it looks sensitive	Tracks where each piece of data came from and whether the destination is allowed
Same answer every time?	No — probabilistic, can vary run to run	Yes — deterministic from the record, so it can be tested before shipping
Catches a hidden instruction?	Only if the wording looks suspicious	Yes — the data's origin and destination decide, not the wording

A tool call through the gate: technical view

	OpenAPPA	Claude Code auto mode	Microsoft FIDES
Tasks completed	89%	90%	41%
Attacks that succeeded	0%	10%	31%

Join free → I have an account

Section 3 of 6 MEMBERS

How to set it up, and what it costs

Join free to read this section

OpenAPPA — steps and cost.

Join free to unlock: how it works, a step-by-step setup with its costs, what you gain, and where it falls short, for every Friday idea.

Is this for you?

	OpenAPPA
Good fit if	You build or run AI agents that read private data and can also reach outside services
	You need to prove an agent cannot leak data, not just hope it won't
	You want a safety check you can test in CI before shipping
Who acts on it	The engineer who owns the agent, with security sign-off on the policy
Not yet if	Your agents touch no sensitive data, or run fully offline
	You need settled, stable software today — this is a preview and RFC

Try it in a few minutes (Claude Code)

The makers call the Claude Code integration a playground, not the product — the fastest way to watch a policy make a real decision on real work.

Install the APPA command-line tool and the Claude Code plugin (an engineer) For example: on your own laptop, to try it before wiring it into anything real.
Start a protected session and open the setup guide (the engineer) For example: `clappa` starts Claude Code inside the gate; the guide helps you write a first policy. Expect: Claude Code now runs inside the gate, and the guide walks you through a first policy.
Watch it block a real unsafe action (the engineer) For example: ask it to take content from a private note and post it to a public GitHub repo — the session refuses and explains why.

Put it in front of your own agent

Write the policy in a TOML file (the engineer, with security) TOML is a simple, readable config format. For example: mark customer data as sensitive and name the CRM as its only allowed destination.
Run the engine in-process, or as a sidecar beside your agent (the engineer) A sidecar is a small helper process that runs next to the agent and checks each tool call. For example: Archestra's release can apply OpenAPPA at the LLM-proxy level for Cursor, Codex, n8n and others without changing your agent.
Check the policy before you merge (the engineer) For example: make `appa replay` a required CI check, so a policy change that would block real work fails the build instead of breaking production. Expect: the config loads, and the scripted tool calls get the decisions you expect.

What it costs

Item	Cost
The tool	Free and open source (MIT licence)
Setting it up	Engineering time to write the policy and wire the gate in
Keeping it current	It is preview/RFC — config and interfaces may change, so expect some upkeep

Join free → I have an account

	What changes	What it means for you
A hard block on bad data flows	Sensitive data can't reach an unapproved tool, even via a hidden instruction	One injected prompt or over-eager agent can't quietly send private data out
Same decision every time	The check is deterministic, decided from the record alone	You can test the policy in CI and trust it behaves the same in production
Work still gets done	88-90% of tasks completed in the makers' tests	Safety that mostly stays out of the way of real work

Limit	Why it matters	What to do
Preview and RFC	The makers say config and interfaces may change without compatibility shims	Pilot it; don't bet production on a stable interface yet
The numbers are the makers' own	The 0% and 89% come from their benchmarks, not an independent test	Re-run the benchmarks on your own workflows before relying on them
A policy is only as good as it is written	The gate enforces the policy you give it; a gap in the policy is a gap in protection	Have security review the TOML, and use appa replay to catch mistakes
It controls data flow, not content	It decides where data may go, not whether the content itself is harmful	Keep your content-safety tools for what they do; this covers the data flow

OpenAPPA: an open-source gate that stops AI agents leaking sensitive data

What problem does it solve?

How does it work?

See the problem

Where OpenAPPA sits in your agent

Why not just use a content filter?

How to set it up, and what it costs

Is this for you?

Try it in a few minutes (Claude Code)

Put it in front of your own agent

What it costs

What do you gain?

What are the limits?

What to keep in mind

Sources