Security

Policy enforcement that holds, whether a human or an AI made the request.

Axiru's governance architecture was designed for a world where the entity requesting a refund might be a rep under pressure, an automated workflow with a bug, or an AI agent that has been manipulated. The enforcement layer doesn't trust the requester, it evaluates the request against your policy, every time, identically.

See how it works →
Architecture

Simple architecture, legible boundaries

Two integration paths. One decision plane. Different guarantees — stated plainly.

APath A · Pre-execution enforcement (can block)
Caller
app / agent / MCP
axiru.decide
policy + approval
Allow / Deny /
Require Approval
Stripe API
only on Allow

The Stripe API call only fires after Axiru returns Allow. This is the only path that can prevent a bad outflow.

BPath B · Post-hoc observability + audit (cannot block)
Stripe already
executed action
Stripe webhook
refund / payout / dispute
Axiru ingest +
shadow replay
Decision ledger
+ leakage report

Webhooks fire after Stripe executes. Use Path B to evaluate Axiru on your own history before flipping enforcement on.

Path A · Enforcement

API / MCP call → Axiru → Stripe

Your refund / payout / transfer code calls axiru.decide first. Axiru evaluates the intent against policy and returns Allow, Require Approval, or Block. The Stripe API call only happens on Allow. This is the only path that can prevent a bad outflow before money moves.

  • Pre-execution: yes
  • Required for live enforcement plans
  • Wired in: ~10 lines (REST) or MCP server registration
Path B · Observability + audit

Stripe webhook → Axiru ingest

Axiru subscribes to Stripe webhooks (refund.created, charge.dispute.created, payout.created, transfer.created, etc.) to build the decision ledger, run shadow-mode replay, and surface policy violations after the fact. Webhooks fire after Stripe has already executed the action, so this path is observability and audit, not pre-execution enforcement.

  • Pre-execution: no — Stripe already executed
  • Powers Shadow Mode, leakage replay, and the audit ledger
  • Wired in: one Stripe Connect OAuth click

When we say "decisions before money moves" we mean Path A. Path B is what you use to evaluate Axiru on your own history before flipping enforcement on.

Technical controls

The controls that matter for any team composition.

These controls were designed for human support teams. They are also exactly the right architecture for AI agent deployments, because the failure modes are structurally identical. Governance at the enforcement layer holds regardless of who or what initiates the request.

Policy before execution, for every requester

Axiru evaluates policy while an action is still governable. The Stripe API call only happens after authorization, whether the request came from a human rep, an AI agent, or an automated script.

Append-only ledger, sealed at the moment of decision

Governed flows record decision, rationale, approval state, and execution outcome in a durable timeline. Written once. Never modified. The authoritative record for audit, legal review, and board reporting, for human and AI decisions alike.

Audit-ready evidence, attached to every decision

Evidence stays attached to the decision path so finance and audit do not need to reconstruct context from multiple systems. Especially critical when AI agent decisions need to be defensible in a legal or regulatory context.

Role-based approvals, requester cannot self-authorize

Approver workflows separate requester, reviewer, and operator responsibilities. No human rep and no AI agent can approve its own request above its assigned threshold. Policy determines the approver, not the requester's confidence.

Deterministic enforcement, not model-based

Axiru's policy engine uses compiled deterministic logic, not a language model. The enforcement layer that governs AI agents cannot itself be prompted, drifted, or hallucinated. Policy rules are explicit, versioned, and human-authored.

Tenant-aware handling

Workspace context, policy evaluation, and access boundaries are organized so customers can reason clearly about review scope and control ownership, across teams that may include both human agents and AI automation.

Compliance

Where we are on compliance certification.

SOC 2 Type II, in progress

Axiru is currently pursuing SOC 2 Type II certification with a target observation window opening Q3 2026. Design partners receive our security architecture review and a draft controls narrative before audit scope is finalized.

Compensating controls in place today:

  • Single-tenant data isolation per workspace, enforced at the database row-level policy layer
  • Encryption at rest (AES-256, AWS KMS) and in transit (TLS 1.3) across all services
  • Append-only decision ledger with cryptographic chain-of-custody for every governed flow
  • Quarterly third-party penetration testing — most recent report available under NDA
  • Least-privilege IAM with mandatory MFA, hardware security keys for production access
  • Vendor due-diligence reviews for every sub-processor (see sub-processors page)
  • Centralized logging with 365-day retention and tamper-evident hashing
Request our security packet →

Stripe OAuth scopes & access boundaries

Axiru connects to your Stripe account using Stripe Connect with the read_only scope at v1.0.0. We do not request, store, or use any scope beyond what is required to observe and evaluate policy on the resources you configure.

What read_only is used for:

  • Read: charges, refunds, disputes, payouts, balance transactions, customers, to build the decision context and surface policy violations
  • No write at install: Axiru cannot create refunds, cancel payouts, or submit dispute evidence on your behalf at v1.0.0; queue-first sends flagged items to a human approver who executes the action inside Stripe
  • Automated Enforce mode (write capability) requires an explicit admin re-consent in a future Axiru version (v1.1.0+) per outflow class
  • OAuth token stored encrypted at rest, scoped per-workspace, revocable from your Stripe dashboard at any time

See /permissions for the full scope manifest and the exact Stripe API endpoints each governed flow touches.

72-hour breach notification commitment

Axiru contractually commits to notifying customers of any confirmed personal-data breach within 72 hours of becoming aware, in line with GDPR Article 33 and our Data Processing Addendum (DPA §8).

Notifications include: nature of the breach, categories and approximate volume of records affected, likely consequences, measures taken to mitigate, and a designated point of contact for follow-up.

Read the full DPA →

Procurement & vendor assessments

If your procurement process requires specific compliance evidence — security questionnaires (SIG, CAIQ, VSAQ), insurance certificates, sub-processor agreements, or contractual amendments — contact us. We will provide what is available and be direct about what is not yet complete.

Contact us about compliance →
Next step

The enforcement layer that was missing, for human teams and AI teams alike.

Start free in shadow mode. Connect Stripe read-only and replay your last 90 days through Axiru's policy engine before enabling any live enforcement.

Start in shadow mode first. Move to live enforcement later.

Book a Demo →

We use cookies for analytics and marketing measurement. You can reject non-essential cookies at any time.

Privacy policy
Axiru Security | Read-Only Stripe Access, Row-Level Security & Audit Controls | Axiru