Product demonstrations
Follow an agent request.
Understand the controls.
AAES is the governance layer for enterprise AI agents. It checks scoped permissions, required approvals and configured spending budgets for actions routed through AAES, then records the decisions.
Start with one invoice workflow. Then inspect the control that matters to your team—and the boundary of what it establishes.
Video recordings will be added to these written walkthroughs.
00 / The complete workflow
From invoice to accountable decision
Let an agent read what it needs. Require a person to authorize the irreversible request. Keep the permission, the action and the evidence distinct.
Synthetic example · Proposed evaluation sequence, not a real customer or a live invoice-provider demonstration.
- ActionAn identified agent requests work
A scoped read or a specific payment request, tied to a bounded task.
- DecisionAAES checks whether it may proceed
Permissions, required approval and evaluated spending determine authorization.
- RecordInspect the decision and reported effect
A grant is not execution. Downstream confirmation is separate evidence.
Establish the agent and its human manager
Create an invoice-processing agent in Agent Studio using your model access, or connect an existing agent. Assign an accountable human manager before routing the task through AAES. Either entry point leads to the same question: what may this identified agent do?
Inspect The agent identity, its accountable human manager and the path its requests will use.
Register two narrow capabilities
For this example, register read-invoice for the designated synthetic invoice and a separate payment-request capability restricted to the test payee. Register the payment action as irreversible. Reading an invoice must not confer permission to request a payment or access unrelated invoices.
Inspect Separate scopes for reading and payment requests, plus the irreversible classification.
Start a task with explicit limits
Use synthetic invoice INV-DEMO-01 for USD 120. Set a proposed task spending limit of USD 150 and a deadline 30 minutes after task start. Define how the payment-request amount will be evaluated against that limit. These are test inputs, not customer results or a payment settlement balance.
Inspect The task identity, deadline, configured budget and amount-evaluation basis.
Allow the scoped read
Route a read request for INV-DEMO-01 through AAES. With the configured scope satisfied and no additional approval required, expect a permit decision. Use the authorized path to perform the read separately; a permission decision is not evidence that the invoice was retrieved.
Inspect A permit for this read, followed by whatever evidence the test system supplies about its result.
Pause the irreversible payment request for review
Request the separately registered irreversible payment action for USD 120. An authorized human must review the exact request, including its invoice, payee, amount, currency and task context. While approval is pending, the request cannot proceed on the enforced path. Approval expires and cannot be supplied by the requesting agent; changing the request requires a new approval.
Inspect The pending request, reviewer authority, exact approved request and approval expiry.
Permit controlled continuation—not a claimed payment
After approval, the request still has to satisfy the applicable scope and spending checks. The /v1/action endpoint authorizes and mints a grant; it does not execute the downstream action. Brokered execution is separate. Continue only through the configured test path and seek downstream confirmation rather than treating approval or dispatch as payment success.
Inspect Authorization separately from execution evidence. Approval itself does not change an enterprise bank balance.
Inspect the task’s decisions and effects
Follow the task through the read, approval and payment-request records. Distinguish a refusal, a permit, a dispatched request and a confirmed downstream effect. If a test system times out or provides no confirmation, preserve that uncertainty rather than inferring that a payment happened—or that nothing happened.
Inspect What AAES decided, what was sent, what was confirmed and what remains unknown.
Retain an export and check its integrity
Export the retained records and verify them offline against a supplied, separately trusted public key. This checks retained export integrity, not event truth, complete capture or downstream execution. The public synthetic sample in the verification chapter lets you try that integrity check now; it is not an export of this proposed invoice workflow.
Inspect The retained export, the reason to trust its verification key and the limits of a passing result.
Use the evaluation to test both allowed and refused requests on your configured path—not to infer universal safety or coverage. Read the evaluation scope
Inspect one control
Five focused walkthroughs
Each chapter isolates a decision to test, the evidence to inspect and the conclusion you can reasonably draw.
01 / Permissions
Give the agent less room to act.
Begin with read access limited to the designated synthetic invoice. Ask the agent to read all invoices in another business unit. That broader request should be denied because it exceeds the assigned scope—even though it is still a read.
Submit a smaller request for INV-DEMO-01 within the allowed scope. Expect a permit when the other configured checks are satisfied. Compare the two decisions: the agent’s identity is unchanged; the requested scope is different.
What to establish: The configured permission boundary distinguishes the refused request from the narrower allowed one. It does not stop calls made with bypass credentials.
Read the access-control guide02 / Human approvals
Approve this request.
Not a blank cheque.
Follow the irreversible payment request from pending, through human review, to an approval or refusal. The authorized reviewer sees the exact request—not just a general instruction to “process invoices.” An action registered as irreversible requires an authorized human’s approval on enforced paths.
Approve the USD 120 request, then propose a different payee or amount. The changed request needs a new approval. An expired approval is not valid, and the requesting agent cannot provide its own approval.
An action approval covers an exact request and expires. An access approval instead grants scoped permission for a limited lifetime. Do not treat either as unrestricted authority.
What to establish: Pending, refused, changed and expired requests cannot use the original approval to proceed on the enforced path. Approval enables controlled continuation; it does not confirm downstream execution.
Read the human-approval guide03 / Spending limits
Test the amount.
Respect the boundary.
Use the example’s USD 150 task limit. Configure the first request to evaluate at USD 120 and inspect its reservation. While that reservation is active, a further request evaluated at USD 40 would exceed the task limit; expect a spending refusal.
Inspect the configured task amount, the amount AAES evaluates, existing reservations and the decision reason. Keep the other required permissions and approvals satisfied so the test isolates the spending check.
What to establish: AAES checks evaluated and reserved amounts against configured budgets. This is not payment settlement, a bank-balance check or a guarantee that every external cost is captured or capped.
Read the spending-controls guide04 / Decision & effect records
Permission is not proof of effect.
Inspect one task’s retained records in sequence. Identify the agent, requested scope, relevant approval and spending decision, then distinguish the authorization from any downstream dispatch and reported effect.
- Authorized
- AAES permitted the request. A grant alone does not show that a call was made.
- Dispatched
- A call was sent through the execution path. Dispatch alone does not confirm the intended result.
- Confirmed or uncertain
- Inspect the reported downstream evidence. Without sufficient confirmation, preserve an unknown outcome.
What to establish: A reviewer can distinguish the recorded decision from the reported effect and see remaining uncertainty. Records do not prove complete capture of activity outside the governed path.
Read the trust model05 / Offline verification
Check the retained evidence yourself.
Available now: a public synthetic sample, not customer evidence.
Use the Apache-2.0 aaesverify v0.2.0 verifier with the sample export and supplied sample public key. Get the platform binaries and setup instructions from the public sample pack.
- Check the unchanged export. With the verifier installed and both sample files saved locally, run the command below. Expected output includes
result: PASS.
aaesverify --export sample-export.jsonl --pubkey sample-pubkey.txt- Test the specified edit. Follow the sample-pack instructions for tamper-demo.sh. It verifies the clean file, flips one byte inside a sealed record in a copy, then requires refusal. Expected on that edited copy:
chain: FAILED,merkle root: FAILEDand exit 1. The head signature can remain valid because the signed head was not changed. - Interpret the result narrowly. After retaining the files and verifier, no AAES service, vendor account or network call is involved in verification. A pass checks retained export integrity against the supplied key—not event truth, complete capture, enforcement or downstream execution.
The key is a trust assumption. The sample key is supplied separately from the export, but both use AAES-controlled distribution. The supplied public key is demonstration material and the sample has no independent witness. For your deployment, establish trust in the public key through a separate channel you control. A party controlling the signing key can create a different, internally consistent history.
Your workflow / Your boundaries
Make the next walkthrough yours.
Bring one workflow, the systems it touches, who should approve, and the limits you want to test.
We can discuss the governed path, the allowed and refused requests to test, and the evidence your team needs to review.