How your data is kept apart, and kept safe

Every table that belongs to an agency carries a PostgreSQL row-level security policy, and the policies are forced — they apply to the table’s owner as well as to the application. The application connects as a role that cannot disable them, cannot create objects, and cannot read a row outside the tenant in scope.

The practical consequence: a mistake in a query does not leak another agency’s data, because the database refuses before the query returns. That is checked by an isolation test suite that attempts cross-tenant reads on every domain, and by a script that compares the live database against the expected policy set.

Passwords are hashed with Argon2id. Sessions use short-lived access tokens and rotating refresh tokens with reuse detection — if a stolen refresh token is used after the real one, the whole family is revoked.

• Two-factor authentication by authenticator app, with one-time recovery codes
• A list of your active sessions, and one control to end all the others
• A password reset ends every session, because a forgotten password is sometimes a stolen one
• Account lockout after repeated failures, and no way to tell from the outside whether an address has an account

Card details are entered on our payment provider’s own secure page and never reach Aegis. What is stored is the brand, the last four digits and the expiry — enough to tell one card from another and nothing like enough to charge it.

No card number or security code appears in our logs, errors, analytics, database or AI context, because none ever arrives. Provider webhooks are signature-verified, replay-protected and applied at most once.

Integration credentials and second-factor secrets are encrypted at rest with AES-GCM under a deployment key. Tokens of every kind — sessions, invitations, reset links, API keys — are stored only as SHA-256 digests, so a database dump yields nothing usable.

Traffic is served over HTTPS with HSTS, a strict Content-Security-Policy with a per-request nonce, and the browser is never given an API token: it talks to our own server, which attaches credentials on the far side of a cookie it cannot read.

Sign-ins, permission changes, data changes, AI actions, approvals, billing events and integration changes are appended to an audit log the application can write and cannot edit or delete — that is a database grant, not a convention.

Each entry is hashed into a chain with the one before it, and the head of that chain is kept in a separate table the application cannot write at all. An altered or removed entry breaks the chain, and you can verify and export it yourself.

The assistant reads through your own permissions — a record you cannot see is one it cannot see, because it runs on the same scoped session your request does. It answers from your rows, cites each figure, and refuses rather than guessing.

• Every run logged with model, inputs, cost, latency and outcome
• Agents hold explicit tool and scope permissions, and a budget
• Risky actions require a human approval that is recorded
• Customer data is not used to train models