PoPayOne runs payroll-critical workflows with an AI in the loop — so the security model can't be “ask the model to be careful.” The database is the boundary, every action is capability-checked, and money always pauses for a human. This page explains exactly what is enforced today, and what isn't yet.
Everything below is grounded in our internal end-to-end security certification — a multi-agent adversarial review (static source + SQL, traced to exact code paths) covering cross-tenant isolation, the money invariant, persona isolation, and audit integrity. All four passed; every high and medium finding was remediated before pilot.
Every business is its own tenant behind Postgres row-level security. Policies are scoped to the acting user's capabilities, and privileged database functions re-check org membership server-side before touching a row. Direct ledger writes are revoked from application users entirely. One company can never read another's data — even with a stolen API key and a valid login, the database itself refuses.
What a user can do is a data-driven capability set resolved from their verified session — per organization, per role, per persona. The active persona is derived from the route on the server, never from a client-sent header, and owner status grants no bypass. A recruiter gets exactly recruiting capabilities; a payroll role gets money-settlement capabilities and is blocked from relationships and immigration.
Money state lives in a double-entry, append-only ledger with hard idempotency — postings cannot be double-spent, edited, or silently drift. Every consequential action is also written to a tamper-evident, hash-chained audit log whose appends are serialized, so the chain cannot fork even under concurrent writes.
Gyani, our AI orchestrator, only ever proposes. Two deterministic layers dispose: row-level security keyed to the user, and a server-side capability broker. The agent executes under the user's own database-scoped session, so nothing said in a conversation — including injected instructions inside transcripts or documents — can expand its authority, pick its tools, or redirect a payment. Four action classes (money, identity, adverse, external) are clamped to always require human confirmation by a literal code constant that no setting, policy, or prompt can relax; a missing policy fails to the strictest setting, and the money gate fails closed.
Account creation records a timestamped attestation that the person is authorized to bind the company. Verification itself is a document-upload KYB flow reviewed by a human on the PoPayOne side — and a database-level guard ensures verification status can only change through that review: a business cannot self-approve, even by calling the API directly.
Every money mutation reachable from the app flows through a privileged database function that re-checks the capability and consumes a single-use confirmation bound to the exact resource. The autonomy gate — one atomic transaction that both decides and decrements the usage budget — can never return “auto” for money, and disbursements above the floor require a second human approver.
We're in an early-access pilot on simulated money rails. We'd rather tell you precisely where the line is than round up.
| Control | Status | Detail |
|---|---|---|
| Per-tenant isolation (Postgres row-level security) | Enforced now | Capability-scoped RLS policies on every table; privileged RPCs re-check membership server-side. |
| Capability checks on every action | Enforced now | Server and database both verify the acting user's capability set; no client value is trusted. |
| Single-use, resource-bound money confirmations | Enforced now | Each money action needs its own confirmation nonce, bound to the exact resource and consumed on use. |
| Dual-approver on large disbursements | Enforced now | Disbursements above the floor require a second approver before execution. |
| Double-entry, append-only ledger | Enforced now | Hard-idempotent postings; no double-spend or drift. |
| Hash-chained, tamper-evident audit log | Enforced now | Appends are serialized so the chain cannot fork under concurrency. |
| Business verification (KYB) with human review | Enforced now | Document upload reviewed by PoPayOne; a database trigger blocks self-verification even via direct API access. |
| Money rails | Pilot mode | Funding is in early access. The pilot runs entirely on simulated bank and insurer partners — no real funds move. Real-money rails require licensing / a sponsor bank. |
| MFA step-up on money actions | Pilot mode | Deferred during the simulated-funds pilot; enforced in real-money mode. Capability checks, single-use resource-bound confirmations, dual-approver, and the hash-chained ledger are enforced now. |
| SOC 2 | On the roadmap | Built to SOC 2 controls; certification is on the roadmap ahead of real-money operation. We do not claim SOC 2 certification today. |
| Third-party penetration test | On the roadmap | Scheduled as a gate before real money, alongside licensing and real bank / insurer rails. |
The funding marketplace is early access / waitlist. All pilot funding flows — advances, disbursements, insurance, collections — run on simulated bank and insurer partners; no real funds move. Real-money operation is gated on money-transmitter licensing or a sponsor bank, real rails, a third-party penetration test, and MFA step-up enforcement.
We welcome good-faith security research. Our machine-readable disclosure policy lives at /.well-known/security.txt.
A dedicated, monitored security mailbox is being set up. Until it's live, report vulnerabilities through the PoPayOne contact you were onboarded with, marked SECURITY — we'll acknowledge, investigate, and keep you updated through remediation.
We will not pursue or support legal action against researchers who, in good faith:
Research consistent with this policy is considered authorized. Note the pilot runs on simulated funds — there is no real money to move, but the same rules apply.
Ask during onboarding — or read the product overview and see the guardrails in action.