A security spine, not a security checklist.
The controls enterprises audit for aren’t features bolted on late — they’re how aanty is built. Isolation lives in the database, every change is on a provable log, and your data is always yours.
Eight controls, enforced by architecture.
These aren’t settings you can misconfigure into a breach — they’re properties of the kernel. Colour, role and cryptography do the work so trust doesn’t rest on “the app remembered to check.”
Tenant isolation (RLS + FORCE)
Every row is scoped by tenant in Postgres with row-level security and FORCE. A query can’t cross tenants even if the application layer is wrong.
Append-only, hash-chained audit
The kernel is event-sourced. Audit records are DB-role-enforced INSERT-only and hash-chained, so history is provable — not editable.
Full export, no lock-in
Self-serve, structured export of your conversation graph on every tier. Bulk export is never rate-limited away.
SSO, SCIM, RBAC + ReBAC
OIDC + SAML SSO, SCIM provisioning, role bundles and relationship tuples (member_of, guardian_of, client_of) for channel and portal access.
Encryption everywhere
mTLS in transit, encryption at rest, and field-level encryption for sensitive payloads. True end-to-end-encrypted channels for the subset that needs them.
Prompt-injection screening
Every AI surface is screened for injection, and AI runs on permitted, policy-allowed content only — bounded by permission trimming and exclusion zones.
DLP & information barriers
Native DLP rules (and ICAP / third-party hooks), plus information barriers between groups that must not see each other.
Residency & self-host
Data-residency options and a self-hosted / BYOC edition for sovereignty buyers — the same kernel, four deployment shapes.
Multi-tenant isolation lives in the database.
Most platforms enforce “who can see what” in application code — one missed check leaks another tenant’s data. Aanty pushes isolation into Postgres itself: row-level security with FORCE means the database refuses to return another tenant’s rows, whatever the app asks.
- RLS + FORCE on every tenant-scoped table — no BYPASSRLS for the app role.
- Least-privilege DB roles — the app, the publisher, backups and redaction each get only what they need.
- Isolation tests in CI — a cross-tenant read is a failing test, not a postmortem.
CREATE POLICY tenant_isolation ON messages_current USING (tenant_id = current_tenant()); ALTER TABLE messages_current FORCE ROW LEVEL SECURITY;
The database returns your rows and only your rows — enforced beneath the application.
Your conversation graph is yours.
The industry moved the other way — closing exports and banning LLM use of the data you generated. Aanty takes the opposite, contractual position: your graph belongs to you, and to the AI you choose.
- Full structured export on every tier — including free.
- Built-in MCP server — your graph is queryable by your own AI under your ACLs.
- No training on your content — never, contractually.
- No API lockdown — rate limits scale with plan; bulk export is always on.
- Messages, files, canvases, entity links
- Structured JSON + attachments
- On demand, self-serve, no ticket
- MCP endpoint for live, ACL-scoped access
An AI data firewall you configure per tenant.
AI reads so people don’t have to — but only what policy allows. Route models by zone, anonymize before anything leaves, and carve out channels AI can never see.
Model routing zones
Self-hosted, regional, or frontier zero-data-retention — routed per tenant policy, with a model allow-list.
Anonymization modes
Full anonymization, structural-only, local-LLM or hybrid — anonymize before an external model, de-anonymize after, destroy the mapping.
AI exclusion zones
Mark channels AI must never read. E2EE channels are excluded by construction — plaintext never leaves the device.
Per-tenant budgets & kill switches
Every AI feature has a budget and an off switch. Full provenance on every output — nothing runs unmetered or unaudited.
The certification path we’re on.
These are the certifications and attestations on aanty’s roadmap — sequenced so evidence collection starts early, not under sales pressure. We’ll publish status as each lands; we don’t claim what isn’t done.
SOC 2 Type II
Evidence collection starts in the earliest phase — not when the first enterprise asks.
ISO 27001 / 27701
Information-security and privacy management on the roadmap behind SOC 2.
ISO 42001
AI management system — becoming table stakes as agents proliferate.
HIPAA BAA
For health and sensitive-community tenants, alongside the sensitive-community policy bundle.
Roadmap, not a claim of current certification. Dangerous actions (deletion, retention changes, legal hold) are gated by tiered confirmation — MFA recheck and dual approval for the most consequential — per the admin safety tiers.
Security FAQ.
Where is tenant data isolated?
In the database. Postgres row-level security with FORCE scopes every tenant-scoped row, and the application connects as a non-superuser role that cannot bypass it. Cross-tenant isolation is covered by tests in CI.
Do you train models on our content?
No — never, and it’s contractual. Customer content is not used to train models, and you can route AI to self-hosted or zero-data-retention zones per tenant.
Can we self-host or keep data in-region?
Yes. Aanty offers data-residency options and a self-hosted / BYOC edition — the same kernel in four deployment shapes, from SaaS to a sealed environment.
What happens to our data if we leave?
You export all of it, structured, yourself, at any time. There is no lock-in and no export throttling — the no-API-lockdown pledge is in the contract.
Are you SOC 2 / ISO certified today?
Those are on the roadmap (see above). We start evidence collection early and publish status honestly as each attestation lands — we don’t market certifications we don’t hold.
Bring your security team.
We’ll walk your reviewers through the isolation model, the audit log, the AI data firewall, and the deployment shapes — and answer the hard questions directly.