Response Redaction
AxonFlow can redact sensitive data from MCP connector responses before that data reaches your application or downstream model. This is one of the key controls that makes governed connector access useful in real production systems.
Concept page. This is the canonical explanation of how response-side redaction behaves. For where redaction sits in the full request/response flow, see MCP Policy Enforcement; for the PII detectors themselves, see PII Detection.
Why Response Redaction Exists
Response-side enforcement matters because:
- a connector can return sensitive data the caller did not explicitly expect
- the returned data may contain PII, account numbers, national IDs, or regulated fields
- once that data flows into an LLM or back to a user, the exposure has already happened
For RAG systems, enterprise copilots, support agents, and internal assistants, output controls are often as important as request-side blocking.
How It Works
When a connector returns data, AxonFlow can:
- scan the response payload
- match configured policy patterns
- redact sensitive values
- return metadata showing that redaction happened
Example
Original response:
{
"customer_id": 12345,
"name": "Jane Smith",
"ssn": "123-45-6789",
"credit_card": "4111-1111-1111-1111"
}
Redacted response:
{
"customer_id": 12345,
"name": "Jane Smith",
"ssn": "[REDACTED:ssn]",
"credit_card": "[REDACTED:credit_card]"
}
Depending on which response-processor and policy path is active, you may also see more generic placeholders such as [REDACTED]. The important contract is that sensitive values are masked before they continue downstream and that the response records which fields were changed.
Redacted responses stay valid JSON
When the response payload is JSON, the redacted payload is always valid JSON. This matters because a downstream consumer — a Policy Enforcement Point, an MCP client, or the model itself — typically re-parses the redacted response and rejects malformed JSON.
Redaction is therefore structure-aware:
- A PII value that sits in a string position is masked in place (it stays a string).
- A PII value that sits in a numeric position — for example a national ID stored as
an integer,
{"nik": 3174012509900001}— is masked and coerced to a string ({"nik": "31**********0001"}), so the document remains valid JSON rather than producing an invalid token like3174…with asterisks. - PII hidden behind JSON string escapes (for example a value encoded with
\uXXXX) is decoded and matched, so escaping cannot smuggle a value past detection.
A JSON value that contains PII may be normalized (re-serialized) as part of this process; a payload with no PII is returned untouched. If redaction cannot produce a safe, valid result the response is failed closed (blocked) rather than forwarded — AxonFlow never emits a partially-redacted or structurally-broken response.
Response Metadata
Redacted responses can include metadata such as:
{
"redacted": true,
"redacted_fields": [
"rows[0].ssn",
"rows[0].credit_card"
],
"policy_info": {
"redactions_applied": 2
}
}
PII Categories Commonly Covered
- global identifiers such as credit cards, email addresses, and phone numbers
- US-specific identifiers such as SSNs
- India-specific identifiers such as Aadhaar and PAN
- EU-related identifiers such as IBAN and other region-specific fields
The exact behavior depends on the policies active for the request.
What This Page Does Not Promise
The current public docs should not promise configurable redaction modes such as full versus partial hashing, or special bypass permissions, unless those behaviors are explicitly documented and verified in the runtime you are deploying.
Treat response redaction as policy-driven output governance, not as a generic masking framework with every strategy available by default.
Configuration
The PII_ACTION environment variable controls how detected PII is handled:
| Value | Behavior |
|---|---|
block | Reject the response entirely |
redact (default) | Replace PII with [REDACTED:type] placeholders |
warn | Allow the response but log a warning |
log | Allow silently, record in audit trail |
MCP connectors support a separate override via MCP_PII_ACTION. If set, it takes precedence over PII_ACTION for connector responses only.
SDK Handling
Go
resp, _ := client.MCPQuery(ctx, req)
if resp.Redacted {
log.Printf("Redacted fields: %v", resp.RedactedFields)
}
TypeScript
const resp = await client.mcpQuery(req);
if (resp.redacted) {
console.warn('Redacted fields:', resp.redacted_fields);
}
Python
resp = await client.mcp_query(...)
if resp.redacted:
print(resp.redacted_fields)
Next Steps
- MCP Policy Enforcement for the request and response shapes
- MCP Connectors Overview for where redaction fits in the flow
- PII Detection for the detectors behind these categories
Connector Rollout Checklist
Before exposing this connector to agents, make the governance boundary explicit:
- confirm the connector belongs in MCP Policy Enforcement rather than direct application code
- map allowed operations in the Connector Capability Matrix
- place tenant, connector, and system policies using Policy Hierarchy
- use Runtime Request Paths to decide whether the caller should use MCP endpoints, gateway mode, or workflow gates
