What Peeve reads, stores, and never sees.
Plain statements of what Peeve does and doesn't touch, written so you can drop them straight into a security review.
Page text enters the model as data, with instruction and content strictly separated. The model requests capabilities by name. It cannot compose a request. An injection suite runs in CI on every deploy.
Three boundaries the design won't let Peeve cross.
Peeve starts with no ability to act. You grant capabilities one at a time in peeve.config.json, reviewed in a pull request. Nothing runs that you didn't add.
Capabilities point at your own endpoints; your execution service makes the call with your keys. The model requests a capability by name. It never sees a token or composes a raw request.
Before anything writes, the effect is shown and (outside read-only scopes) confirmed. A single command is the kill switch: it disables all acting at once.
The model asks by name. Your keys never cross the line.
The model requests a capability by name: change_plan, not a URL and not a token. Only that name crosses into your infrastructure, where your execution service holds the credentials and makes the call. An injection can ask for a capability; it can never compose a raw request or reach a key.