Illana gives AI assistants durable memory over a customer's email, calendar, documents, and financial activity — without sending that corpus to a model vendor for training. Connected sources sync into a PostgreSQL vault the customer operates. A temporal knowledge graph links people, organizations, and memory items over time. The Model Context Protocol (MCP) server exposes search and retrieval tools to whichever LLM the customer already uses.

Security is built around isolation, encryption, and control: your data in your database, your keys, your model choice, and your ability to disconnect sources or delete the account entirely.

Illana separates ingestion, storage, graph intelligence, and model access. The LLM never holds a copy of your vault — it calls MCP tools that return scoped snippets and expand to full items only when needed.

Email
Calendar
Documents
Financial Records
      ↓
Connector sync pipeline
      ↓
PostgreSQL + pgvector
      ↓
Temporal knowledge graph
      ↓
MCP server
      ↓
Your LLM (Claude, ChatGPT, local, …)

How sync works: A background pipeline worker pulls Gmail, Google Calendar, Google Docs, Microsoft sources, and Plaid on your schedule. Records land in the vault through a fixed ingest contract — no third-party ETL platform in the path.

• PostgreSQL + pgvector — structured memory items, full-text search, and optional 1024-dim embeddings for hybrid semantic retrieval.
• Temporal knowledge graph — entities (people, organizations), mentions, relationships, and item-to-item edges (threads, attachments, co-occurrence) with timestamps on every memory item. This is Illana's time-aware graph layer, not a third-party workflow engine.
• MCP server — authenticated search tool for Claude, Cursor, or other MCP clients (natural-language questions over synced personal data).

This is the foundation of the Illana trust model.

• You own your data. Email, calendar, documents, and transactions ingested through your connections remain yours. Illana processes them to build searchable memory on your behalf.
• Data stays in customer-controlled Postgres. Self-hosted and private-cloud deployments run the vault database in your VPC or on your hardware. Illana does not operate a shared multi-tenant memory pool for enterprise pilots.
• We do not train on customer data. Illana does not use your vault content to train foundation models. Query-time calls go to the LLM provider you configure; that relationship is governed by your agreement with them.
• We do not sell or share vault content with third parties. Connectors talk only to the sources you authorize (Google, Microsoft, Plaid, etc.) and to your Illana deployment.
• You can delete all data at any time. Disconnecting a source with purge removes its vault rows. Account deletion disconnects integrations and deletes the user's memory items, entities, and credentials from the vault.

• Encryption at rest. Sensitive typed-table fields (email bodies, document sections, OAuth tokens in pipeline state, attachment job payloads) are encrypted with AES-256-GCM using a customer-supplied VAULT_ENCRYPTION_KEY. Database volume encryption depends on your Postgres host (EBS, RDS, etc.).
• Encryption in transit. Production API and MCP endpoints are served over HTTPS (TLS 1.2+). OAuth and connector traffic to Google, Microsoft, and Plaid uses each provider's TLS requirements.
• Key management. The vault encryption key is an environment secret on the customer deployment — not checked into source control. Key rotation requires a planned re-encryption procedure; contact security@illana.ai for guidance.
• Database security. Postgres runs on a private Docker network in the reference deployment; only the API and workers connect. Credentials are scoped per service. Network exposure of the database port should remain disabled in production.

• Authentication. Dashboard users sign in with email and password (bcrypt-hashed) or Google OAuth. MCP access uses OAuth 2.0 with dynamic client registration or configured static tokens, bound to a single user identity per session.
• Authorization. Every vault query is scoped by user_id. There is no cross-tenant memory access in the application layer. Team API keys exist for programmatic access with owner-scoped roles; full enterprise RBAC is on the roadmap.
• Audit logs. MCP tool calls write audit and quality-log records (tool name, arguments, result previews). Full email bodies and raw payloads are excluded from routine logs.
• Service accounts. API keys and MCP OAuth clients are issued per user or team. Connector credentials live encrypted in connection state, not in the web tier.

Illana stores and retrieves memory. You choose which model reasons over it.

• OpenAI via ChatGPT or API-connected clients today
• Anthropic via Claude and MCP connectors tomorrow
• Local or private models via any MCP-compatible host next year

Illana does not require a specific LLM vendor. Memory format and MCP tool contracts are stable across providers so you can switch models without migrating your vault.

Current posture and planned work (honest as of June 2026):

• SOC 2 Type II — on the roadmap; not yet certified. Controls are designed with SOC 2 in mind (access logging, encryption, deletion).
• GDPR — architecture supports data subject deletion and data minimization in previews; formal DPA and EU residency options available on request for enterprise deals.
• CCPA — same deletion and no-sale posture; California-specific disclosures provided during procurement.
• Legal hold — not automated in product today; enterprise pilots can coordinate export and hold procedures with our team.
• Data retention — retention follows what you keep in Postgres; disconnect-with-purge and account deletion are the primary erasure controls. Per-source retention policies are a planned enhancement.

1. Detection. Production health checks, container restarts, database connectivity alerts, and anomalous MCP audit patterns. Customers should also monitor their own infrastructure logs.
2. Notification. Confirmed incidents affecting customer data are reported to affected customers and security@illana.ai within timelines agreed in your contract (enterprise) or as required by law.
3. Recovery. Postgres backups and redeploy from known-good images; credential rotation; optional vault key rotation with support. Post-incident review documents root cause and preventive changes.

Security questions, responsible disclosure, and enterprise questionnaires: