Built for compliance buyers.
No overclaiming.
Every enterprise security review starts with a Google search for "<vendor> security." This is that page. Honest status, real controls, no fake badges.
How Axiom signs and verifies execution receipts
Every agent invocation that flows through Axiom produces a cryptographically signed receipt. Here's exactly what that means.
Input/output hashing
All skill inputs are serialized to canonical JSON (keys sorted alphabetically) and hashed with SHA-256. The tool output is hashed the same way. Any mutation — even one character — produces a completely different hash. Hashing happens before signing; raw inputs never touch storage.
inputs_hash = SHA-256(canonical_json(inputs))
output_hash = SHA-256(canonical_json(output))
Receipt signing — HMAC-SHA256
Axiom constructs a deterministic payload from the receipt fields and signs it with HMAC-SHA256 using a per-tenant signing key. The signature is stored alongside the receipt. Per-tenant keys mean a key rotation for one customer does not affect another.
payload = skill | timestamp | inputs_hash | output_hash
signature = HMAC-SHA256(payload, signing_key)
Timing-safe verification
When a receipt is verified, the server recomputes the expected signature from the stored fields and compares it to the stored signature using Node.js crypto.timingSafeEqual(). Constant-time comparison eliminates timing-oracle attacks that could leak key material byte by byte.
expected = HMAC-SHA256(payload, signing_key)
valid = timingSafeEqual(expected, stored_sig)
Key handling
Signing keys are stored encrypted at rest using environment-level secrets. Keys are never logged, never returned in API responses, and never transmitted in plaintext. Key rotation is a documented procedure: new key issued → receipts re-signed in background → old key retired after verification window.
What Axiom protects against. And what it doesn't.
Honest scope is more useful than a list of everything that could theoretically go wrong. Compliance buyers have seen the overclaiming — here's the real picture.
What Axiom protects against
- Tampered receipts. Any post-execution mutation of a receipt's fields (skill name, timestamp, inputs hash, output hash) is detectable: the HMAC signature will fail verification for anyone holding the signing secret.
- Replay attacks. Each receipt includes a unique ID and a microsecond-precision timestamp. Replaying an old receipt for a different audit window produces a verifiable timestamp mismatch.
- Forged invocation claims. A receipt can only be produced by a caller with a valid API key. Unsigned or incorrectly signed receipts are rejected on ingestion. You cannot fabricate a receipt that passes verification without the signing key.
- After-the-fact log manipulation. Because receipts are signed at execution time and the signature covers the full payload, retroactively editing a log entry breaks its signature. Any change — including changing the timestamp — is detectable.
- Unsigned execution claims. Any claim that a skill was or was not invoked without a corresponding signed receipt is not provable. Axiom provides the signed proof layer. Absence of a receipt is a finding.
What Axiom does not protect against
- Compromised caller environment before invocation. If the agent process itself is compromised before it calls a skill, the receipt will accurately reflect what the agent invoked — but the agent may have been manipulated. Receipt signing starts at invocation time; what happened before is outside Axiom's trust boundary.
- Malicious skill code. Axiom receipts prove that a skill was called with specific inputs and returned a specific output. They do not verify that the skill's logic is correct, safe, or unmodified. Skill code integrity is the responsibility of the skill registry layer (e.g. Koi, MintMCP). Axiom and that layer are complementary, not overlapping.
- Key compromise. If the Axiom signing key is stolen, an attacker could forge receipts. Key material is protected with environment-level secrets and rotation procedures, but this is a residual risk that no shared-secret HMAC system eliminates entirely.
- Side-channel data leaks. Axiom stores input and output hashes — not the raw data. But metadata (skill names, caller IDs, timestamps, invocation frequency) is stored and could be sensitive in some threat models. Treat Axiom receipt metadata as operational data, not as raw payload storage.
How Axiom maps to the controls you're already audited on
Compliance teams get audited on these specific controls. Here's exactly how Axiom receipts address each requirement — no hand-waving.
| Regulatory control | How Axiom satisfies it |
|---|---|
|
EU AI Act — Article 12
Record-keeping for high-risk AI systems. Providers must automatically log AI system operation throughout lifetime.
|
Every agent skill invocation produces a signed, tamper-evident receipt stored indefinitely. Logging is automatic and happens at the SDK layer — no developer action required per invocation. Receipt fields (skill name, timestamp, caller ID, input/output hashes) constitute the operational log Article 12 requires.
|
|
EU AI Act — Article 13
Transparency to users. High-risk AI systems must enable users to interpret outputs and exercise human oversight.
|
Axiom receipts map directly to the required disclosures: what skill was invoked, with what inputs (hashed), when, by which caller, and whether it executed successfully. The public
/verify endpoint lets compliance officers, regulators, or auditors independently verify any receipt without vendor involvement. |
|
SOC 2 — CC7.2
System operations are monitored to detect and respond to potential threats and security events.
|
Axiom's receipt audit trail provides real-time, cryptographically verifiable evidence of system operations. Every agent action is logged with a tamper-evident signature. The trail is queryable by skill name, caller, date range, and verification status — supporting the continuous monitoring CC7.2 requires.
|
|
SOC 2 — CC7.3
Identified security incidents are analyzed to understand their nature, scope, and impact, with evidence of incident response activities.
|
When an incident is declared, Axiom receipts provide the forensic record: which agents were active, which skills were called, what inputs were provided, and what outputs were returned — all with cryptographic proof that the record hasn't been modified since the incident. Receipt-based forensics eliminates "we can't prove what happened" from incident response reports.
|
|
HIPAA — §164.312(b)
Audit controls. Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems containing or using ePHI.
|
Axiom provides cryptographic action logs for every AI agent activity — the "mechanisms that record and examine activity" HIPAA requires. Crucially, Axiom stores only SHA-256 hashes of inputs and outputs by default, not the raw data. For PHI-adjacent workflows, this means the audit log proves an action occurred without storing the protected health information itself.
|
|
DORA — Article 12
ICT incident logging. Financial entities must implement detection, logging, and reporting of ICT-related incidents.
|
Axiom's tamper-evident receipt infrastructure satisfies DORA's requirement for reliable ICT incident logs. Receipts cannot be altered after creation without detection — a requirement DORA implicitly imposes when it mandates "reliable" logging. The cryptographic chain provides the integrity guarantee regulators expect of financial-sector incident records.
|
These mappings are provided as guidance, not legal advice. Axiom receipts constitute technical evidence that supports — but does not replace — a complete compliance program. Engage your compliance counsel to determine how Axiom fits your specific regulatory posture.
Exactly what Axiom stores. And what it doesn't.
PHI/PII buyers need to know this before the first call. Here's the precise data model — no guessing.
What Axiom stores in receipts
- Skill name — the name of the agent skill that was invoked (e.g.
send_email,query_database) - Timestamp — microsecond-precision execution timestamp (UTC)
- SHA-256 input hash — a one-way hash of the canonical JSON of all inputs. Cannot be reversed to recover inputs.
- SHA-256 output hash — a one-way hash of the tool output. Cannot be reversed to recover output content.
- HMAC-SHA256 signature — the cryptographic signature over the above fields
- Verification status — whether the receipt was verified at creation time (e.g.
verified,error) - Source — whether the receipt is from a live integration or a demo environment
- Caller ID — the identifier of the calling system (API key prefix, not the raw key)
What Axiom does not store
- Raw inputs — Axiom hashes inputs before storage. The original input values (including any PHI, PII, or proprietary data) are never written to Axiom's database by default.
- Raw outputs — Same as inputs. Only the SHA-256 hash of the output is stored, not the output itself.
- API keys — Full API keys are never stored. Only a key prefix (first 8 chars) is stored for identification. Keys are stored as SHA-256 hashes.
- User identity — Axiom does not store end-user identities from the workflow. Caller IDs are system-level identifiers, not individual user data.
Data residency
US East (AWS us-east-1) via Neon PostgreSQL. All data at rest encrypted with AES-256. TLS 1.2+ in transit.
EU residency (eu-west-1 or eu-central-1) for GDPR data-localization requirements. Timeline: Q3 2026. Contact us to be notified.
Where we are. Where we're going. No fake badges.
We are a design-partner-stage product. We will not display a SOC 2 badge we haven't earned. Compliance buyers respect honesty and punish overclaiming — this is our honest status.
MVP + pilot stage
Cryptographic signing infrastructure live. HMAC-SHA256 receipts, timing-safe verification, SHA-256 hashing, API key issuance with SHA-256 hashed storage. Public /verify endpoint. Rate limiting on verification API. CORS policy on receipt API.
SOC 2 Type 1 readiness
Formalizing security policies, access control documentation, incident response procedures, and vendor management. Working with a third-party auditor to prepare for the Type 1 observation period.
SOC 2 Type 2
12-month observation period for Trust Service Criteria: Security, Availability, Confidentiality. Type 2 report available to customers under NDA.
EU data residency
Dedicated EU PostgreSQL region for GDPR data-localization. Configurable at tenant level — receipts stay in EU for EU-domiciled customers.
ISO 27001
Information Security Management System certification. Specifically relevant for EU-headquartered enterprise customers and financial services.
2,000+ assertions. Deterministic-first. Audited in production.
Before Axiom existed as a product, the same pattern was built and used in a real $12M nonprofit with Federal Single Audit requirements. 4 signed LOIs from regulated organizations followed.
Don't trust the vendor. Audit the verifier.
A compliance buyer cannot defend "trust the vendor" to a regulator. They can defend "we audited the open-source verifier ourselves." Axiom publishes the exact same verification logic that runs server-side — MIT-licensed, dependency-free, readable in one sitting.
Dependency-free verifiers in Node.js (~150 LOC) and Python (stdlib only). Exactly the same crypto as the server. No third-party packages to trust.
-
→
Full receipt schema spec (
/spec/RECEIPT_SPEC.md) - → Canonical JSON encoding rules (deterministic hashing)
- → Signature derivation pseudocode (HMAC-SHA256)
- → 3 sample receipts: valid, tampered inputs, tampered output
- → 17 integration test cases covering edge cases
- → CI pipeline (GitHub Actions — Node 14+ and Python 3.8+)
Security questions?
Responsible disclosure, compliance questionnaires, pen test coordination, or specific regulatory mapping — reach us directly.
security@axiom-ai-19.polsia.appEvaluating Axiom against other tools? See the competitive comparison →