Guardian Protocol Registry

MITRE ATLAS names the attacks on AI systems. Guardian Protocol is the open, executable layer for AI agents: runnable tests, working detections and measured results, each mapped to ATLAS, and an anonymized way to share what each organization sees, so one detection protects everyone. Built in the open by YC founders, headed for a neutral home.

Want to take part? Clone this and run ./guardian. It attacks your own machine through your own sensor so you can watch it work, then asks before it installs or sends anything. Ctrl-C at any point leaves having done neither.

git clone https://github.com/guardianprotocol-ai/registry
cd registry && ./guardian

If you know security tooling: Atomic Red Team and Sigma for AI agents, mapped to ATLAS. Atomic Red Team publishes runnable tests mapped to MITRE ATT&CK; Sigma publishes open detection rules mapped to it. Nobody had built either one for agents.

Why the sharing matters most

A catalogue of agent attacks is being built by several groups, and a public log already watches over 13,870 MCP servers from the outside. None of that can see inside one organization's deployment, which is where the attacks land.

In 2026 agents were used in real intrusions. Hugging Face disclosed on July 16 that an autonomous agent entered its production infrastructure through a malicious dataset and ran more than 17,000 actions over a single unattended weekend, escalating to node access and moving laterally. A second case followed in October. Both became public because the organization disclosed it and researchers wrote it up afterwards. Software has machinery for this, in CVEs and information sharing centres. For AI agents that machinery is being assembled now: an AI information sharing and analysis centre is in development under the Department of Homeland Security, and the people building it have said they want to avoid duplicating what the private sector already has. What nobody has is the layer underneath such a centre: the format a deployed agent's sensor uses to report, automatically, without naming its owner. An exchange needs something to exchange.

One detail from that first disclosure is worth sitting with: during the investigation, hosted frontier models declined to help analyse the attacker's artifacts, because they could not tell an incident responder from an attacker. The responders ran an open-weight model on their own infrastructure instead. A defence that disappears at the moment you need it is part of why this project measures self-hosted setups too, and not only the hosted ones.

So the piece worth building is the plain one: a format a deployment can use to say what it saw, without saying whose it was. Seven fields, a pseudonym the member picks, a preview they read before anything leaves, and totals withheld until three organizations have seen the same thing. The sensor is the reporter. The scanner is how a pattern earns the right to be reported in the first place.

We are not claiming agents are easy to break. The opposite, so far: GP-0003 ran 20 times against a hardened Claude Code and succeeded 0 times, with the agent naming the injected instruction in 19 of those runs. That is in the matrix beside everything else. A defence that depends on every vendor being careless is not a defence, and an attack nobody reports is not measurable at all.

Every pattern has a stable ID, links to OWASP and MITRE ATLAS, a runnable test with a harmless payload, and a detection rule.

• The test powers scans: run every pattern against your agent and see which attacks get through.
• The detection powers sensors: block the attack in real time.
• The result is what the scan measured: an attack success rate for one pattern against one named model and harness, with the run count and a 95% interval. They collect in the attack matrix.
• Sightings are what each organization's sensor saw, shared as counts with no content in them. This is the part that does not exist anywhere else, and it is why the project is built the way it is. The minimal hub is built and tested; the wider network is still in design. See ARCHITECTURE.md.

The words above are used precisely. docs/GLOSSARY.md says what each one means.

Season 1 runs October 5 to October 29, 2026. PROGRAM.md is the one page that says what we are doing, what you can pick up without asking, and when it ships. Live progress is in docs/STATUS.md, generated from this repository.

Want to contribute? START_HERE.md gets you set up in about 15 minutes and points you to a first task.

New to the design? Read ARCHITECTURE.md: the three domains of defense (actions, words, thoughts), how the registry, scan, sensor and network fit together, and the roadmap.

Taking part

One command does each thing, and each asks before it changes anything.

./guardian	Start. Shows the drill, then asks what you want
./guardian drill	Attack your own machine through your own sensor. Nothing leaves
./guardian protect	Put the sensor in front of the MCP servers your agents use
./guardian verify	Check those servers still answer, and really are behind the sensor
./guardian measure	Measure a real agent on your machine against these attacks
./guardian canary add	Register a value the sensor should watch for leaving
./guardian report --preview	The whole of what would be shared, before anything is
./guardian share on / off / forget	Agree to report, stop, or delete everything held about you
./guardian status	What this machine has done. Reads local files and nothing else

protect reads the configuration of Claude Code, Claude Desktop, Cursor, Windsurf, VS Code and Gemini CLI, shows every server it found with the command it runs, copies each file before writing it, and can be undone with --remove. Codex keeps its servers in TOML, which the standard library reads and cannot write, so those are reported with the exact lines to paste rather than changed. It starts in monitor mode: the first thing a sensor does to real work should not be to stop it.

What is shared, and what is not

Eight fields, counts only: a pseudonym you choose, sensor version, rules version, pattern, action, the hour, a count, and whether it came from a drill or live traffic. No tool names, no arguments, no URLs, no paths, no message text, nothing finer than an hour. Those are not removed from the report; they are never read.

Before anything is sent	You see the entire document and agree once
Rows carrying your pseudonym	Deleted after 30 days
The counts they contributed to	Kept, and identify nobody
Everything about you, on request	./guardian share forget
Reporting under a name in use	Refused unless signed with that member's key
A total from fewer than three organizations	Withheld, because it would be traceable

What this measures

