PII Detection & Redaction

AxonFlow provides built-in detection and redaction of Personally Identifiable Information (PII) in LLM interactions. The system uses a hybrid approach combining fast regex-based pattern matching with intelligent validation to minimize false positives while maintaining sub-millisecond latency.

Detection vs Policy

Detection identifies what happened. Policies determine what action to take.

For example, PII detection can be enabled while policies are configured to log-only during development, and later switched to block or require_approval in production — without changing application code.

This separation allows AxonFlow to support experimentation, audits, and enforcement within the same architecture.

Supported PII Types

Global PII Types

Type	Severity	Example	Validation
Credit Card	Critical	4532-0151-1283-0366	Luhn algorithm
Email	Medium	[email protected]	RFC 5322 format
Phone	Medium	(555) 123-4567	Format + context
IP Address	Medium	192.168.1.100	IPv4 validation
Passport	High	AB1234567	Format + context
Date of Birth	High	01/15/1990	Context-dependent
Booking Reference	Low	ABC123	6-char alphanumeric

United States PII Types

Type	Severity	Example	Validation
SSN	Critical	123-45-6789	Area/group/serial rules
Bank Account	Critical	021000021-123456789	ABA routing checksum

European Union PII Types

Type	Severity	Example	Validation
IBAN	Critical	DE89370400440532013000	MOD 97 checksum

India PII Types

Type	Severity	Example	Validation
India PAN	Critical	ABCDE1234F	10-char format with entity type
India Aadhaar	Critical	2345 6789 0123	12-digit with Verhoeff checksum

Singapore PII Types (MAS FEAT)

New in Community

Singapore PII detection is now available in AxonFlow Community Edition. See MAS FEAT Compliance.

Type	Severity	Example	Validation
NRIC	Critical	S1234567D	9-char with prefix S/T/M
FIN	Critical	F1234567N	9-char with prefix F/G
UEN	High	200312345A	8-10 digit business registration
SG Phone	Medium	+65 9123 4567	+65 format, 8-digit
SG Postal	Low	238877	6-digit Singapore postal

NRIC Prefixes:

• S - Citizen born before 2000
• T - Citizen born 2000+
• M - Foreigner from 2022+
• F - Foreigner before 2000
• G - Foreigner 2000-2021

How It Works

Two-Layer Detection

1. Agent Layer (Static Engine): Fast regex-based detection (<1ms) that flags potential PII for downstream processing
2. Orchestrator Layer (Enhanced Detector): Deep validation with Luhn, MOD 97, and context-aware confidence scoring

False Positive Prevention

The enhanced detector uses context analysis to reduce false positives:

Input: "Order number: 123-45-6789"
       → Context contains "order" → Low confidence (not flagged as SSN)

Input: "Customer SSN: 123-45-6789"
       → Context contains "SSN" → High confidence (flagged as SSN)

Configuration

Environment Variable Configuration

Configure PII detection behavior using environment variables:

Variable	Values	Default	Description
PII_ACTION	block, warn, redact, log	warn (v7.0.0+)	Action when PII is detected
AXONFLOW_PROFILE	dev, default, strict, compliance	default (v7.0.0+)	Bundles per-category actions. See Governance Profiles.

Actions:

• block - Reject request with HTTP 403
• warn - Log warning, allow request through unchanged (v7.0.0+ default)
• redact - Mask detected PII with category-tagged placeholders (e.g., [REDACTED:ssn]), allow request
• log - Log for audit only, allow unmodified

# v7.0.0+ default: PII is flagged in audit but the request flows through
docker compose up -d

# Restore the v6.1.0 behavior — PII masked with [REDACTED:*]
PII_ACTION=redact docker compose up -d

# Block requests containing PII (recommended for production)
PII_ACTION=block docker compose up -d

# Or use the strict profile which sets PII, SQLi, and sensitive data to block
AXONFLOW_PROFILE=strict docker compose up -d

Default Changed in v7.0.0

PII detection now defaults to warn (flag but do not mutate the data). The previous default was redact. Silent redaction was breaking debugging flows — see Governance Profiles for the full rationale and the new profile matrix.

Gateway Mode

