Security and data protection
Execution data can contain credentials, personal data, proprietary requests, and infrastructure details. Treat capture as sensitive application data.
Authentication
The API supports:
| Mechanism | Header | Typical use |
|---|---|---|
| API key | Authorization: ApiKey <key> |
SDKs, CI, service accounts |
| Bearer JWT | Authorization: Bearer <token> |
Web and interactive clients |
Keep credentials in a secret manager. Do not place them in source control, URLs, shell history, or project files used by coding agents.
Authorization
Hosted resources are scoped by tenant, identity, role, share permission, expiration, and revocation. A resource ID is not permission to read it. Cross-tenant and expired-share access should be rejected without exposing unrelated resource details.
Transport
Use HTTPS for non-local traffic. Configure TLS and browser-origin policy in the environment that runs the API. Keep health responses free of sensitive dependency information.
Capture minimization
Before capture:
- choose the narrowest capture mode that answers the question;
- enable body capture only when necessary;
- review authorization, cookie, token, password, secret, and API-key fields;
- review URLs, query strings, SQL, database arguments, message bodies, and errors;
- define retention and deletion for the captured data.
SDKs redact known-sensitive fields and bound event sizes. The Python SDK defaults to no raw body capture. Application-specific secrets still require an explicit redaction review.
drc privacy audit capture.json --policy .drc/redaction.toml --fail-on-leak
Evidence access
Team/Enterprise evidence is created from the authenticated web workspace. The browser receives authorized metadata and verification information; raw evidence data is not embedded in public pages. Evidence access remains subject to tenant and role permissions.
Data lifecycle
Use the product's retention and deletion controls for execution data. Deletion and sharing changes should be auditable and must respect legal or organizational retention requirements.
Safe integrations
- URL-encode execution and job IDs.
- Use bounded request/event payloads.
- Treat event data as untrusted input when displaying it.
- Keep agent/API credentials outside repositories.
- Use JSON output rather than parsing terminal formatting.
- Preserve request IDs and avoid placing payloads in support tickets.## Safe support reports
Do not include credentials, customer payloads, signing material, or exploit details in a public issue. Provide a minimal reproduction with synthetic data and include the stable error code or request ID instead of the captured payload.