Security & Data Privacy
Security that passes the review you're preparing for
DialogueDB is built for teams shipping AI products into regulated, multi-tenant environments. Data isolation, audit trails, and access controls are structural — not bolted on after the fact.
Why DialogueDB
Built for the questions your security team will ask
These aren't features on a roadmap. They're how the system works today — and what you can demonstrate in your next security review.
Namespace isolation at the partition level
Every query is scoped by project and namespace at the database partition key — not an application-layer filter. A missing parameter returns a not-found error, not another tenant's data.
Audit events for every operation
Entity events are emitted for all operations — creation, modification, and deletion — across dialogues, messages, and memories. Build audit logs, trigger workflows, or stream to your SIEM.
Hard delete with full cascade
When you delete a project, all associated dialogues, messages, memories, and metadata are permanently removed. No orphaned data, no soft-delete ambiguity.
Immutable dialogue mode
Lock conversations at the project level so dialogues cannot be deleted after creation. Designed for regulated workflows where audit trails must remain intact and tamper-proof.
IP whitelisting
Restrict API access to trusted networks by configuring allowed IP addresses or CIDR ranges per project. Available on Pro and Business plans.
Your data stays yours
Customer data — including conversation content, memories, and metadata — is never used for model training or any secondary purpose. Your data exists to serve your application, nothing else.
Data isolation
Two-level isolation you don't have to build
DialogueDB enforces isolation at two levels. Every API key is scoped to a single project, and within each project, data is partitioned by namespace. Both boundaries are structural — embedded in the database partition key, not enforced by application logic.
Project-level isolation
Each API key is scoped to one project. There is no query that can reach another project's data, even with a bug in your application code.
Namespace-level isolation
Within a project, the namespace field partitions data per tenant or end user. All queries are automatically scoped — omitting the namespace returns a not-found error, not someone else's data.
Structural enforcement
Both project and namespace are embedded in every partition key. The database engine itself prevents cross-tenant access — there is no filter to forget.
How data is partitioned
API Key → Project A
namespace: "tenant-1"
Dialogues, messages, memories
namespace: "tenant-2"
Dialogues, messages, memories
Different partition keys → no query can cross the boundary
API Key → Project B
Completely separate data
Different API key, different project, different partition space
Compliance ready
Answers for the security questionnaire
Engineering leaders and compliance reviewers need specifics, not marketing language. Here's what DialogueDB provides for common security review questions.
How is customer data isolated?
Data isolation is enforced at the database partition key level using a two-tier model: project-level (via API key scoping) and namespace-level (via partition key embedding). Cross-tenant queries are structurally impossible.
What audit trail is available?
Events are emitted for all entity operations — creation, modification, and deletion — across dialogues, messages, memories, and projects. Events include entity type, namespace, item ID, and operation details. Real-time delivery is available via WebSocket.
Can conversation records be made immutable?
Yes. Projects can be configured with immutable dialogue mode at creation time, which prevents any dialogue deletion. This ensures audit trails remain intact for compliance, legal holds, and regulatory requirements.
How is customer data deleted?
Project deletion is a hard delete with full cascade — all associated dialogues, messages, memories, and metadata are permanently removed. Projects can also enable delete protection to prevent accidental removal.
Is customer data used for any secondary purpose?
No. Customer data is never used for model training, analytics, benchmarking, or any purpose other than serving the customer's own application.
Can API access be restricted by network?
Yes. IP whitelisting lets you configure allowed IP addresses or CIDR ranges per project. Requests from non-whitelisted addresses are rejected before any data is accessed. Available on Pro and Business plans.
See it in your own environment
The free tier includes full API access with namespace isolation, audit events, and conversation management. No credit card required.
Security questions
Common questions about DialogueDB's security posture.
Ship AI products that pass security review
Data isolation, audit trails, and access controls — built into the database, not your application code.