An agent can be real and still lack authority for this action.

Verified Infrastructure checks a proposed consequential action against current, bounded authority independently of the AI agent. It denies requests outside those limits and produces evidence for an authorised exact action that a recipient can check.

Start the fictional Purchase Order walkthrough →

THE PROBLEM

A login proves something about an actor. An AI-generated instruction says what it wants to do. Neither, by itself, proves that this actor may issue this purchase order, to this recipient, for this amount, now.

WHO IT IS FOR

Operations, procurement, risk and technology teams evaluating one bounded agent-to-business workflow.

CURRENT BOUNDARY

What it can genuinely support today.

CURRENTLY SUPPORTED OR POSITIONED

Actor and capability: identify which agent is acting and which class of action it may request.
Exact action: check the recorded recipient, amount, reference and other relevant terms rather than a broad instruction.
Limits and delegation: compare the request with the human or organisational authority granted, its scope and ceiling.
Revocation and currentness: authority must still be valid when the exact request is checked.
Decision: deny an out-of-bounds request or authorise only the exact recorded action.
Recipient verification: let the recipient check the evidence independently. Changed details are invalid; already-consumed evidence is denied in the fictional Purchase Order journey.

WHAT THIS PAGE DOES NOT CLAIM

The public demonstration uses fictional organisations and inert actions. It does not issue a real purchase order, move money, send messages or change production authority.
Verification does not establish that every underlying real-world statement is true or legally effective.
Authorisation is not proof that an action was delivered, accepted or executed, and it is not a blanket guarantee of safety.
Purchase orders, contracts, payments, job offers, sensitive access and system changes are demonstration scenarios; live integrations and a production pilot require separate review.

Technical evidence and demonstration status

The working showcase separates the agent's proposed action, an independent authority decision, the issued exact-action evidence and recipient-side verification.
The Purchase Order scenario visibly demonstrates a £10,000 ceiling, £38,000 denial, exact £8,000 authorisation, £39,000 tamper rejection and replay denial.
This public website is an explanation, not an API endpoint or a live execution rail. Pilot design and deployment status must be confirmed for each proposed integration.

BUYER QUESTIONS

The checks behind the claim.

Is an authenticated AI agent authorised to place a purchase order?

Authentication identifies the agent. It does not establish that the agent may place this order for this amount, recipient and set of terms. The proposed action still needs a separate check against current delegated authority.

What happens when an agent exceeds its spending limit?

The fictional Purchase Order walkthrough denies a £38,000 request against a £10,000 limit. It separately authorises an £8,000 request only for the exact action recorded in that decision.

What can the recipient verify?

In the demonstration, the recipient checks that the presented evidence matches the authorised exact action. A changed £39,000 amount is invalid and reuse of consumed evidence is denied. Verification does not prove delivery, payment or the truth of every underlying statement.

Can this run a real procurement workflow today?

The public walkthrough is fictional and inert. An interactive authority showcase is available through controlled access. Any live procurement integration or production pilot needs its own design, security and release review.