Security & trust

Built to be audited, not just believed.

An agent that touches invoices, bills, and bank details has to be engineered like the control system it is. This page says plainly how — including what is enforced in structure rather than policy.

The edge

One gate, explicit allow-lists, scoped principals

Every request enters through a single gateway that authenticates, resolves the tenant, and forwards only an explicit allow-list of routes — anything not on the list does not exist. Internal services trust only the gateway's signed context, never client headers.

A customer signing into the portal is a different kind of principal than your staff: bound to exactly one customer of one company, with no path to anything else. Vendor onboarding pages are single-purpose tokens — the link is the whole credential, it expires, and it can be rotated the moment it leaks.

Money movement

Dual control, by construction

Vendor bank details are entered by one person and verified by a different one — the same person structurally cannot do both. They are never accepted from an email or read off a bill; a bill printing different coordinates than the verified account is held, every time.

Payment runs are proposed by the agent and released by a person holding the payer role, with a second release required above the threshold you set. Account numbers are stored encrypted (AES-GCM) with only the last four digits visible; full numbers exist solely for the payment partner at execution time.

The policy engine hard-blocks a set of actions no configuration can grant to the agent: releasing a run, changing bank details, marking invoices paid without a payment application, posting unconfirmed records to your accounting system.

Fraud

Screens on every document, every sender

Every incoming bill runs the gauntlet: exact and near-duplicate detection, sender-domain history and look-alike checks, and the redirection screen comparing printed bank coordinates against the vendor's verified account. New vendors are screened against the OFAC SDN list, and their taxpayer IDs are format-validated before anything is paid.

Document text itself is screened for instruction-like content — a bill that tries to talk to the model is flagged as evidence of fraud, not followed. Attachments pass a malware gate (quarantine, content-type verification by magic bytes, antivirus scan) before any system reads them.

Data

Secrets in a vault, sensitive fields sealed

Provider credentials and signing secrets live in a cloud KMS vault and are rendered onto hosts at deploy time — never committed, never in the codebase. Vendor bank numbers and taxpayer IDs are sealed with authenticated encryption; the working copies your team sees are last-four and salted fingerprints.

Each customer environment is tenant-scoped end to end: every table carries the tenant, every internal query filters on it, and cross-tenant identifiers answer as not-found rather than forbidden — the system does not confirm what it will not show.

Accountability

The decision log and an append-only ledger

Every agent action exists as a proposal — with its evidence, confidence, policy result, and pinned model version — and every decision on it is recorded once, immutably, with the human or policy that made it. Executions are idempotent and deterministic: a redelivered event cannot double-apply a payment or double-send a reminder.

The receivable and payable ledgers are append-only: applications, credits, and reversals are new rows that reference what they change, so the balance of any invoice or bill on any date is reproducible, and an auditor can walk from a statement line to the document it came from.

Email

Inbound and outbound mail treated as hostile until proven

Outbound mail is sent over authenticated SMTP with SPF and DKIM on our sending domains, threaded reply addresses per conversation, and templates for anything a model did not write — model-composed text always crosses a human before it leaves.

Inbound mail routes by dedicated per-company addresses, never by trusting sender headers. Attachments go through the same quarantine and scan gate as uploads, bank details typed into an email body are flagged and never acted on, and every message is logged with what happened to it — including the ones that were rejected.

Want the deeper answers?

Design partners get the architecture walkthrough, the threat model, and direct access to the people building it.

Join the design-partner waitlist
invoiceAI

The AR & AP agent that never moves money on its own. Built for businesses in the US and Canada.

© 2026 invoiceAI. All rights reserved.

invoiceAI prepares, proposes, and executes within the policy you set. Payments release only on a human decision under dual control, vendor bank details change only with two people, and every decision is logged with its reasoning.