The facts your security review needs.
This page is written for the person running the security review. It states what the architecture guarantees, what data Axiru touches, what external auditors found, and where the compliance program stands. Every claim is verifiable against the codebase or the public changelog.
Verify the path you will enforce.
Enforcement requires a supported call routed through Axiru. Webhook observation cannot stop money that already moved.
| Action | Availability | Control point | Limit |
|---|---|---|---|
| Stripe refunds routed through Axiru | Live integration | Before execution | Supported requests only; exceptions need separate approval and current policy checks. |
| Direct Stripe API or Dashboard actions | Outside the enforcing path | Not intercepted | A later webhook may be observed. Restrict bypass paths and verify the caller integration. |
| Stripe payout, transfer, dispute and credit webhooks | Observation | After execution | Replay, review and evidence; cannot block a transaction that already executed. |
| x402 supported pre-authorization | Live | Before payment | Requires the supported token-verifying integration; separate from Stripe refund coverage. |
| Stripe DAA | Shadow | Observation / simulation | No live DAA enforcement claim. |
| USDC on Solana | Live, enabled per organization | Before execution | Enabled per organization on request. Confirm execution scope; no protocol compatibility claim. |
A hash chain provides tamper evidence for recorded decisions; it does not prove capture completeness or prevent bypasses. Verify your specific path before activation.
Download the refund security review packet · Download the synthetic refund quickstart
Invariants, not intentions.
These properties are enforced in code and CI, not by process documents.
Hash-chained evidence ledger
Recorded decisions link to evaluated policy versions. Hash-chain verification can reveal changes to recorded evidence. It does not prove that every provider action was captured or eliminate the need to reconcile provider records.
Decision replay
Each ledger record carries the decision inputs, the policy versions, and the outcome. Any historical decision can be replayed against the same policy versions and must reproduce the same result.
Deterministic decision engine
Policy evaluation is a pure function of the proposed transfer, the policy set, and the supplied context. Same inputs, same decision. Evaluation performs no I/O and has no side effects, which is what makes replay possible. The engine is compiled logic, not a language model; it cannot be prompted or drift.
Fail-closed pre-authorization
On the signed pre-authorization path, an engine error or non-allow result means no allow token is issued. The receiving integration must verify the token before execution. This does not intercept direct provider calls; test the particular integration and bypass boundaries.
Org kill switch and connection freeze
An organization-level pause and a per-connection freeze gate supported execution paths. Calls made directly to the provider are outside this control.
Write-path ratchet
A CI ratchet detects model writes and prevents increases outside governed action paths. Existing legacy write sites remain explicitly baselined; a green check does not establish complete financial control coverage. Verify the actual caller and executor path.
What Axiru touches. What it never does.
Read-only Stripe connection for Free replay
Free replay connects to Stripe with read-only scopes. It replays history and simulates policy outcomes. It cannot create, modify, or execute anything in your Stripe account. Write scopes are only requested if you later enable enforcement, and only for the surfaces you choose to govern.
No custody of funds
Axiru does not custody funds. Supported integrations can execute authorized provider requests using scoped access; the provider moves the funds. Review requested grants, credential handling and execution coverage before activation.
Decision-scoped data
Axiru processes the transfer metadata needed to evaluate policy: amounts, counterparties, rail actions, initiator identity, and agent scopes. Full card numbers and CVV never enter the system; Stripe remains the PCI-DSS boundary. Sub-processors, retention terms, and the DPA are linked below.
External audits and remediation status.
Two external security and correctness reviews have been run against the codebase to date.
- May 2026 (batch 1): external security review of the API surface. Shipped fixes include content-type guards, timing-safe token comparison, error-response sanitization, rate-limit fingerprint hardening, and an SSRF allowlist on the Slack response path.
- July 2026 (batch 2): external codebase review covering the API surface, decision engine, Stripe, approvals, billing, and the crypto and agent packages. All P0 and P1 findings are fixed and merged, each with a regression test where a pure-function seam exists.
- Continuous guards: CI runs the write-path guard, the fail-closed contract test at the engine service boundary, and the ontology and actions suites on every pull request.
Where the compliance program stands.
Stated plainly so you do not have to ask twice.
- SOC 2 Type I: preparation is underway, with the report targeted for Q1 2027. Axiru is not SOC 2 certified today, and we will not tell you otherwise.
- Evidence exports: the evidence pack export (decisions plus a manifest) comes straight from the decision ledger, for your auditor or examiner.
- Independence: Axiru is an independent product that works with Stripe. Axiru is not affiliated with, endorsed by, or sponsored by Stripe.
Procurement questionnaires (SIG, CAIQ, VSAQ) and vendor documentation: email security@axiru.com. We will send what exists and be direct about what does not exist yet.
Found a vulnerability? Tell us.
Include reproduction steps and the affected endpoint or component. We acknowledge reports, we do not pursue good-faith researchers, and we credit fixes on request. Please do not test against other customers' data.