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

Encrypted storage, authorized plaintext retrieval. Dashboard connection views show status rather than stored values. Authorized runtime API or MCP credential requests return the actual provider credential over HTTPS. The agent runtime—and a third-party host running it—receives that value.

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.

Credential-release permissions. Gazebo checks the requested service and agent-declared method before releasing a credential. It does not proxy subsequent provider calls or reduce a retrieved key's authority. Provider scopes and IAM enforce downstream permissions; only use runtimes you trust with the released key.

Audit credential access. Authorized-agent credential requests record agent identity, service, declared method, outcome and timestamp. These are retrieval records, not proof of downstream provider activity. Authentication failures do not create credential-access records.

Revocation blocks future retrieval. Revoking an agent invalidates its Gazebo token without changing the provider key. A previously retrieved key can remain usable; a suspected leak may require provider-side revocation or rotation.

Security sections

• Encryption model — AES-256-GCM, key management, what's encrypted
• Credential storage — encrypted storage and runtime key exposure
• Audit and compliance — what's logged, format, retention
• Responsible disclosure — how to report a vulnerability

Security page

For the product-level security overview and limitations, see the Security page.