PII detection is automatically applied during the gateway pre-check flow:

# Pre-check detects PII in prompts
curl -X POST https://api.example.com/api/policy/pre-check \
  -H "Content-Type: application/json" \
  -d '{
    "user_token": "user-123",
    "client_id": "community",
    "query": "Customer SSN: 123-45-6789",
    "context": {}
  }'

Response includes policy and redaction context:

{
  "approved": true,
  "requires_redaction": true,
  "policies": ["sys_pii_ssn"],
  "context_id": "ctx_abc123"
}

SDK Usage

Community Examples

See complete working examples in the AxonFlow examples repository.

Python

from axonflow import AxonFlow

async with AxonFlow(
    endpoint="http://localhost:8080",
    client_id="your-client-id",
    client_secret="your-secret",
) as client:
    result = await client.get_policy_approved_context(
        user_token="user-123",
        query="Process refund for SSN 123-45-6789",
    )

    if not result.approved:
        print(f"Blocked: {result.block_reason}")
    elif result.policies:
        print(f"Policies triggered: {result.policies}")

TypeScript

import { AxonFlow } from '@axonflow/sdk';

const axonflow = new AxonFlow({
  endpoint: 'http://localhost:8080',
  clientId: 'your-client-id',
  clientSecret: 'your-secret',
});

const result = await axonflow.getPolicyApprovedContext({
  userToken: 'user-123',
  query: 'Process refund for SSN 123-45-6789',
});

if (!result.approved) {
  console.log(`Blocked: ${result.blockReason}`);
}

Go

import "github.com/getaxonflow/axonflow-sdk-go/v5"

client := axonflow.NewClient(axonflow.AxonFlowConfig{
    Endpoint: "http://localhost:8080",
})

result, err := client.GetPolicyApprovedContext(
    "user-123",
    "Process refund for SSN 123-45-6789",
    nil, nil,
)

if !result.Approved {
    log.Printf("Blocked: %s", result.BlockReason)
}

Java

import com.getaxonflow.sdk.AxonFlow;
import com.getaxonflow.sdk.AxonFlowConfig;
import com.getaxonflow.sdk.types.*;

AxonFlow client = AxonFlow.create(AxonFlowConfig.builder()
    .endpoint("http://localhost:8080")
    .build());

PolicyApprovalResult result = client.getPolicyApprovedContext(
    PolicyApprovalRequest.builder()
        .query("Process refund for SSN 123-45-6789")
        .userToken("user-123")
        .build()
);

if (!result.isApproved()) {
    System.out.println("Blocked: " + result.getBlockReason());
}

Redaction Behavior

When PII is detected, the exact behavior depends on your configured action:

Action	Runtime behavior	Typical use
redact	Request continues with detected values masked or removed	Default for production systems that need continuity
block	Request is rejected during pre-check or request processing	Strict regulated workflows
warn	Request continues and detection is recorded	Rollout and tuning
log	Request continues and detection is written to audit	Observation and evidence collection

If you need different behavior by execution path, use the mode-specific overrides:

• PII_ACTION for the shared default
• MCP_PII_ACTION for connector/MCP traffic
• GATEWAY_PII_ACTION for gateway-mode requests

Performance

Operation	Latency	Notes
Single type detection	~1μs	Type-specific check
Full detection (no PII)	~17μs	All patterns
Full detection (with PII)	~25μs	With validation
Long text (10KB)	~1.4ms	Comprehensive scan

Compliance

AxonFlow's PII detection helps with compliance requirements:

Regulation	Supported PII Types
PCI-DSS	Credit card numbers, bank accounts
HIPAA	SSN, DOB
GDPR	Email, phone, IP address
CCPA	SSN, email, phone

Best Practices

1. Enable validation for financial data (credit cards, bank accounts)
2. Use context to reduce false positives
3. Tune actions by environment so staging can warn while production blocks or redacts
4. Log PII detection events for audit trails
5. Test with realistic data to tune confidence thresholds

See Also

• Media Governance -- PII detection is also applied to text extracted from images via OCR as part of the media governance pipeline
• Security Best Practices
• Policy Configuration
• Gateway Mode