Skip to main content

Data Protection

Radar action items for guards, guardrails, secrets, and content filtering. Each item below describes the problem, why it is a risk, a concrete example of what can go wrong, and the step-by-step fix in Willow.

No Active Guards​

Problem. Your organization has no active guards or guardrail providers attached to MCP traffic.

Why it is a risk.

  • Without guards, sensitive data (API keys, customer PII, secrets) can flow through tool calls and into logs unobserved.
  • Prompt injection from a tool's output is not caught, so a malicious page or document can hijack agent behavior.
  • Compliance frameworks generally expect at least one technical control between users and external services.

Example. A user pastes a customer support transcript into a chat. Without a guard, the transcript, including credit card numbers, is sent verbatim to a third-party tool, and the call is logged in plaintext.

How to solve it.

  1. Open Guards and review the built-in guards (secrets detection, prompt injection, PII detection, etc.).
  2. Enable at least one runtime guard and one build-time guard. Start with secrets and prompt injection.
  3. Optionally connect an external guardrail provider (ActiveFence, Prompt Security, custom webhook) for additional coverage.
  4. Attach guards to the right scope (organization, group, or specific integrations) so they actually run.
  5. Confirm guards are firing by checking Monitor > Logs after a few tool calls.

No Runtime Guards​

Problem. Build-time guards may exist, but no runtime guards are attached, so live tool calls are not inspected.

Why it is a risk.

  • Build-time checks miss anything that depends on runtime context (user input, tool output, dynamic arguments).
  • Sensitive data can be sent to a tool and returned to the agent without any inspection.
  • Detection becomes purely reactive, you only learn about leaks via logs after the fact.

Example. A user asks the agent to summarize a Notion page. The page contains the Stripe live API key. With no runtime guard, the key is read by the agent and emitted to the chat history.

How to solve it.

  1. Open Guards and create or activate a runtime guard.
  2. Choose a scope (runtime), a direction (input, output, or both), and the entities the guard applies to (integration, toolkit, skill, command).
  3. Set the action: Redact, Warn, or Block depending on severity and your tolerance for false positives.
  4. Save the guard and run a test tool call.
  5. Watch the guard results in Monitor > Logs > Guard Events.

No Build-Time Guards​

Problem. No build-time guards are active, so skills, commands, and toolkits can be published without inspection.

Why it is a risk.

  • Hardcoded secrets, malicious instructions, or unsafe code can ship to many users at once via the managed marketplace.
  • Reviewers have to check everything by eye, which does not scale.
  • Anything synced from Git (skills, MCP servers, toolkits) bypasses runtime checks if there is no build-time gate.

Example. A new "Repository Scanner" skill is added to the marketplace. It contains an embedded private key the author forgot to remove. Without a build-time guard, the skill is published and copied to many devices.

How to solve it.

  1. Open Guards and enable the built-in build-time guards: Secret & Credential Detection, Prompt Injection Detection, and Code Injection Detection at minimum.
  2. Attach them to the entity types you want covered (skill, command, toolkit, integration).
  3. Set the action to Block for high-confidence findings so unsafe content cannot be published.
  4. Re-validate any existing entities that were created before the guards were enabled.

Content Redaction Disabled​

Problem. MCP request and response content is being persisted in logs without redaction.

Why it is a risk.

  • Audit logs are read by more systems than the original tool call (SIEM, log archive, support tooling).
  • Anyone with access to logs may end up with copies of secrets or customer data.
  • Long retention combined with plaintext content means a single log breach can expose months of sensitive payloads.

Example. A help desk engineer queries the audit log to debug a tool failure. They see the raw payload, which includes a customer's social security number. The engineer should not have access to that data.

How to solve it.

  1. Open Admin > Settings > Logs.
  2. Turn off Include MCP Content in Logs so tool-call and response bodies are no longer attached to logs. Only interaction metadata (user identity, timestamp, tool name, and status) is kept.
  3. If response bodies are logged separately, turn off Log Response Content as well.
  4. Verify by inspecting a fresh log entry and confirming the payload content is no longer present.
  5. Communicate the change to engineers who rely on log payloads for debugging, they may need to add a debug-only path.

Stale Vault Secret​

Problem. A Vault secret has not been updated in at least 90 days.

Why it is a risk.

  • Long-lived secrets are more likely to leak via screenshots, logs, dotfiles, or terminated employees.
  • Some upstream providers (Stripe, AWS, GitHub Apps) require periodic rotation for compliance.
  • Even if the secret has not leaked, rotating proves your rotation process actually works.

Example. A vault secret called STRIPE_LIVE_KEY is one year old. A former contractor still has a copy in their .env.bak file from when they had access. Because the secret has not been rotated, that copy still works.

How to solve it.

  1. Open the upstream provider's dashboard (for example, Stripe, GitHub, AWS) and create a new credential.
  2. Open Admin > Settings > Vault in Willow.
  3. Edit the affected secret and paste the new value. Click Save.
  4. Confirm the integrations or MCP configurations that reference the secret with {{vault.SECRET_NAME}} still work.
  5. Revoke the old credential at the upstream provider.
  6. Add the secret name to your rotation calendar so it does not slip again.

Secrets In MCP Configuration​

Problem. An MCP server's configuration JSON appears to contain a hardcoded credential, for example, an API key, OAuth client secret, JWT, private key, password, or database connection string.

Why it is a risk.

  • MCP configurations are easier to share, copy, sync to Git, and screenshot than Vault-managed secrets.
  • A leaked configuration can immediately authenticate against the upstream provider.
  • Detection rules in your SIEM may flag the leak only after it has been pushed to a remote repository.

Example. A user enters this configuration:

{
  "type": "http",
  "url": "https://api.example.com/mcp",
  "headers": {
    "Authorization": "Bearer sk-ant-abc123...realsecret..."
  }
}

Anyone who can read the integration sees the live API key. If the configuration is exported (via Git sync, JSON export, or screen sharing), the key leaves Willow in plaintext.

How to solve it.

  1. Open Admin > Settings > Vault in Willow.
  2. Click Create Secret, name it descriptively (for example, EXAMPLE_API_KEY), and paste the current value.
  3. Open the affected integration's MCP configuration.
  4. Replace the inline secret with a Vault reference: "Authorization": "Bearer {{vault.EXAMPLE_API_KEY}}".
  5. Save the configuration. Willow resolves the reference securely at runtime.
  6. Rotate the credential at the upstream provider, because the previous value was already in plaintext and may have been copied.
  7. Update the Vault secret with the rotated value and confirm the integration still works.
  8. Repeat for every secret reported by the radar item.
On this page