Security
An assistant that reads your private data, reads content from strangers, and can send messages on your behalf can be talked into leaking the first through the third. HEADING OS cannot remove the first two, because that is the job. It keeps the third under your hand.
Nothing is sent without you
Every outbound message, an email or a chat message to someone else, is produced as a draft. It is sent only when you type the approval, and the send happens inside that command, while you watch. Nothing in the background holds a queue of approved messages.
Each kind of action carries a risk tier in a configuration file. Anything that can send is forced to the gated tier by code, whatever the file says, and a kind of action nobody classified is treated as gated too. Editing the configuration can add friction; it cannot remove the gate.
There is one bounded exception: notifications to your own channel, such as "the backup failed". They can only reach you, and any other recipient is refused.
Seven layers between the engine and your data
The engine is meant to be public. Your data must never travel with it, however a file was written, so seven separate checks stand in the way. Six of them ask where a file belongs; the last one opens the file and reads what is inside.
git commit -m "update contacts"
BLOCKED - non-engine content staged into the engine repo:
crm/contacts/dana-reyes.md -> refused (unresolvable); only an allowlisted engine file may be committed here
The leak guard's own words. The file name is invented.
| Bypass guard | No engine code may build a path from the engine into a data folder; every data path goes through one function. |
|---|---|
| Leak guard | Every staged file is routed by a map; a private file headed for the engine is refused at commit. |
| Data-path redirect | When the agent reads or writes a data folder, the path is rewritten to the data repository, so the engine tree never holds a data file. |
| Build partition | A public build of the engine is assembled only from files that route to the engine. |
| Tree-clean check | Proves at runtime that the engine's working tree holds no file that routes private. |
| Push wall | Pure code on the push path, also run by the pre-push hook on a plain git push. |
| Content guard | Opens each engine file and refuses private content inside it. |
A further allowlist refuses any file in the engine that is not part of the engine itself, by class and by name.
Which models see your data
Local models come first for private work: embeddings for your memory index run on your machine. When a remote model is needed, the fallback chain accepts only a short, named list of vendors and refuses any other in code. Proxy configuration does not add a vendor to that list.
Also in the path
- Secret scanning before a commit, and a content scan on every push with no skip flag.
- Prompt-injection detection on content the agent reads. It warns; it does not block, and we say so.
- Agents in isolation. Agents work in their own copies and are refused anything live: sending, publishing, or starting and stopping a service.
- A failed guard blocks. If a safety hook crashes, the action it was guarding is refused, not waved through.
Report a vulnerability
Write to admin@headingos.com with the subject line "HEADING OS security". Once the source is public, GitHub private vulnerability reporting will work as well.
Please do not open a public issue for a vulnerability. You will get an acknowledgement and, where the report is valid, a fix on a timeline that matches its severity.
Machine-readable contact: /.well-known/security.txt