One platform. Every AI-initiated action submitted to it, evaluated before it executes.
PayReality connects approved business rules and current enterprise facts to action authorization, integrated enforcement, and execution evidence, into one deterministic decision with evidence behind it. Delegating that authority to an autonomous agent or a chain of them is one supported path into this workflow, not the whole of it: every delegation still has to obey one rule, authority may narrow, but must never expand.
This page is the architecture: how the pieces evaluate an intent, together. For the individual products this runtime is built from, and a quick way into any one of them on its own, see Products.
Two inputs, one decision, two layers of evidence
What Runtime Authority evaluates against
Authority Graph
Who holds authority, who it's delegated to, and what constraints apply, modeled from your existing governance documents.
Runtime Policies
Deterministic rules, compiled once from your policy, versioned like code, evaluated against every intent.
Runtime Authority evaluates
The signed intent is evaluated deterministically against the active Runtime Policy set, compiled from your governance documents and Authority Graph review.
What comes out of the decision
Authorization Decision
Approve, reject, or require human review: deterministic, produced before execution.
Capability Authorization
For actions that need it, a short-lived, single-use authorization tied to this exact decision. An external, customer-operated enforcement point verifies and consumes it before the downstream operation proceeds.
Evidence Portal
Every decision becomes signed, searchable evidence: investigated, audited, and exported today.
Authorization Receipt
A signed receipt for every decision, retrievable today. A portable, self-contained artifact is the roadmap beyond that.
Verification
Confirmed independently (by an auditor, insurer, or regulator) without depending on PayReality's live systems.
Authority and policy stay separate because they answer different questions
The Authority Graph answers "who is entitled to delegate what, to whom." Runtime Policies answer "under what conditions is a given action permitted." Runtime Authority doesn't collapse these into one system, because your organization doesn't either: your org chart and your approval matrix are already two different documents, maintained by different people, on different cadences. The runtime respects that separation and evaluates both, together, for every intent.
Runtime Authority is decoupled from both your AI systems and your enterprise systems: it evaluates whatever signed intent an agent sends, regardless of what produced it, and isn't tied to a specific LLM, agent framework, or orchestration platform.
None of this replaces your organization's governance. It evaluates the authority your organization already delegates, at the one moment an AI agent's intent becomes a real action, the same moment that matters whether that agent is assisting, executing, or operating as a standing part of the workforce.
Every delegation PayReality evaluates has to obey one rule: authority may narrow, but must never expand. Today that's tested and revocation-aware for a single delegation, a person to one agent, or one agent to one connected system. Verifying the same rule end to end across a full chain of multiple agents and tools is the direction the architecture is built toward, and the harder problem this platform exists to eventually solve, not a capability already proven in production across a multi-agent chain.
Four surfaces, connected where your use case needs them
This is the full client-facing integration model in one place, instead of pieced together across product and developer pages.
Connect your AI
Agent SDK / Runtime API
Your AI application identifies its Agent and submits authority requests through the PayReality SDK or the Runtime API directly. Registering an Agent establishes its identity; it doesn't by itself grant that Agent any authority. The SDK is a developer interface into PayReality, not a copy of your governance logic: your policy lives, and is evaluated, on PayReality's side.
Establish trusted action context
Trusted Adapter / Trusted Integration
For higher-assurance actions, PayReality doesn't have to rely solely on what your AI says it's doing. A customer-controlled Trusted Adapter, a separate, independently authenticated identity from the Agent, reports the real attempted enterprise operation through an approved Action Mapping, so an Agent's own declared description is never the only evidence of what's actually being asked of your enterprise system. One generic, configuration-driven Adapter template ships today; it's a starting point you configure against your own systems, not a packaged connector for any named vendor.
Supply trusted enterprise context
Trusted Enterprise Facts
Connect the enterprise facts your authority rules depend on: whether a supplier is approved, whether a delegated authority holder is still active, business-unit membership, account status, risk classification. These come from your own approved enterprise sources as authenticated, provenance-aware assertions, not from the AI simply asserting them, and not from PayReality independently confirming the underlying business truth.
Enforce controlled authorization
Capability verification
For actions that need stronger execution control, PayReality can issue a short-lived, single-use Capability Authorization. Your own enforcement point verifies and consumes it before your business system proceeds. PayReality decides and authorizes; your enforcement point is what acts on that authorization, never PayReality itself. A reference Python enforcement component is available to embed at your own checkpoint, not a hosted enforcement service.
Integration patterns, not pricing tiers
Lower-assurance or advisory use cases, where you control the Agent and accept its own submitted context.
Where the real attempted enterprise operation needs an independent, trusted observation path.
Consequential actions that need stronger execution control before your business system proceeds.
You don't need every integration surface for every use case. Start with the minimum assurance your use case requires, and expand as needed.
Built around one authority and evidence contract, not one vendor's runtime
PayReality makes the business-authority decision and issues the constrained authorization; it doesn't perform your business operation itself, and an Allow decision doesn't mean execution happened, it means an authorization was issued. Making that authorization effective at the execution boundary is the job of a compatible Policy Enforcement Point (PEP). PayReality is designed around a vendor-neutral authority and evidence contract, not a single agent runtime or enforcement product: any agent runtime, gateway, or customer-controlled enforcement point that can submit a canonical action, enforce a PayReality authorization, and return an authenticated execution receipt can participate in it.
PayReality's reference PEP
A Python enforcement component you embed directly at your own checkpoint.
Agent-runtime middleware
Enforcement built into the agent runtime itself, wherever your agent framework supports it.
API / MCP gateway
A gateway in front of your APIs or MCP tools that enforces the authorization before a call reaches them.
Customer-controlled proxy
A proxy you operate and control, positioned wherever your architecture needs the check to happen.
Enterprise-system adapter
An adapter built to your workflow requirements, for the specific enterprise system that needs to act on the authorization.
A commercial agent-runtime and enforcement environment is one possible way to enforce a PayReality authorization. PayReality does not replace that environment's identity, sandboxing, technical policy, monitoring, or agent-SRE capabilities; PayReality adds the cross-system organizational-authority decision and authority-lifecycle evidence. PayReality does not depend exclusively on any single agent-runtime or cloud vendor: the same authority contract is intended to work with other runtimes, gateways, and customer-controlled enforcement points.
No specific vendor is named above, because no vendor partnership is currently documented or approved. Each enforcement-point category is an architectural-compatibility path built out according to a customer's actual workflow requirements, not a packaged, generally available connector, and nothing here implies a formal partnership with, or endorsement from, any agent-runtime, cloud, or enterprise-system vendor.
See the full runtime evaluate a real decision
From signed intent to decision to evidence, in one session, against your own governance documents.