Security

We use layered controls: no single control is the only thing standing between an attacker and your data. If one control fails, another catches it.

Systems deny by default. When an access check, a tenant scope, or a safety control cannot be evaluated, the system blocks the action rather than allowing it.

Every component gets only the access it needs to do its job and nothing more.

Tenant data is isolated at the application layer, where every query is scoped to the acting tenant, and again at the database layer through Postgres row-level security.

Row-level security is a second layer: even if the application code forgets a scope or has a bug, the database itself refuses to return another tenant's rows.

Sign-in uses an email magic link combined with a TOTP two-factor code. There is no shared-password surface to phish or reuse.

Multi-factor sign-in is required for staff, and sensitive actions require an extra check beyond the initial sign-in.

Sessions are database-backed and revocable, so access can be terminated centrally and immediately rather than waiting for a token to expire.

All traffic is encrypted in transit with TLS. Sensitive columns, including sign-in secrets such as TOTP seeds, are also encrypted at the field level at rest.

Field-level encryption means the most sensitive data is protected inside the database itself, not just at the transport and disk layers.

Privileged actions are logged with enough context to reconstruct what happened, who did it, and against which tenant.

Audit logs are retained for integrity and incident response, and are scrubbed of payload PII so the record survives without re-exposing sensitive content.

Each agent can use only the tools on its allowlist. Tools that make network requests are blocked from reaching internal services, private network ranges, and cloud metadata endpoints.

Tools run under resource limits, and we guard against prompt injection so untrusted input cannot give an agent extra abilities.

Model output never directly triggers a sensitive action. A separate, authorized control sits between what the model suggests and what the system actually does.

Security is enforced in CI as a set of gates, not as a manual afterthought. An authorization matrix and row-level-security coverage are tested on every change.

Dependency scanning and secret scanning run in the pipeline, so vulnerable packages and leaked credentials are caught before they reach production.

If you believe you have found a security issue, report it to security@spaltx.com. We welcome good-faith research, will acknowledge reports, and will work with you on coordinated disclosure. Please do not access other tenants' data or run disruptive tests while investigating.