Security overview
Gazebo is built around one core principle: credentials are the highest-value asset in your stack, and the system handling them should be designed as if attackers are already inside.
Design principles
Zero plaintext in transit to the browser. After a credential is stored, its plaintext value is never returned to a web client — not to the Settings page, not to the API, not to any authenticated user session. Credentials only leave the vault in response to an authorized agent get_credential call.
Encrypted at rest with AES-256-GCM. Every credential is encrypted before being written to the database. The encryption key is stored separately from the data. See Encryption model.
Scoped by policy, not by trust. Agents don't get "your credentials" — they get credentials for the specific services their access profile allows, with the specific HTTP methods permitted. An agent that can read Stripe cannot touch GitHub, regardless of what it tries.
Audit everything. Every credential access — successful or denied — is logged with agent identity, service, method, outcome, and timestamp. Logs are append-only.
Revocation without rotation. Removing an agent in Gazebo immediately revokes its access. The underlying API key doesn't change — only the Gazebo token is invalidated. This is intentional: credential rotation affects every system using a key; Gazebo revocation affects only the agent.
Security sections
- Encryption model — AES-256-GCM, key management, what's encrypted
- Credential storage — vault design, zero-plaintext guarantees
- Audit and compliance — what's logged, format, retention
- Responsible disclosure — how to report a vulnerability
Security page
For the product-level security overview — infrastructure, SOC compliance, and certifications — see the Security page.