Redaction

Redaction rules help keep sensitive values out of error context, logs, session data, and agent-visible evidence. Configure broad defaults at the organization level, then tighten individual projects when they handle more sensitive data.

What redaction protects

Use redaction for data that should not be displayed during triage or exposed to automation. Good candidates include tokens, passwords, payment values, personal identifiers, and customer secrets.

• Redact known sensitive fields before teammates rely on a project in production.
• Prefer targeted field scopes over broad patterns that hide useful debugging context.
• Use removal when the value itself should never be visible.
• Use replacement when responders need to know that a value was present.

Organization defaults

Organization data policy applies defaults across projects. Start here for rules that should be consistent everywhere, such as API keys, authorization headers, session cookies, and password-like parameters.

1. Open Organization, then Data Policy.
2. Add redaction rules for sensitive fields shared across projects.
3. Review the MCP exposure defaults for source, logs, sessions, params, deploys, and infrastructure.
4. Save changes and notify project owners if agent-visible evidence changes.

Project rules

Project settings can add rules for service-specific data. Use them when one project handles values that other projects never see.

• Add project rules for domain-specific IDs, partner tokens, or regulated fields.
• Keep organization rules for common secrets so projects do not drift.
• Use project MCP exposure controls to make a project more restrictive than the organization default.

Write good rules

A useful rule has a clear name, a narrow field scope, and a regular expression that matches the sensitive value without hiding unrelated context.

• Name rules after the data they protect, such as Authorization bearer token.
• Choose the smallest field scope that covers the data.
• Test with realistic examples before relying on a broad regex.
• Keep replacement text obvious, such as [redacted].

MCP exposure

MCP exposure controls decide which evidence repair agents can access. Turn off categories that are unnecessary for automated investigation or that contain sensitive data.

• Source gives agents source files and surrounding code context.
• Logs gives agents log evidence near errors and incidents.
• Session gives agents replay-related user-session context.
• Params gives agents request parameters and should usually be restricted.
• Deploy and infra expose operational context useful for root cause analysis.

Review changes

After changing redaction or exposure, review a recent error group and incident to confirm responders still have enough context. Rotate any project key or agent token that may have been exposed before the rule existed.