Policy
What are the 8 policy presets?
Areev ships with 8 policy presets that configure governance behavior for the entire memory database: gdpr, ccpa, hipaa, lgpd, pipl, sox, ephemeral, and permissive. This context database uses presets to apply regulation-appropriate encryption, consent handling, PII/PHI detection, retention, and erasure rules for AI memory in a single configuration step.
Each preset enforces a specific combination of controls. The regulated presets (gdpr, ccpa, hipaa, lgpd, pipl) require encryption and enable PII detection. The sox preset requires encryption and mandates a 7-year retention period with no erasure. The ephemeral preset auto-deletes grains after 24 hours. The permissive preset requires nothing. When multiple policies are active, the strictest rule wins for each dimension — combining gdpr and hipaa, for example, yields the strictest of both.
| Preset | Encryption | Consent | PII | PHI | TTL | Erasure |
|---|---|---|---|---|---|---|
gdpr | Required | Explicit | Yes | No | Optional | Crypto-erasure |
ccpa | Required | Opt-out | Yes | No | Optional | Crypto-erasure |
hipaa | Required | Explicit | Yes | Yes | Required | Crypto-erasure |
lgpd | Required | Explicit | Yes | No | Optional | Crypto-erasure |
pipl | Required | Explicit | Yes | No | Optional | Crypto-erasure |
sox | Required | None | No | No | 7 years | No |
ephemeral | Required | None | No | No | 24 hours | Auto-expire |
permissive | Optional | None | No | No | None | Manual only |
# Create a database with GDPR policy
areev create --policy gdpr --master-key-env AREEV_MASTER_KEY
# Create with multiple policies (strictest rules win)
areev create --policy gdpr,hipaa --master-key-env AREEV_MASTER_KEY
How does Areev enforce policies at write time?
The policy engine checks every add() operation before the grain is persisted. This autonomous memory system runs checks in order: consent verification, processing restriction check (GDPR Art. 18), PII/PHI detection, and guardrail enforcement.
Consent grains themselves are exempt from consent checks to avoid a chicken-and-egg problem — you must be able to store consent before checking for it. When a grain contains PII, the policy determines whether to tag it for review or block it outright. When a grain contains PHI under the HIPAA policy, the write is blocked unless valid consent exists. TTL ceilings enforce data minimization by blocking data that would exceed the retention period at write time.
add(grain) -> PolicyEngine::check_write() ->
1. Is the user's processing restricted? (GDPR Art. 18) -> Block
2. Does the grain require consent? -> Check Consent grain exists
3. Does the grain contain PII? -> Tag or block based on policy
4. Does the grain contain PHI? -> Block if HIPAA and no consent
5. Has the TTL ceiling been exceeded? -> Block expired data
How does policy sealing work?
Policies are sealed at database creation time, recording the active policies and configuration hash in the audit trail via a PolicySealed event. This creates an immutable record of the AI agent memory governance rules that were in effect when the database was created.
Sealed policies can be upgraded (adding stricter policies) or downgraded (removing policies, which requires a documented reason). Both operations produce audit events (policy.upgraded or policy.downgraded) that record the change for regulatory accountability. The configuration hash (SHA-256 of the policy state) enables point-in-time verification that policies have not been silently altered, satisfying SOC 2 CC8.1 change management controls.
# Upgrade: add HIPAA to an existing GDPR database
areev modify --add-policy hipaa
# Downgrade: remove HIPAA (requires reason)
areev modify --remove-policy hipaa --reason "Discontinued healthcare use case"
How does PII/PHI detection work with policies?
When a policy enables PII or PHI detection, Areev scans grain content at write time using regex pattern matching with optional NER model inference. This context database classifies detected patterns and either tags or blocks them depending on the active policy.
PII patterns cover email, phone, SSN, IP address, credit card, and date of birth. PHI patterns cover all 18 HIPAA Safe Harbor identifiers including names (3 formats), geographic data, dates, ages over 89, addresses, and city+state combinations. Detection is hardened against evasion: Base64 payloads are decoded and scanned, Unicode homoglyphs are NFKC-normalized, and zero-width characters are stripped before scanning. The detect_pii() API is always available for on-demand scanning regardless of policy.
import requests
# On-demand PII detection
resp = requests.post("http://localhost:4009/api/memories/default/detect-pii", json={
"content": "Contact john@example.com or 555-0123"
})
detections = resp.json() # [{"type": "email", ...}, {"type": "phone", ...}]
areev detect-pii "Contact john@example.com or 555-0123"
Related
- Compliance: Compliance verification overview
- GDPR: GDPR-specific policy requirements
- HIPAA: HIPAA-specific PHI handling
- Configuration: Setting policy at startup