Cloud Redaction Policies

Glubean redacts sensitive data before results leave your machine. The CLI applies redaction rules from your project config during upload. See CLI Redaction for the local rules.

Cloud adds a team-facing safety net on top of that local behavior.

Two layers of redaction

Redaction runs in two places, configured independently:

Author your local rules by hand in glubean.yaml under defaults.redaction. On ingestion the server re-applies a fixed built-in baseline (it does not load your team dashboard policy for CLI runs), so don’t rely on dashboard toggles to catch a value you didn’t also cover locally. defaults.redaction is additive — it can only add keys/patterns, never disable a built-in scope.

Functional runs and load runs differ. For functional uploads, defaults.redaction is applied when you run a profile: glubean run --profile <name> or glubean ci run. An ad-hoc functional run such as glubean run tests/ --upload does not resolve a profile and uses the built-in baseline only. For load uploads, glubean load ... --upload reads defaults.redaction from project config during upload preflight, even when the load target is explicit.

See CLI Redaction for the local rules.

Configuring rules in Cloud

Go to Team → Redaction in the Cloud dashboard when Cloud-managed surfaces need team-level redaction policy.

For CLI uploads, the important rule remains: configure project-specific redaction in glubean.yaml, then use a profile for functional uploads or glubean load ... --upload for load uploads. The server baseline still re-applies common safety rules at ingestion, but dashboard policy should not be treated as a replacement for local upload redaction.

Scopes

Scopes control which data areas are scanned for sensitive values. Each scope targets a specific field in a specific event type.

These dashboard controls apply to Cloud-managed surfaces. CLI uploads still use local redaction plus the fixed server baseline described above.

HTTP scopes:

General scopes:

Each scope can be individually enabled or disabled. Disabled scopes skip redaction entirely for that field.

Protocol plugins can publish additional scope declarations for custom hosts. The CLI also includes generic trace scopes for metadata, request bodies, and response bodies, so common protocol traces such as gRPC metadata are covered by the baseline upload path.

Global Sensitive Keys

Add additional keys that should be treated as sensitive across all scopes. These are additive — built-in scope-specific keys (like authorization in request headers, password in request bodies) are always active.

Value Patterns

Built-in patterns detect common secret formats in string values:

Toggle each pattern on/off. You can also add custom regex patterns with a name and regex.

Replacement Format

Choose how redacted values appear:

Local Config Format

The CLI reads redaction rules from defaults.redaction in glubean.yaml:

defaults:
  redaction:
    sensitiveKeys: [x-custom-secret, internal-token]
    customPatterns:
      - { name: stripe_key, regex: "sk_live_\\w+" }
      - { name: internal_id, regex: "int_[a-f0-9]{32}" }
    replacementFormat: labeled

The built-in baseline (scope-specific sensitive keys + 5 default patterns) is always active and cannot be weakened. Your config can only add rules on top.

Preview before uploading

Use glubean redact to see exactly what will be masked without uploading:

glubean redact --input .glubean/last-run.result.json

This uses partial masking in the console so you can verify which values are caught. See CLI Redaction for details.

Server-side redaction

Cloud applies baseline redaction server-side at ingestion time as a safety net. Even if the CLI skips or misconfigures redaction, the server will catch common secrets before persisting events.

For CLI uploads, redaction happens locally first. Server-side redaction is idempotent — already-redacted values pass through unchanged.