How to keep sensitive data out of AI debugging context

The fastest way to help a coding agent investigate a production failure is often the riskiest one: give it access to the logging platform and let it search.

That may expose far more than the incident needs. Production logs can contain authorization headers, cookies, access tokens, private URLs, customer data, and unrelated events from other services. Even when the agent finds the right evidence, the context window may already contain data that never needed to leave the logging system.

DebugBundle takes a different path. It prepares a bounded incident artifact first, applies mandatory protection before that evidence is stored or returned, and gives the agent only the connection it needs for the investigation.

We have now shipped a deeper sensitive-data protection layer across DebugBundle's SDKs, server, CLI, MCP server, GitHub Action, and WordPress integration. The goal is simple: useful production context should reach an agent, while recognized credentials and sensitive values should not.

Protect the data before it becomes AI context

Redacting a prompt at the last moment is too late. By then, the same value may already exist in an SDK queue, a raw event object, a processed bundle, a downloaded file, or a tool response.

The current DebugBundle policy applies protection at three boundaries:

1. Before SDK buffering and transport. Upgraded SDKs inspect application-owned event data before it enters their queues or leaves the process.
2. Before server persistence and processing. The ingestion path validates and protects accepted events again before they become stored and derived incident evidence.
3. Before protected evidence leaves DebugBundle. Incident context, bundles, and reproductions are scrubbed again on supported retrieval paths before they are returned through the API, CLI, MCP, or GitHub Action.

That third boundary matters for older evidence. An event captured before the latest SDK protection can still receive the current privacy projection when it is retrieved. It is a backstop for access, not a claim that every historical copy has been rewritten or deleted.

The protection contract has a version, telemetry-privacy-v1, so consumers can distinguish a projected response from an unverified one. The current GitHub Action refuses to write a successful artifact response when that privacy contract is missing or unknown.

What the redaction policy recognizes

The policy covers defined sensitive keys and high-confidence credential patterns, including:

• passwords, secrets, API keys, and authentication fields;
• authorization and cookie headers;
• recognizable access-token formats and labeled credentials in text;
• private-key blocks;
• credentials and sensitive query values in URLs;
• validated payment-card patterns.

It also checks nested objects, arrays, and JSON represented as strings within fixed limits. Those limits are deliberate. An error-reporting SDK should not freeze an application while walking an enormous or hostile object.

For example, useful routing context can survive while a credential is removed:

{
  "route": "/checkout",
  "shipping_country": "DE",
  "authorization": "[REDACTED]"
}

Applications can add their own sensitive field names for business-specific data. Those custom fields extend the mandatory baseline in the protected releases. They do not turn the baseline off. Application hooks are followed by another mandatory pass, so a supported credential introduced by a hook does not silently return to the captured payload.

The exact behavior and configuration are documented in the redaction guide.

Give agents incident evidence, not a raw-log login

Redaction reduces exposure inside captured evidence. Authorization decides how much evidence an agent can reach in the first place. Both controls matter.

A normal DebugBundle member token can read and manage resources. That is useful for an operator, but broader than an agent needs when it is only investigating an incident.

The restricted agent connection uses a separate, expiring credential with one project and one fixed read scope. It exposes five evidence operations for project summary, incident listing, incident detail, incident context, and bundle retrieval. It cannot resolve incidents, change capture policy, manage tokens, or fall back to member permissions.

Issuance is disabled by default and must be deliberately enabled by the operator after the compatible server path is deployed. Teams can still use the ordinary member connection when they need the broader workflow, but the distinction is explicit.

This gives a coding agent a smaller surface to work with. It can inspect the error, related request and log context, release information, and available reproduction evidence without receiving a general login to the logging platform. See token and connection permissions and the MCP setup guide for the available connection modes.

The SDKs stay small and safe for host applications

We did not turn every SDK into a miniature data-processing gateway. The same portable privacy cases run across the maintained Node.js, Browser, Python, PHP, Ruby, Java, .NET, Go, Android, Swift, and React Native implementations, using the normal patterns of each platform.

The checks are bounded, package growth remains modest, and the SDK safety contract is unchanged: capture failures must not crash the host application or throw uncaught exceptions into application code. Native queue replay, context updates, application hooks, relay delivery, and transport paths all received regression coverage.

For this release, Node.js, Browser, Android, Java, Go, Swift, and React Native moved to 2.0.0 because custom sensitive-field lists now extend the mandatory policy instead of replacing it. Python, PHP, Ruby, .NET, and WordPress ship the protection in 1.5.0, where that configuration was already additive. The matching CLI and MCP release is 1.10.0, and the GitHub Action is 2.0.0.

The WordPress integration now uses the protected PHP and Browser dependencies and safer private or temporary spool handling. Browser-to-backend relay support keeps the write-only project token on the server when an application has a backend. For separated deployments, the split frontend and backend guide explains the origin and relay setup.

What this protection does not claim

Security copy becomes unhelpful when it hides the boundary of the guarantee. These limits remain important:

• Automatic rules cannot identify every piece of confidential prose. Avoid putting private data in exception messages, URL paths, logs, or custom fields when you do not need it.
• Upgrading does not retroactively erase historical raw objects, logs, backups, exports, notifications, or content already shared with another system.
• Installed applications receive the new client-side protection when they update their SDK or plugin. Server-side retrieval protection remains a backstop for supported evidence paths.
• A custom queue, exporter, or storage adapter supplied by an application needs its own security review and acceptance.
• Redaction is not a general defense against prompt injection. An agent still needs bounded tools, appropriate permissions, and human review before consequential actions.

If you use local-only mode, the evidence stays in the storage you operate. If you send that local artifact to an external AI provider, that provider receives the content you choose to send.

A safer production debugging workflow

The practical workflow is straightforward:

1. Upgrade the SDKs and integrations used by the application.
2. Capture only the evidence needed to investigate failures.
3. Add application-specific sensitive field names where the built-in policy cannot know your domain.
4. Use a backend relay for browser capture when a backend is available.
5. Give an agent a restricted connection when it only needs incident evidence.
6. Review a controlled test bundle before broadening production capture.

This release improves the protection behind that workflow without changing the basic shape of a debug bundle. Errors, requests, related logs, release context, and reproduction details still live in stable fields. Existing integrations keep their purpose. The difference is that recognized sensitive values now face the same mandatory policy across more capture paths and again when protected evidence is retrieved.

That is the kind of security work we want in DebugBundle: mostly behind the scenes, difficult to bypass accidentally, and clear about what it can and cannot guarantee.

Read the full security overview, review the redaction controls, or start with the SDK guides for your platform.