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.
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.
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)
Why This Matters for Discovery and Procurement
Teams looking for AI governance often search for terms like:
- PII redaction for AI agents
- RAG data redaction
- AI output filtering
- governed database access for LLMs
This capability is one of the clearest examples of why AxonFlow is more than an SDK wrapper. It is part of the operational governance layer that becomes necessary as AI applications move into production.
