Ayion Meru Assure
Evidence pack
Finance operations
Period: September 2026
- Coverage
- 94%
- Controls
- 7
- Exceptions
- 3, all closed
Chain verified
4a17…c9e2 · verifiable without Ayion
Meru Assure
Proof of what your agents did. Whichever vendor built them.
Assure puts business-level controls on every consequential agent action, binds approvals to the exact parameters, reconciles each action against what actually changed, and assembles evidence packs mapped to the frameworks your auditor, your regulator and your insurer work from.
The sample pack is gated: tell us who you are and we send it. It is a worked example on illustrative data, not a real company’s period.
What Assure answers
Four questions your agent estate has to answer.
They are hard to answer today for a structural reason rather than a technical one: each agent platform keeps its own log, none of those logs was written for an auditor, and nobody owns the join between them.
-
What did our agents do, to which records, on whose authority?
Every consequential action carries the agent, the vendor that built it, the operating contract it ran under, the person or system that authorised it, and the exact record and version it touched.
-
Which actions needed a control or an approval, and did they get one?
Controls are evaluated before the action, not reconstructed from logs afterwards. The decision, the control blueprint version and the approver are part of the record.
-
Did what the agent intended actually happen, once, and did anyone correct it?
Assure compares the intended action against the observed change in your system of record, and counts the duplicates, the mismatches and the human corrections.
-
Can we hand an auditor the evidence without running a project?
Evidence packs export as files that read without Ayion. Auditor seats are free and read-only.
One action, end to end
Every consequential action takes the same path.
Whether an Ayion agent, a Microsoft or Salesforce agent, or one you built took it. Propose, check, approve where required, execute, observe, reconcile, record.
See the whole platformA left-to-right flow. An agent proposes an action with typed parameters, which enters a policy check where the controls are evaluated. Three ways out: allowed, which goes straight to execution in the system; approval needed, which goes to an approval bound to the parameters and the record version and then either on to execution or, if declined, to a stopped-and-recorded box; and blocked, which goes straight to that same stopped box. After execution the flow observes the change in the system of record, then reconciles it. Reconciliation either confirms the change happened once, which produces an evidence record, or finds a mismatch, which opens an exception that also produces an evidence record. The stopped box produces one too.
Controls
Business controls, not developer guardrails.
A prompt rule is not a control. A control is a stated limit, evaluated before the action, recorded whichever way it decided, and owned by a named person in your organisation.
Every control writes a record whichever way it decided, including the times it allowed the action.
| Control | What it does | Example |
|---|---|---|
| Threshold | Sets the size, count or value at which an action stops being routine and needs a named person. | Payments up to USD 10,000 proceed and are recorded. Above it, the action waits for the controller. |
| Segregation of duties | Keeps whoever prepared a change away from whoever approves it, with agents and people in one matrix rather than two. | The agent that edited the vendor master cannot approve a payment to that vendor, and neither can the person who asked for the edit. |
| Purpose limitation | Binds an action to the purpose its operating contract declares, so data read for one job cannot drive another. | A support agent may read an order to answer a query. It may not use that same record to raise a refund. |
| Reversibility gate | Holds any action that cannot be undone until a person accepts it, and lets the reversible ones through. | Drafting a credit note is reversible and proceeds. Issuing it is not, and waits. |
| Budget and rate | Caps spend, volume and frequency per agent, per contract and per period, including retries. | A procurement agent gets 200 supplier emails a day and a monthly model budget. Either limit stops the run and opens an exception. |
| Kill switch | Stops one agent, one pack or every agent at once, without a deploy and without waiting for an engineer. | An incident in billing stops the finance pack while customer operations keeps running. |
| Bound approval | Ties an approval to the exact parameters and record versions it was given, so it cannot be reused for a different action. | Approve USD 12,400 to Acme Supplies against vendor record v7, and that is what the approval covers. Anything else needs a new one. |
Approvals bound to the facts
An approval covers exactly what was approved.
Change the amount, the vendor or the record version, and the approval expires. It does not stretch to cover the new action, and nobody has to notice that it should not have.
- The approver sees the parameters, not a summary of them: the vendor, the amount, the invoice, the record version, the control that asked for the approval and the agent that requested it.
- The approval is sealed to a hash of those parameters. A different hash is a different action.
- Approvals arrive where the approver already works — Slack, Teams, email or mobile — and the channel does not change what is recorded.
- The evidence record it produced is written at the same moment, and carries the approver, the timestamp and the bound hash.
Approve payment · Finance operations
Slack · #finance-approvals Waiting on you
Approve payment
- Vendor
- Acme Supplies record v7
- Amount
- USD 12,400
- Invoice
- INV-20418
- Requested by
- Finance Ops Agent operating contract v3
- Control
- Threshold above USD 10,000
Approve Decline
Approval covers exactly these values.
Evidence record Reconciled once
- identity
- agent:finance-ops · principal:ap-clerk · vendor:ayion
- action
- bill.pay · target:netsuite/bill/20418
- policy
- blueprint v12 · threshold · approval required
- approval
- r.mehta · 14:22:07Z · bound 9f3c…a71d
- execution
- ok · 1 attempt · 2.4s · USD 0.011
- observation
- netsuite bill 20418 · v7 to v8
chain 4a17…c9e2 · verifiable without Ayion
Reconciliation
A successful tool call is not proof the work happened.
The call returns 200 and the agent moves on. Assure goes and looks at the system of record, compares what changed against what was intended, and writes down which of six things it found.
Every outcome is written to the ledger, including the ones that say nothing happened.
| Outcome | What the system of record shows | What Assure does |
|---|---|---|
| Confirmed once | One change, matching the parameters that were approved. | Closes the action and seals the evidence record. |
| Not executed | The call succeeded. Nothing changed. | Opens an exception, names the action as unperformed, and does not retry on its own. |
| Executed twice | Two changes from one intended action, usually a retry that was not idempotent. | Opens an exception, marks the duplicate for reversal, and keeps both observations in the record. |
| Different parameters | The change happened with an amount, a date or a target that is not the one approved. | Expires the approval, opens an exception, and records the intended and the observed values side by side. |
| Corrected by a person | Someone changed the result afterwards. | Records who, when and what changed, and counts it towards the correction rate the pack reports. |
| Unobservable | The system exposes no change feed for this field, so nothing can be compared. | Declares the gap in the evidence pack rather than reporting coverage it does not have. |
Declared gaps are the reason a coverage figure on an Assure pack means something. A pack that cannot see a field says so on its own cover.
Evidence packs
Mapped to the frameworks your reviewers already use.
A pack assembles the control descriptions, the population of actions in scope, the approvals sampled, the exceptions and their closure, and a completeness statement for the period. Mapped to the framework, not certified against it: no auditor has been handed an Ayion pack yet, so none has accepted one.
Evidence exports read without Ayion. Auditor seats are free.
-
SOX and ICFR
Control descriptions, the population of agent actions in scope, approvals sampled, exceptions and their closure, and a period completeness statement.
How the mapping works -
ISO/IEC 42001
Operating contracts as documented purpose and scope, control blueprint versions, the human oversight record and the incident log. An alignment, not a certificate.
How the mapping works -
NIST AI RMF
Map, measure and manage, in the record: what each agent is for, which controls applied, what was measured, and what was done about the exceptions.
How the mapping works -
EU AI Act
The logging, human oversight and record-keeping obligations that fall on a deployer: automatic logs per action, the person who oversaw it, and retention of both.
How the mapping works -
Insurer questionnaire
What an underwriter asks at renewal: which agents can act, what they may spend, what stops them, how often a person corrects them, and what happened when a control fired.
How the mapping works -
Board report
The same period, four numbers: actions taken, controls fired, exceptions opened and closed, and the coverage the pack can actually claim.
Evidence pack · Finance operations · September 2026
Control matrix
Page 4 of 18| Control | In scope | Breaches | Sampled | Result |
|---|---|---|---|---|
| Payment threshold | 1,284 | 0 | 40 of 212 | Pass |
| Vendor bank change | 18 | 0 | 18 of 18 | Pass |
| Segregation of duties | 1,284 | 2 | 40 of 212 | Exceptions closed |
| Journal approval | 96 | 1 | 24 of 96 | Exception closed |
| Duplicate payment | 1,284 | 0 | All | Pass |
Period completeness. 94% of consequential actions in the period were observed through the MCP proxy and NetSuite change feeds. The remaining 6% ran through a support channel with no change feed, and are declared as a gap rather than assumed to have succeeded.
Illustration. The figures are a worked example, not a customer’s period.
Works with the agents you already run
Assure records the doer. It does not have to be the doer.
Capture is built to reach the agent platforms a mid-market company already has, without asking you to move any of them. Which of these is live on the day you start is a question we answer on the call, in writing, rather than on this page.
Planned or in development
- Microsoft Copilot Studio and Agent 365
- Salesforce Agentforce
- ServiceNow
- ERP-native agents
- Support-platform agents
- Agents built on OpenAI or Anthropic
No third-party logos, and no claim of a partnership. These are the platforms capture is being built for.
-
MCP policy proxy
Assure sits in front of the tool call. Controls are evaluated per argument, inline, and can be set to fail closed.
-
Telemetry ingestion
Traces that already follow the OpenTelemetry conventions for generative AI are read as they are, with no change to the agent.
-
Platform connectors
Per-vendor connectors read the action logs each agent platform already keeps, and normalise them into one record shape.
-
System-of-record change feeds
Read-only, signed and replay-safe feeds from the ERP, CRM or billing system supply the field-level diffs reconciliation compares against.
Independence
The doer does not keep the record.
One company selling both the agents and the proof is a conflict of interest unless the proof is built so that the agents cannot touch it. That is a design constraint, and this is what it is.
The independence rule
Assure records what any agent did, including agents from other vendors, and Run cannot alter the ledger. Keys are customer-held and records are verifiable by a third party without Ayion. Assure can be bought without Run. This is what lets one company offer both without asking auditors to trust the doer’s own record.
Assure is sold and priced on its own, so Meru Run is a choice you make separately. The full posture, including everything we have not built yet, is on the Trust and security page.
A left-to-right diagram. On the left, a box labelled Doers holds two items: Meru Run agents, and third-party agents from Microsoft, Salesforce or a customer’s own build. Arrows from both, labelled "actions captured", run to a cylinder on the right: the Assure evidence ledger, append-only and hash-chained. A separate box, customer-held keys, feeds into the same ledger from below. One arrow leaves the ledger, labelled "verify without Ayion", and reaches a box holding auditor, regulator and insurer. No arrow runs from either doer into the ledger directly.
Bring the control question you think we cannot answer.
A demo on our worked example, then a ninety-day pilot on your systems, your agents and your work. You keep everything it produces.