A detection found at one organization becoming a working defence at another, and how long that took. scripts/time_to_protection.py reports the distribution: how many members adopted, the median, and how many never did, because a member who never adopted is the result rather than missing data.

A sensor that has been removed or killed stops reporting, and a sign of life goes once a day whether or not there is anything to report. So absence is visible to the network. A sensor cannot be made tamper proof against an agent running at the same privilege on the same machine; it can be made tamper evident, and that is what this is. See THREAT_MODEL.md.

How it works

Everyone here is a contributor. Fork the repository, pick an issue, open a pull request. The machine checks everything first: format, tests, that the rules still catch attacks and still leave ordinary work alone, and that every pattern maps to MITRE ATLAS. Then a reviewer approves and a maintainer merges. Do good work for a few weeks and you are invited to be a reviewer; keep reviewing well and you can become a maintainer. Your name, and your organization if you opt in, are credited automatically, in the order people contributed. Every week we demo what shipped.

flowchart LR
    A[Pick an issue<br/>and claim it] --> B[Fork and branch]
    B --> C[check.py new-pattern<br/>or edit the files]
    C --> D[python3 check.py<br/>git commit -s]
    D --> E[Open a pull request]
    E --> F{Automatic checks}
    F -- red --> C
    F -- green --> G[Reviewer approves<br/>in their area]
    G --> H[Maintainer merges]
    H --> I[Credited automatically<br/>and demoed on Friday]

Three roles: contributor, reviewer, maintainer. What each can do and how you move between them is in GOVERNANCE.md. Start at START_HERE.md, which is a first contribution in about fifteen minutes.

What's in this repository

Folder	What it is
patterns/	One YAML file per attack pattern
schema.yaml	The pattern format
coverage/	Every MITRE ATLAS technique, triaged by where the protocol can act on it
scanner/	Validates the registry and measures an attack success rate against an agent
sensor/	The MCP proxy, the CLI, and everything a member runs
hooks/	Client hooks that cover an agent's own tools, which never pass through MCP
receiver/	The HTTP contract a receiver implements, and one implementation of it
spec/	The sightings format, normative, with a conformance suite
demo/	A 90-second end-to-end demo with a visual report

No dependencies beyond the Python 3.9+ standard library.

Coming next: reference agents beyond Claude Code, so an attack success rate can be compared across models, and scenarios for the patterns the scan cannot yet run.

Pattern lifecycle

Status	Meaning	Can block traffic?
draft	Proposed; format valid	No
verified	Test and detection proven by automatic checks; two reviewers approved	No
enforced	Approved for sensors to act on	Yes

How contributions are checked

Run every check with one command:

python3 check.py

Every pull request runs the same script automatically. Today it checks:

1. Format: every pattern validates against schema.yaml, and its ID matches its filename.
2. Payload safety: canary tokens are well formed, and every destination is inside reserved, unroutable space: .test, .example, .invalid and .localhost (RFC 2606 and RFC 6761), the example.com family, the RFC 5737 documentation addresses, or loopback. Anything else is refused, including bare public IP addresses.
3. Detections prove themselves: every attack case in corpus/attacks/ must still be caught, and the ordinary work in corpus/benign/ must raise nothing. On pull requests, the run summary shows what the change catches and flags compared with the base branch.
4. Rules are safe to run: the rule lint rejects signatures that match plain prose, could hang the sensor on crafted input, or hide characters from reviewers. A change to the rules must add a test or corpus case.
5. Tools work: the scanner, sensor and hook test suites pass.

Coming before patterns can move past draft: each test run against the vulnerable reference agent (must be exploited) and the hardened one (must resist), a benign corpus large enough to measure false-alarm rates, and a duplicate check. How rules are kept safe is in docs/RULE_SAFETY.md.

Then maintainers review. Patterns need two approvals: at least one from an organization other than the contributor's, and never all from the same company. There is one maintainer today, so that rule cannot be met yet: changes are reviewed by the founding maintainer alone, and the two-approval rule starts the moment a second maintainer joins. Adding maintainers from other organizations is the project's first governance goal.

Every commit is signed off under the Developer Certificate of Origin (git commit -s).

Contributing a pattern

1. Copy docs/pattern-template.yaml to patterns/ and give it the next free ID. patterns/GP-0001.yaml is a complete example.
2. Fill in every field, including the test and the detection.
3. Run python3 check.py, then open a pull request. Credit goes in the credits field, with your name and organization.

Reporting an incident

Don't open a public issue for an active attack or anything specific to one vendor's product. Use the private reporting process in SECURITY.md. We follow coordinated disclosure: affected parties hear first, and the public advisory comes after a fix or on a set timeline.

The project

• START_HERE.md: your first contribution
• TRACKS.md: the areas of work
• CONTRIBUTING.md: how to contribute
• CONTRIBUTORS.md: everyone who has contributed
• THREAT_MODEL.md: how the protocol itself is protected
• docs/RULE_SAFETY.md: how a bad rule is kept out
• docs/proposals/: designs under discussion
• GOVERNANCE.md: roles, decisions and neutrality
• ROADMAP.md: the next twelve months
• docs/DECISIONS.md: design decisions and the security baseline checklist
• CODE_OF_CONDUCT.md and MAINTAINERS.md

Who maintains it

Maintained by the Guardian Protocol Research Group, a working group of YC founders and researchers. How it publishes and how someone becomes an author are in docs/RESEARCH.md.

License

Apache 2.0.