Was the action still authorized
when it actually happened?
An AI agent can request a payment, refund, claim decision, or supplier change. The approval, business rules, and current facts may live in different systems. PayReality connects those records to the exact action, checks the applicable authority before a connected system executes it, and relates the destination's reported outcome back to what was approved.
The demo follows an AI agent attempting a real enterprise action, in a live, simulated environment.
An approval has a history. An action has an outcome.
A payment may be approved on Monday and sent on Thursday. Between those moments, its amount, destination, supporting facts, or the approver's authority can change. Your existing systems may already detect some changes. The operational question is whether they can show, for this exact action, which authority applied at execution and what the destination actually reported.
One connected workflow, not five separate tools.
AI proposes an interpretation; an authorized human approves it before it can govern anything, a different event from approving one action later. An Allow decision is not execution: your integrated enforcement point makes it effective, and reconciliation depends on an authenticated report coming back from it. Delegation continuity and policy change management support this workflow without becoming a separate story of their own.
Follow one payment from approval to outcome.
- 1
A director approves a specific supplier payment under a recorded limit and policy version.
- 2
The payment waits. A relevant fact or authority changes. The customer's agreed rules determine whether the pending payment needs a new approval.
- 3
A connected enforcement point checks the action before any new execution. If it is dispatched and the bank's response is missing, the outcome remains unknown until reliable destination evidence resolves it. Investigating the original operation does not itself authorize another payment.
- 4
The record retains the original approval, subsequent changes, execution decision, and destination-reported result or unresolved state.
This walkthrough illustrates the intended workflow across one payment, in a simulated environment. Which parts are implemented, which require your own integration, and which are still planned is detailed below.
What's protected, what isn't, and how you'd find out.
Take a different, equally illustrative example: a person approves an order for 120 units from supplier A, charged to buyer account B, delivered to location X. Before it executes, someone tries to change a detail. Here's exactly what that does and doesn't catch.
What stays fixed
A Capability checks exactly the fields your integration contract declares material for this order. Supplier, quantity, buyer account, and delivery destination are illustrative examples, not a universal list. A field that isn't declared and submitted can't be noticed if it changes.
Where execution is stopped
Your own enforcement point verifies and consumes the Capability on the real write path before the order is placed, the only path PayReality actually gates. Any other route into the same system has to be closed on your side; PayReality can't secure a path it isn't wired into.
What's observed
An agent's signed intent is its own account of what it's asking to do. Where a Trusted Adapter is configured, its report of the attempted operation is a second, independently authenticated observation, closer to the destination, but still not the destination's own record.
What happened
A decision records what was authorized. A consumed Capability records that the authorization was invoked, once. An execution receipt records what an authenticated integration reported. Reconciliation compares that report against what was authorized, confirming internal consistency, not that the order was placed exactly as reported.
What changes, or stays unknown
PayReality re-checks the agent, organization, and integration are still active when a Capability is consumed, not only when it was issued. It doesn't yet watch a pending Capability for an authority change before someone tries to use it, or resolve what happened when a receipt never arrives: both are directions we're testing, not shipped controls. A missing receipt means the outcome is unknown, not that the order didn't happen.
What's implemented, what needs your integration, and what's ahead.
Today's implementation covers policy interpretation and human review, live evaluation of one delegation, and action-bound authorization. Trusted enterprise context, effective enforcement, and reconciliation depend on customer integration. Discovery of affected pending actions after an authority change, and recovery of ambiguous post-dispatch outcomes, are planned and to be tested, not production-ready claims.
AI proposes a structured interpretation; deterministic checks and human review gate activation.
A single delegation is evaluated live and denied the moment it's revoked or expired.
Facts and independently-reported actions come from sources you configure, not a packaged connector.
A short-lived, single-use authorization is tied to the exact reviewed request.
PayReality issues the authorization; your own integrated enforcement point makes it effective.
Reconciliation logic is implemented; it depends on your destination system reporting back.
Today's narrowing check covers one delegation hop, not a full multi-agent chain end to end.
Verification without depending on PayReality's own systems is on the roadmap, not shipped.
Detecting that a change to an approver's own authority after approval should force revalidation before execution is a direction we're investigating, not a built capability.
Resolving what actually happened when an execution report never arrives, or is ambiguous, is a direction we're investigating, not a built capability.
Statuses reflect evidence gathered in prior technical audits of this platform, not claims made because code exists or a test suite passes. A pilot re-checks the ones that matter for your specific workflow.
A layer, not a replacement.
PayReality integrates with the identity, business, policy, and execution systems you already run. Setting up an integration defines which sources supply the facts a decision needs, which system stays the owner of that decision, where enforcement actually happens, and which execution reports are available to reconcile against.
No packaged connector for a specific named vendor ships today, and no vendor partnership is documented. Each integration is configured against your own systems, not assumed to fit every stack.
Test the whole journey
on one workflow.
We select one consequential action with its owner, agree how authority changes should affect it, and compare PayReality with the controls you already use. We measure which records are available, what each approach can answer, the effort to connect the systems, and the cost of manual investigation.
At the end, an accountable owner decides on a scoped, priced next step, declines with a reason, or defers with a named condition and date.
Also exploring: a discovery programme for procurement AI vendors