Security & Isolation

ICE enforces data isolation at the database layer. Session data is scoped per user and per session through mandatory request headers and PostgreSQL Row-Level Security policies.

1. Session Isolation

ICE utilizes mandatory headers to enforce data boundaries at the kernel level.

• X-User-Id: Unique identifier for individual users. Ensures User A cannot access User B's historical context within a shared tenant.
• X-Session-Id: Hermetically seals memory ledgers for distinct conversations. Prevents "Context Bleed" where information from one project leaks into another.

2. Multi-Tenant Row-Level Security (RLS)

For Enterprise deployments, ICE leverages PostgreSQL Row-Level Security. RLS policies are applied at the database kernel, ensuring that every SQL query is automatically scoped to the active tenant_id and user_id. This provides a hard boundary that cannot be bypassed by application-level logic.

3. Deployment Modes

Mode	Specification
Local	Runs on local hardware. No external telemetry or cloud dependencies.
Enterprise (VPC)	Deployed within a private network. Integrates with existing IAM and security groups.

4. Compliance & Governance

PII Redaction

The engine includes a configurable compliance layer (ICE_INGEST_ENABLE_COMPLIANCE) that scrubs Personally Identifiable Information (PII) during ingestion using localized Named Entity Recognition (NER).

Data Retention

• ICE_RETENTION_DAYS: Configurable lifecycle management for session data.
• Pre-Purge Webhook: Notifies external systems before data deletion, allowing for cold-storage archiving or audit logging.
• Right to be Forgotten: API endpoints provided for atomic deletion of specific user_id or session_id data across all tiers.