DRC
reference operator public

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:

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

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.