Skip to main content

AI agents spend real money. Who's watching?

Real money needs explicit policy, clear trust boundaries, and auditable decisions. Reinx uses deterministic controls—never hidden AI judgment—to decide whether a request can execute automatically or needs human review.

Provider-scoped PCI boundary·Encryption at rest and in transit·Scoped agent credentials·SOC 2 in progress·Dakota custody infrastructure

Six security layers. Total control

The request crosses explicit boundaries from identity to organization scope, policy, signing, and audit. The agent cannot skip a stage.

01

Human and machine authentication

Clerk sessions, organization keys, and scoped agent keys establish who is acting.

02

Organization context and role scope

Every request is resolved to an organization and, where applicable, constrained to project and team scope.

03

Wallet and workspace gates

KYB, workspace lifecycle, and wallet readiness are checked before financial operations.

04

Deterministic payment policy

Budgets, per-payment caps, velocity limits, and approval rules run before execution.

05

Signing and custody boundary

Reinx builds and authorizes payment intent; custody and signing stay inside hardened infrastructure.

06

Audit trail and pause control

Every tool call and financial decision is recorded. Pausing an agent blocks new payments.

What we store. What we don't

What Reinx stores

Agent names and configurationsBudget limits and spending policiesTransaction metadata and historyRestricted access tokens (hashed)Dashboard preferences

What we NEVER store

Card numbers or CVCsWallet private keysFinancial account credentialsRaw API keys (only hashed)Agent AI context or memory

When virtual cards launch, issuing-provider elements will keep card data out of the Reinx frontend and backend. Dakota, a FinCEN-registered MSB, runs the wallet, on-ramp, off-ramp, and KYC infrastructure. Wallets are non-custodial: Reinx holds the ECDSA P-256 signing keys, and customers can revoke Reinx’s signing authority at any time.

Agents never hold provider credentials

An agent does hold a scoped Reinx bearer credential so it can call MCP tools. It never receives wallet private keys, custody signing material, or provider secrets. Those remain behind the Reinx API and hardened signing boundary.

Scoped Reinx bearer key — never provider signing credentials
No tool exposes private keys or raw custody credentials
One-time agent keys are stored as HMAC hashes server-side
Credential Flow
Isolated
AI AgentSends structured request
Restricted TokenScoped permissions only
Reinx BackendValidates policy, holds credentials
DakotaSigning Infrastructure
Raw credentials never leave the backend

Bank-grade encryption. Everywhere

01

In Transit

TLS 1.3 encrypts all data between your device and our servers.

TLS 1.3
02

At Rest

AES-256 encrypts all stored data. Row-level database policies ensure each account only sees its own records.

AES-256
03

API Keys

Stored as an HMAC-SHA-256 hash. Shown once at creation and replaceable anytime.

HMAC-SHA-256
TLS 1.3·AES-256·HMAC-SHA-256
Found a vulnerability?We take security reports seriously. Reach out and we'll respond within 24 hours.
Report Issue

Trust is earned. We're building it.

Join the waitlist and be first to deploy agents with real financial guardrails.

See All Features