Security

PayReality is early-stage. This page describes what's actually implemented today, in both the website and the platform, and states plainly where the current limits are. We don't hold any third-party security certification (SOC 2, ISO 27001, or otherwise), and we won't imply that we do.

Encryption in transit

This website, the PayReality platform, and its API are all served over TLS. Certificates are issued and managed by our hosting providers; nothing is served over plain HTTP in production.

Signed intents

Every action an AI agent submits to the platform is signed with an Ed25519 key generated on the agent's own side. The private key is never transmitted to us; only the public key is registered. We verify the signature against that registered key before evaluating the request. A timestamp window plus a uniqueness constraint on each request's nonce prevent a captured request from being replayed later.

Certificate rotation

An agent's signing certificate can be rotated or revoked at any time. Rotating immediately invalidates the old certificate for new requests. Because we never hold an agent's private key, a rotation generates a genuinely new keypair on the agent's side. We can flag an agent for rotation, but can't rotate its key for it. Decisions and Evidence already recorded stay valid and explainable against whichever certificate was actually active when they were created.

Signed evidence

Every Decision and its Evidence record is independently signed, separately from the intent that produced it. Each signature is checked against the specific signing key that was active at the time it was made, not just whichever key happens to be active now, so rotating the evidence signing key doesn't invalidate verification of anything signed under a previous one.

Authorization freshness

Where a decision issues a Capability Authorization, PayReality rechecks relevant live organizational state immediately before that Capability is consumed, not only at the moment it was issued: the originating Agent, the Organization, and, where applicable, the Trusted Integration identity and the Runtime Connection it depends on. If any of those is no longer active, consumption fails closed, and the Capability is not marked as used by the failed attempt. A later attempt is checked against whatever state exists at that time; if the underlying identity has since been restored, it can succeed.

Execution receipts and reconciliation

PayReality records what it authorized, separately from whatever happens next in your own systems. Where a separately authenticated destination system or a trusted execution adapter supplies an execution receipt afterward, PayReality verifies that receipt's linkage to the original decision and reconciles the reported execution against the action that was actually authorized: MATCHED, MISMATCHED, EXECUTION_FAILED, PARTIAL, RECEIPT_MISSING, or INDETERMINATE. A cryptographically authenticated receipt proves what the trusted source reported. It does not independently prove that the underlying business system or real-world event was truthful, and we don't claim otherwise.

Authority Graph liveness

A policy compiled from the Authority Graph stays grounded in the specific delegation relationship it was built from, not a one-time review of it. That delegation has to still exist and be active at the moment a policy is evaluated, not only at the moment it was reviewed. If the underlying delegation is revoked or expires, the policy stops granting that authority automatically, without requiring anyone to go and edit the policy by hand.

Tenant-scoped verification

Verifying a Capability requires authenticating as a specific organization. A verifier authenticated for one organization cannot consume a Capability belonging to a different one. The platform's shared operator credential can still be used to verify a Capability, but only when it also names the specific organization it's acting for.

Access control

The platform enforces role-based permissions server-side (not just hidden in the interface), across six roles (Owner, Governance Administrator, Agent Administrator, Reviewer, Auditor, Executive), each with a fixed set of allowed actions.

Current limitations

We'd rather state these plainly than let you assume otherwise:

• At this stage, a single shared operator credential can act with full administrative authority across an organization, on top of the role-based permissions described above. It is not yet a scoped, per-user credential. Narrowing this is ongoing work.
• We don't currently implement encryption at rest beyond whatever our database hosting provider applies by default. There's no PayReality-specific at-rest encryption layer today.
• We don't hold SOC 2, ISO 27001, or any other formal third-party security certification.
• There's a narrow window between the authorization-freshness check described above and the database operation that actually marks a Capability consumed. We haven't closed it, and we're not claiming zero race window here.
• A customer can currently declare a Runtime Connection's enforcement assurance as ADVISORY or CAPABILITY_REQUIRED. We don't yet implement independent verification or registration of an external enforcement point (sometimes described as VERIFIED or registered-external-PEP assurance): that remains a customer's own declared claim about their own infrastructure, not something PayReality checks.
• AI can propose structured authority from uploaded governance documents, but it cannot grant authority or activate a policy on its own; that still requires human review and a separate accountable approver for high-risk changes. We've validated extraction accuracy only in controlled synthetic testing so far, not yet against a broad set of real enterprise documents.

Reporting a security issue

If you find a security issue, please tell us directly at sean@aisecurewatch.com rather than disclosing it publicly. We'll respond directly.