Security architecture
Axiom is designed so that compromise of any single layer does not expose regulated data. This page expands on the posture summarized on the home page, for the benefit of IT, security, and compliance reviewers.
Layered defenses
Each layer is a separate mechanism with a separate failure mode. An attacker who defeats one still has to defeat the next. The application is treated as a potentially hostile client; the database is the source of truth and the enforcement point.
Where triggers enforce the rules, disabling them requires the table-owner role (axiom_owner), reserved for migrations and never used by the running system — not the application's runtime role (axiom_definer). So "trigger-enforced" guarantees in this document are not bypassable from any path the application or its users can reach.
Execute-only application role
Prevents: The application cannot read or write tables directly. If the app is compromised, the attacker still cannot query or modify data outside the audited function surface.
Implementation: The PostgreSQL role used by the Node.js API (axiom_user) has EXECUTE on functions and nothing else. No SELECT, no INSERT, no UPDATE, no DELETE on any table.
Function-layer authorization
Prevents: Business logic bugs in one endpoint cannot leak data through another. Every operation is gated at the SQL function boundary, not in application code.
Implementation: All data access flows through plpgsql functions that check the caller’s grants against the requested operation, domain, and facility. The application forwards the user identity; the database decides what is permitted.
Row-level security policies
Prevents: A forgotten filter in a function (or direct access by privileged roles like analytics) cannot return rows the caller is not entitled to see.
Implementation: PostgreSQL RLS policies on every regulated table enforce row-level visibility as a defense-in-depth layer underneath the function grants.
Append-only audit
Prevents: A compromised application or function-layer attack cannot doctor or delete audit records. Bypassing the protection requires DDL credentials, not application credentials.
Implementation: Audit tables (session_events and related) are INSERT-only: the application’s role has no UPDATE or DELETE privilege, and BEFORE UPDATE / BEFORE DELETE triggers reject any attempt as defense-in-depth.
SCD Type 2 versioning
Prevents: Regulated data is never overwritten in place. A superseded record stays in the database, linked to its successor; change history is a first-class citizen, not a log to be grep’d.
Implementation: Regulated tables carry record_id, id, version, previous_record_id, previous_record_hash. Data columns are immutable: the application’s role lacks UPDATE privilege on them, and BEFORE UPDATE triggers reject illegal column changes as defense-in-depth. Updates flow through lifecycle transitions and new version inserts.
Cryptographic record chain
Prevents: Tampering with historical data is detectable: any bytes changed after the fact break the hash chain, and the break can be proven.
Implementation: Each record version stores record_hash = SHA-256 of its content, and previous_record_hash linking back through the chain. Chain verification is a deterministic SQL query.
Delegation model
Delegation is first-class. Permissions can be handed over temporarily — but only under rules that prevent privilege escalation. Both types require an expiration, a reason, and a complete audit trail.
Horizontal delegation
Scope: Same domain, same or higher access level, DIFFERENT facility
Use case: A reviewer at site A is out; a reviewer at site B temporarily covers their revision queue.
Vertical delegation
Scope: Same facility, same domain, access level exactly one tier lower
Use case: A manager delegates data-entry to a technician while retaining authoring and review authority.
Every delegation records: the delegating user, the delegation type, the target scope (facility + domain + access level), expiration timestamp, grant reason, and a reference to the source grant. Delegations inherit the audit trail of the underlying grant — there is no separate, weaker channel.
E-signature authentication
21 CFR Part 11 requires re-authentication at signing time. Axiom carries a registry of authentication factor types that signing policies can require — password alone for low-risk actions, hardware-key or SSO re-auth for higher-risk ones.
Account password
Re-enter password at signing. The baseline factor required by 21 CFR Part 11.
Hardware key / platform authenticator
YubiKey, Touch ID, Windows Hello. Phishing-resistant, per-user enrolled.
Identity provider re-authentication
For SSO-linked accounts — forces a fresh login at the identity provider via OIDC prompt=login.
Change management
Regulated changes — to specifications, test methods, facility configuration, and other controlled data — route through a built-in change management workflow. Proposed changes are authored, reviewed, and approved (or rejected) with explicit audit. Nothing is changed directly on production records without passing a review gate where the process requires one.
What's not in this document
This page is a stub summary. A full technical brief — covering threat model, deployment topology, key management, backup / DR, secret rotation, and the SCD2 upgrade procedure — is available on request.
- Deployment topology and network isolation guidance
- Secrets management and key rotation
- Backup, disaster recovery, and integrity verification
- Penetration test summaries (available under NDA)
- Full audit-log schema and retention policy
Request the full technical brief
We send the complete security documentation to qualified prospects — deployment topology, key management, audit-log schema, and more.
hello@axiom.bi