MCP API data loss prevention

When your organization has gateway DLP enabled, tool data your MCP client fetches through POST /v1/mcp is subject to your organization’s data loss prevention (DLP) policy before it leaves Kindo: the gateway redacts what the policy says to redact, and refuses to return content it cannot inspect. For organizations without gateway DLP enabled, results pass through unchanged.

This is the same DLP engine and the same redaction representation you see on the Kindo chat and model APIs. What differs is how the policy is selected.

The policy is provider-neutral

On the chat and model APIs, DLP resolves against the model and provider that will serve the request. An external MCP client calls its own model directly, so the gateway has no downstream model — and it will not take one from the client, because a client-declared model could be used to select a weaker policy.

Instead, the gateway resolves the policy from what it can verify about the caller:

• your organization’s DLP settings for the integration the tool belongs to;
• the DLP settings of every user group you belong to;
• and the DLP settings of the individual tool being called, which take precedence over the integration’s when both configure filters.

The result is the strictest combination: if any of those levels redacts an entity type, it is redacted. Because the policy is resolved on every call, an administrator’s change takes effect on your next request — there is nothing to refresh or reconnect.

Administrators configure this under Settings > Integrations. Organizations with no integration-level DLP configured see results returned exactly as the upstream server produced them.

What gets redacted

Part of the result	Treatment
text content items	Redacted.
structuredContent	Every string value is redacted, at any depth. The JSON structure is preserved.
Embedded resources with inline text	The text is redacted.
resource_link items	name, title, and description are redacted. The uri is returned unchanged so the link keeps working.
Results with isError: true	Redacted like any other result — error text is tool output and often quotes the record that failed.
image content items	Returned unchanged. Images carry no text the DLP engine reads.

Redactions use the DLP engine’s entity placeholders — an email address becomes <EMAIL_ADDRESS>, a US social security number becomes <US_SSN>, and so on. Custom phrase and pattern filters your administrator has configured are replaced with REDACTED.

What gets blocked

Some content cannot be inspected: Kindo cannot read it, so it cannot redact it, and returning it would make an opaque payload the way around the policy. When DLP is enabled for the integration, a result containing any of the following is blocked in full rather than partially returned:

• embedded resources carrying a binary blob;
• audio content items;
• any content type Kindo does not recognize.

The call fails with a JSON-RPC -32000 error and data.reason = "dlp_uninspectable_content". If DLP is not enabled for the integration, this content is returned normally.

A DLP outage is treated the same way: if the policy cannot be determined or applied, the call fails with -32000 and data.reason = "dlp_unavailable". Kindo does not fall back to returning unredacted data.

Both envelopes are documented in MCP API errors.

What this means for your client

• Handle -32000 as terminal, not retryable. A block is a policy decision. Retrying returns the same error; the fix is a policy change or a tool that returns inspectable content.
• Expect placeholders in tool output. A tool that returns an email address may return <EMAIL_ADDRESS> instead. Do not treat a placeholder as a literal value to write back.
• Prefer tools that return text or structured content over tools that return binary attachments, if your organization enables gateway DLP — text and structured content are redactable, attachments are not.