# Security

Canonical: https://auggy.dev/docs/security
Status: Published
Package: auggy 0.5.0

**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 [hello@looselyorganized.xyz](mailto:hello@looselyorganized.xyz) 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. |

> **Note: 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.

## Related

- [Delegated authorization](https://auggy.dev/docs/delegated-authorization/markdown)
- [Architecture](https://auggy.dev/docs/architecture/markdown)