Security

Your data stays yours

Retanu is built for organizations that take data seriously. Every design decision starts with: what happens if something goes wrong?

Transparency note: This page describes what is built and tested today vs. what is planned. We do not claim certifications we haven't earned. Early-access partners get full visibility into the current posture.

Organization isolation

Implemented & tested

Every organization's data is stored in the same database but separated by row-level security (RLS) policies. The application connects with a restricted role that can only see rows belonging to the authenticated organization. One organization cannot access another's data, configuration, or logs.

Database-level enforcement — not just application logic
Restricted app role — cannot bypass security policies
16 automated tests — verify that organization A cannot see organization B's data

-- Security policy (simplified)

CREATE POLICY org_isolation ON requests

USING (tenant_id = current_setting(

'app.current_tenant')::uuid);

-- App role cannot bypass

GRANT USAGE ON SCHEMA public

TO retanu_app;

-- Verified by automated tests

✓ org_a cannot read org_b rows

✓ org_b cannot read org_a rows

Credential security

Implemented

API keys never logged

Provider API keys are never written to application logs. A scrubber removes sensitive material from all log output.

Implemented

Zero-retention default

Inference request and response content is not stored by default. Only routing metadata (model, cost, latency) is kept unless you opt in.

Implemented

Automatic scrubbing

Every log entry passes through a scrubber that removes patterns matching API keys, tokens, and credentials.

Fail-closed budget controls

Implemented & tested

Budget checks and rate limits run before any inference call is made. If the budget system itself is unavailable — database issue, network timeout — the request is rejected, not passed through. This prevents silent overspend even during system issues.

Spend cap enforcement

Budget checked with 98% accuracy. When a workspace exceeds its cap, requests are blocked with a clear message.

Rate limit enforcement

Per-workspace rate limits enforced at the gateway. Excess requests are rejected before reaching any provider.

Structured logging

Implemented

All logs are structured JSON with request metadata (organization, model, latency, token counts, cost) but never include prompt content or API keys.

What's done vs. what's planned

Capability	Status
Row-level security on all organization tables	Done — QA-tested
Restricted application database role	Done
Secure authentication functions	Done
Credential scrubbing in logs	Done
Zero-retention default (no content logging)	Done
Fail-closed spend caps & rate limits	Done — QA-tested
Cross-organization isolation tests (16 tests)	Done — passing
TLS in transit	Done (deployment-level)
Streaming support	Done — SSE with per-chunk delivery
KMS/Vault for key storage	Planned — currently env-var backed
SOC 2 Type II	Planned — not started
Audit log	Planned — v2
WAF / DDoS edge layer	Planned — deployment-level
Penetration test	Planned — pre-GA

Questions about our security posture?

Early-access partners get a full walkthrough of the isolation model, the test suite, and the planned hardening roadmap.