Agents read the spec before they act. So it is guarded like code.
A spec of record is the first thing every agent session reads, which makes it the most trusted text in your repo. DurableSpec is built so that trust can’t be turned against you: nothing runs that you didn’t ask for, nothing leaves your machine, and nothing in the spec can hand an agent a job of its own.
Plain files and one small script. Nothing calls home.
Markdown, two Agent Skills and one Python script that uses only the standard library. Nothing to install from a package registry, and you can read all of it in an afternoon.
No accounts, no tracking, no network at all, except an upgrade you start yourself.
An upgrade runs a new release only if its tag is signed by a DurableSpec release key, and that key is written into the copy you already have. Taking over the GitHub repository isn’t enough to reach your machine.
The installer writes nothing but its own files, and refuses to follow a link that leads out of your repository.
The spec is knowledge, not commands.
The spec shapes how an agent does what you asked: your conventions, your architecture, your decisions. It can never give the agent a new task or widen what it may do.
- Instructions are reported, not followed. If the spec, or code and docs the agent reads, asks it to send data anywhere, download and run something, change permissions, skip a check or ignore its instructions, the agent tells you instead.
- Your conventions still work. Build commands, git habits and the way your team works are followed as before. The line is drawn at new tasks and wider reach, not at useful guidance.
- Review it like code. If your repository takes outside contributions, require review of
doc/spec/, for example with a CODEOWNERS entry.
A spec is often public. What goes in it is checked.
The skills never open or quote secrets, and keep internal host names, IP ranges, cloud account ids and customer names out of the spec. The check script backs them up on every commit:
- It fails on anything shaped like a secret: private keys, cloud and GitHub tokens, AI provider keys, passwords in links.
- It flags what deserves a second look: text addressed to an AI, hidden comments, invisible
characters, long encoded blobs, private IP addresses and cloud account ids.
check --strictfails on those too, for CI.
We tuned the patterns against eleven working specs, about 140,000 words written mostly by agents. They raised no false alarms, and found one real cloud account id in a design document.
Tell us privately.
Report a vulnerability through GitHub’s private reporting, not a public issue. You’ll hear back within a week. The full threat model is in the spec.