Tokens never stored in plaintext
Source ingest tokens are stored as SHA-256 hashes. Validation is constant-time. Tokens are never written to logs or audit trails — only their hash prefix.
SHA-256Security
Built so the on-call engineer sleeps through the night.
Webhook traffic carries some of the most sensitive data in your stack — payment events, identity changes, access grants. Axel is engineered like the systems your security team is already comfortable with.
What we promise
Six guarantees you can hold us to today.
Every item below is implemented and tested in the codebase — not aspirational. We'd rather under-promise and ship than ride a marketing slide deck.
Payloads encrypted in transit & at rest
TLS 1.2+ on the edge. Cloudflare R2 encrypts every object at rest. ClickHouse logs are stored in customer-managed encryption keys when self-hosted.
TLS 1.2+Sandboxed transform code
Customer route filters and transforms run in isolated Worker threads with V8 resource limits, 250ms wall-clock timeouts, and no network or filesystem access. Per-process semaphore prevents noisy-neighbor.
0 egressTenant isolation by workspace_id
Every Postgres row, ClickHouse partition, and queue message is keyed by workspace_id. The dashboard enforces workspace scope on every query — there's no path to read a sibling tenant's data.
every rowBounded payload retention
Raw payloads in R2 are kept 30 days for replay. Event traces in ClickHouse have a 30-day TTL, dead letters are kept one year, and the audit log ten years. Caps are enforced by scheduled drains, not best-effort.
30 daysAudit log on every privileged action
Workspace creation, member invites, role changes, source mutations and destination writes are all recorded with actor + timestamp in an append-only audit log.
append-onlyRoadmap
The compliance work, sequenced honestly.
We'd rather you see the plan than a logo soup. Here's where the security work sits today, and where it's going next.
- ShippedTLS edge, hashed tokens, sandboxed transforms, audit log
- ShippedPer-source rate limits, body & depth caps, idempotent fan-out
- ShippedEgress guards on every destination connector — private-network and SSRF targets rejected, including connection tests
- ShippedVersioned signing secrets bound to their source, constant-time sign-in, fail-closed ingest
- ShippedRelease gate: every version passes a deterministic check suite plus an adversarial audit before deploy
- In flightSelf-serve GDPR erasure for data-subject requests
- Q3 2026SOC 2 Type I report (in observation now)
- Q4 2026BYO-cloud option for regulated workloads
- 2027SOC 2 Type II + ISO 27001
FAQ
Is Axel secure, and how is my data handled?
Is Axel secure?
Yes. Axel encrypts payloads in transit (TLS 1.2+) and at rest, stores ingest tokens only as SHA-256 hashes, isolates every tenant by workspace_id, sandboxes customer transforms with no network or filesystem access, and records an append-only audit log of every privileged action.
Is Axel SOC 2 compliant?
Axel is in a SOC 2 Type I observation period, with the Type I report planned for Q3 2026 and SOC 2 Type II plus ISO 27001 targeted for 2027. The underlying controls — encryption, tenant isolation, audit logging, and egress guards — are already in place.
How does Axel handle and store my data?
Raw webhook payloads are stored encrypted in object storage for 30 days for replay; event traces are kept 30 days, dead letters one year, and the audit log ten years. Retention caps are enforced by scheduled drains, not best-effort cleanup.
How is one customer's data isolated from another's?
Every Postgres row, object-storage object, queue message, and analytics partition is keyed by workspace_id, and the dashboard enforces workspace scope on every query — there is no path to read another tenant's data.
Have a security question?
We respond to security@axelapp.ai within one business day. Vulnerability reports get a same-day acknowledgement and a fix or mitigation timeline within 72 hours.