SECURITY

A firewall you can audit, not a badge wall.

APPEN’s security story is architectural: the card number, the dangerous secret, never enters the agent’s world, and every control below is enforced server-side, in code, not in a policy PDF. No compliance logos here until they’re earned; this page tells you how it works.

The credential boundary

your agent                    APPEN                        issuing partner
──────────                    ─────                        ───────────────
holds crd_ handle      →      policy engine decides   →    holds the PAN
holds ak_live_ key            logs every decision          executes payment
sees decisions + receipts     stores NO card numbers       (bank-sponsored,
NEVER sees PAN / CVV                                        Mastercard network)

There is no card-number column in APPEN’s data model and no API response that carries one. A card is represented to your agent as a handle (crd_…) plus a last-four. A compromised or prompt-injected model has nothing to leak, because it was never given anything worth leaking.

Agent keys: built to be revoked

• — ak_live_ keys are shown once and stored as a sha256 hash. We cannot read them back; neither can an attacker who reads the database.
• — One key per agent, scoped per tool. Revoking one kills one agent — the rest of the fleet keeps working.
• — Agent keys cannot approve purchases, mint keys, pause cards, or read card numbers. Those endpoints require a human session and return 403 to any agent key, always.

The engine’s own guarantees

• — Deny by default. A purchase in a category with no budget envelope is denied before any rule runs.
• — Approval is not a bypass. When you sign off on a parked purchase, the full rulebook re-runs: a merchant lock or spend cap still declines even after your approval.
• — Every decision is explained and persisted. The per-rule verdict is stored on the decision itself; the audit trail is not a separate system that can drift.

Where the PCI boundary sits

Card numbers live with our bank-sponsored issuing partner; payments will execute via network tokenization or vault-proxy patterns. APPEN’s servers are designed to stay outside PAN scope, which keeps your integration outside it too. When a human owner needs a full card number, that happens in an issuer-hosted reveal, not through APPEN’s API.

Honest posture

We’re pre-certification and say so: no SOC 2 badge yet (the control set is being built into the product from day one, which is the cheap time to do it), invite-gated launch, and card issuance turns on with our issuing partner’s BIN connection. Every claim on this page is verifiable in the product today — the docs show the 403 boundary live.

Report something

Found a vulnerability or something that smells wrong? Email dalton.redden@blindbilling.com with “security” in the subject. Reports get a human reply, fast.