An AI finance investigation is only as trustworthy as the data it reads and the trail it leaves. A step-by-step look at a synthetic iGaming reconciliation where a payout changed after signing was rejected at the boundary.
· Article
AI workflows are moving into finance. A graph of model calls and tools reads a batch of records, reconciles it, explains the result in plain language, and saves a report a human will act on. That is genuinely useful, and it raises a question most stacks cannot answer well: how do you know the data the model read is the data that was actually ingested, and how do you know who wrote the conclusion?
A bearer token proves a caller had a credential. It says nothing about whether the request body was changed between the moment it was produced and the moment it arrived. If a payout figure is altered in transit, in a queue, or by a compromised step, the API accepts it, the model reasons over it, and the report looks perfectly credible.
This post walks through a recorded demo that tests exactly that, and explains what the boundary checked, why the altered request was rejected, and what the audit trail shows for every step.
A tampered record in a traditional system usually surfaces as a number that does not add up. With a model in the loop, it surfaces as a fluent, well-argued explanation built on the wrong number. The more convincing the model, the less likely anyone checks the input.
That puts the burden on the data path, not the model. The useful guarantees are simple to state: what was ingested is exactly what the producer signed; every read and write is attributable to a named workload; and the record of those decisions does not depend on the AI system's own logs.
The scenario is synthetic. Harborline Gaming is a fictional iGaming operator, and it is built to show fit, not a customer deployment. A game provider's statement covers four accepted rounds: $350 in stakes, $260 in payouts, and a 5% fee. One $10 adjustment on the statement has no linked round.
Finance runs an investigation built in LangGraph. Trustplane sits in front of the business service that holds the batch and the reports, and each workload calls through it with its own identity.
The graph reads the protected batch and calculates the payable: $72.50, which is $10 above what the statement shows. The recording shows the actual LangGraph nodes from that run finishing one by one, as the model explains the difference and the report is saved.
The saved case cites both the statement and the unlinked adjustment. The model's explanation is checked against source line IDs, so every claim in the report points to a specific record rather than to the model's memory.
Finance is advised to ask the provider for supporting documentation. The original batch stays intact; the investigation reads it, it does not rewrite it.
The batch the graph read did not appear from nowhere. It was ingested earlier by a separate workload, with its own identity, making its own signed request. Trustplane control shows that request was verified and the business service returned HTTP 201.
That separation matters. The workload that writes source data is not the workload that analyses it, and neither holds a shared key to the other's routes. Each is admitted for its own operation only.
In a test run during the recording, a payout was changed after the request had been signed. Everything else was the same: the same workload, the same route, a valid signature over the original content.
Trustplane rejected the changed request. Control's audit shows the rejection and confirms the business service was never reached. The altered payout never entered the batch, so the model never had the chance to reason over it.
Every request through Trustplane carries a short-lived passport bound to the caller, the action, the audience, the route, and a moment in time, and the request is signed over its content. The boundary verifies all of it locally, with no hosted call in the request path. See how the boundary works for the full sequence.
Change one byte of the body after signing and the proof no longer matches the request. Every other check may still pass, the caller is real and the route is allowed, but one failed check is enough to refuse.
Which workloads may ingest, read, and write reports is declared as trust anchor policy rather than handed out as credentials, so the ingestion workload and the analyst workload are distinct identities with distinct permissions.
Request-level view
Allow
Approved action, scope, brand, and workload all match.
Refuse
Wrong route, tenant, scope, or replayed proof.
one request · one verdict · one audit record
Saving the report is not a side effect of the investigation; it is a separate authorized request. Control links it to the analyst workload, shows the route it called, and records HTTP 201 from the business service.
The same request ID appears in the LangGraph panel, so the AI workflow's view and the boundary's record can be matched line for line. Trustplane's decision and the upstream result are recorded as distinct facts: the boundary allowed the request, and separately, the service succeeded.
Back in finance, the evidence-linked report shows $72.50 expected and a $10 shortfall. That is a finding to raise with the provider, not a verdict.
The demo is careful on this point, and so should any deployment be: the model did not prove misconduct. What Trustplane adds is a visible access and integrity trail, so the operator can review the provider's figures knowing the data underneath was not altered and every step is attributable.
For finance and risk teams, AI findings come with provenance: which records, ingested by which workload, verified when, and written by whom. That is what makes an AI-generated report defensible in a dispute or an audit.
For security teams, request integrity is enforced at the boundary for every workflow, not left to each API. A compromised step cannot quietly edit data on its way in.
For platform teams, the LangGraph workflow is not rebuilt around a security product. Each workload gets its own proven identity, and there are no shared keys to rotate between the ingestion job, the graph, and the report store.
The same pattern fits any AI workflow that reads sensitive data and writes conclusions: payment reconciliation, bonus abuse review, responsible-gaming checks, and fraud triage. It extends the themes in our use cases to agents built with LangGraph or any other framework.
If you run AI agents over financial or player data and need proof of what they read and wrote, book a custom demo.
Every request proves itself — no keys, anywhere.
Put the boundary in front of one API and measure it yourself.