Security
Auggy's security boundaries, the prompt-injection threat model, and how to report a vulnerability privately.
What the runtime decides
The runtime, not the model, decides caller identity, authorization, trust level, and which tools are available.
- Peer trust is structural. Transports assign creator, agent, or public at the boundary; public callers are anonymous or recognized.
- The capability table filters tools before the engine sees them. A tool outside the current trust level cannot be called.
- Route and tool requires rules check scopes and grants before any handler or execute function runs.
- Context carries provenance (operator, system, agent, agent-derived, peer-derived), so peer-supplied text cannot masquerade as operator policy.
- Secrets stay in .env or provider-owned stores, never in prompt-visible files.
Prompt injection threat model
Injected text can always influence what the model says. The security question is what it can make the runtime do. Auggy treats injection as a vulnerability when it crosses an explicit security boundary.
| Injection outcome | Treated as |
|---|---|
| Escalates a peer's trust level | Vulnerability. In scope. |
| Exfiltrates creator-only memory | Vulnerability. In scope. |
| Evades the capability table | Vulnerability. In scope. |
| Changes tone or wording without crossing a boundary | Model-quality issue. Out of scope. |
Secrets and data at rest
- Keep provider keys and signing secrets in .env or a provider-owned secret store.
- Persistent runtime state, including visitor memory, auth records, and AgentMail ledgers/review queues, lives in hardened SQLite stores. On Railway core paths resolve directly under /app/data and AgentMail is isolated under /app/data/agent-mail/<augment-name>.
- identity.md, learned-behaviors.md, skills, and knowledge sources are prompt-visible. Never put secrets in them.
Report a vulnerability
Do not open a public issue for a security vulnerability. Email [email protected] with a description of the vulnerability and its impact, the Auggy and Bun versions, and a reproduction such as proof-of-concept code or step-by-step instructions. Invited source collaborators can also use GitHub private vulnerability reporting.
| Stage | Target |
|---|---|
| Acknowledgement | Within 3 business days. |
| Initial triage and severity | Within 7 business days. |
| Fix or mitigation | Prioritized by severity ahead of feature work. |
| Public disclosure | Coordinated, typically within 14 days of fix availability. |
Best effort, not an SLA
Auggy is a small project. These targets are best-effort response commitments rather than a contract. Reporters who follow this policy are credited in the advisory and changelog unless they request anonymity.
Scope and supported versions
- In scope: the Auggy runtime (kernel, augments, engines, transports, memory), the CLI and launchd integration, and docs that claim a security property the implementation does not have.
- Out of scope: vulnerabilities in upstream dependencies (report those upstream), prompt injection that does not bypass an Auggy boundary, issues requiring physical access to the operator's machine, and operator-authored identity files.
Only the latest published minor release receives security patches. Auggy is pre-1.0 and breaking changes between minor versions are possible, so pin to an exact version in production until 1.0.