PII Protection

Apart Intelligence automatically detects personally identifiable information (PII) in your knowledge graph and encrypts it with your organization's own key. Only authorized users with the decryption key can view the original data.

How It Works

When you add or update a node, Apart Intelligence scans the title, content, and metadata for PII patterns. Detected PII is replaced with encrypted tokens before storage. Embeddings and search vectors are generated from the original text, so semantic search continues to work even though the stored content is encrypted.

Detected PII Types

PII Modes

CLI Commands

View PII policy

ai pii show

Enable encryption

ai pii set encrypt
ai pii set encrypt --allow-bypass
ai pii set encrypt --allowed-types email,phone_number

When you first enable encryption, an AES-256-GCM encryption key is automatically generated for your organization. This key is encrypted at rest on the server.

Switch to detect-warn mode

ai pii set detect-warn

Test PII detection

ai pii test "Contact john@example.com or call (555) 123-4567"

Scans text for PII without storing anything. Useful for testing what will be detected.

Remove PII policy

ai pii delete

Reading Encrypted Nodes

When a node contains encrypted PII, the ai get command shows the encrypted tokens by default:

ai get <id>
# Content shows: [PII:email:...] and [PII:phone_number:...]

Use the --decrypt flag to view the original data:

ai get <id> --decrypt
# Content shows: john@example.com and (555) 123-4567

Bypass

Sometimes you intentionally want to store PII unencrypted — for example, when building an employee directory in your knowledge graph. If your organization's policy has allowBypass enabled, you can skip encryption per-request:

# Via API header
curl -X POST /api/nodes \
  -H "X-Pii-Bypass: true" \
  -d '{"type": "person", "title": "Employee", "content": "bob@company.com"}'

Bypassed nodes are flagged in their metadata with bypassed: true for audit purposes.

Allowed PII Types

You can configure specific PII types that are allowed to remain unencrypted. For example, if your organization stores employee names and emails intentionally:

ai pii set encrypt --allowed-types email,phone_number

Only PII types not in the allowed list will be encrypted. SSNs, credit cards, and other types will still be encrypted.

API Endpoints

How Encryption Works

Each organization gets its own AES-256-GCM encryption key. When PII is detected, each match is individually encrypted and replaced with a token:

# Original
"Contact john@example.com for details"

# Stored (encrypted)
"Contact [PII:email:iv:tag:ciphertext] for details"

The PII type label (e.g., email) is stored in cleartext for audit purposes. Only the actual PII value is encrypted. Each token uses a unique random IV, so the same email encrypted twice produces different ciphertext.