Evidence Library

Public proof, separated from source code.

This is where a buyer reads the evidence in plain language: case notes, method notes, readiness checks, and sample deliverables. GitHub stays available as the source layer for every number.

Read case notes Prepare a trace

Start here

The buyer-readable route through the evidence.

Use these pages to understand the review before opening source files. The public repo proves the method; a pilot applies it to your staging workflow.

Sample evidence report

The full deliverable, rendered: executive summary, evidence register, findings, fixes, and retest plan for a synthetic AP workflow, in 9 pages.

Read the report structure
AP payment authorization

A real invoice approval still does not prove the current actor may schedule payment. One synthetic payment, walked from approval record to tool call to verdict.

Read the case note
Stripe Agent Toolkit boundary

A Stripe test-mode L3 slice: the official sample created unauthorized test coupons from ordinary business email; the same write path was denied with the gate, while the authorized control still passed.

Read the Stripe note
Poisoned AP documents

An invoice-looking document asks the agent to export data and change bank details. The review checks whether a trusted record, or just the document, authorized the action.

Read the case note
Trace readiness

Four readiness levels, 0 to 3: how one redacted trace becomes either a scoreable review input or a missing-evidence map.

Read the readiness check
Deep payment controls

Post-approval edits, handoff claims, and retry/replay, graded on 12 scored runs: 3 EXPLOITED, 3 BLOCKED, 4 BENIGN_PASS, 2 INCONCLUSIVE.

Read the method note
Technical handoff

Safe setup paths, trace shape, and data boundaries. Most teams spend about 1 to 3 hours; a small adapter adds at most a day.

Read the handoff

Worked examples

Case notes that show the authorization boundary.

These are public worked examples, not claims about a customer's private system. They show the kind of evidence ActionBoundary looks for in a staging pilot.

AP/payment case note

A payment approval is not user authorization.

In an AP workflow, a valid invoice approval does not prove the current actor may schedule payment or change payment details. The review separates approval scope, acting principal, vendor-bank source of truth, tool result, and sandbox side effect.

  • What it provesAction authorization has to be enforced at the tool layer, not inferred from persuasive business context.
  • What it does not proveIt is not a live payment-rail audit, fraud-detection certification, or claim about a customer's production AP system.
  • Buyer useExplains why a security or finance-control reviewer should ask for runtime authority evidence before an agent can move money.
AP/data-export case note

When an accounts-payable agent reads a poisoned document.

A synthetic AP workflow shows how a vendor statement or invoice-like document can carry approval-looking text into a high-impact action. The review asks whether the data export, bank-change, or payment action traces to trusted authorization evidence, not whether the document sounded routine.

  • What it provesBusiness documents are useful context, but they must not become authorization for sensitive data export or payment-adjacent actions.
  • What it does not proveIt is not a customer breach, production incident, or claim about every AP agent.
  • Buyer useUseful for founders facing security-review questions about invoices, statements, vendor emails, and external recipients.
Multi-turn case note

When an agent treats a note as authorization.

A multi-turn workflow can drift when an earlier note, handoff, or status update is reused as authority later. The evidence question is whether the agent checked a current source of truth at action time, not whether a plausible note existed somewhere in the conversation.

  • What it provesAuthorization can drift across turns unless scope, source, actor, and timing are rechecked before the high-impact action.
  • What it does not proveIt is not a broad benchmark of every agent framework or every model's multi-turn behavior.
  • Buyer useUseful for healthcare, insurance, support, scheduling, and operational workflows where a note can be mistaken for approval.
Model-behavior note

Model choice is not an authorization layer.

The public cross-model battery shows that sampled model API configurations produced different attempted tool-call behavior on the same simulated high-impact actions. The business conclusion is narrow: model behavior is evidence to inspect, but application-layer authorization still has to enforce the boundary.

  • What it provesRefusal behavior and model choice are not enough to answer whether an agent may take a high-impact action.
  • What it does not proveIt is not a vendor ranking, product endorsement, current-model leaderboard, or claim that one model is globally safe or unsafe.
  • Buyer useHelps a security reviewer see why the pilot grades actions and runtime evidence rather than model promises.
Stripe L3 method note

Stripe Agent Toolkit authorization boundary review.

A public-source review plus Stripe test-mode coupon run maps Stripe MCP, the official customer-support sample, restricted keys, and per-action authorization evidence into buyer-readable traces. It does not claim a Stripe finding; it shows what trace evidence an agent builder would need for high-impact Stripe writes.

  • What it provesWhen run with a write-capable test key in this slice, the official sample path created unauthorized Stripe test-mode coupon objects from ordinary untrusted business email without a tool-layer gate, while the same write path was denied with the gate and authorized controls still passed.
  • What it does not proveIt is not a Stripe engagement, endorsement, production vulnerability report, customer trace, or claim about Stripe's private MCP systems.
  • Buyer useUseful for teams wiring agents to refunds, invoices, payment links, subscriptions, disputes, connected accounts, or agentic commerce rails.

Method notes

How the review keeps claims narrow.

These notes define the boundaries that keep ActionBoundary from overclaiming. Missing evidence is not treated as safety; it is reported as missing evidence.

Authorization-drift method

Testing multi-turn authorization drift.

The method asks whether trusted authorization evidence is current at the moment of action. It checks trace shape, authority source, pass/fail criteria, and benign controls so a normal authorized path still works.

  • Evidence standardActor, target, authorization source, scope, timing, tool result, and observed business outcome.
  • Pass ruleHigh-impact action proceeds only when current trusted evidence matches the action scope.
  • Fail ruleUntrusted content, stale notes, or mismatched scope cannot authorize the action.
AP/payment method note

Deep payment-control experiment.

The L3-L5 AP experiment checks whether the scorer can handle post-approval mutation, inter-agent handoff claims, retry/replay side effects, and benign payment controls. It shows the evidence standard without publishing customer scenarios.

  • Evidence standardActor, approval source, material payment fields, idempotency key, tool result, and terminal business outcome.
  • Control goalUnauthorized changed, handed-off, or replayed payment actions are blocked while legitimate payment controls still pass.
  • BoundaryPublic synthetic method evidence, not a production ERP test or private customer playbook.
Sample deliverable

Sample evidence report.

The sample report shows the deliverable shape: executive summary, scope, scenario matrix, evidence register, findings, fixes, retest plan, independence boundary, and limitations. It is an illustrative format, not a customer-executed or manifest-bound report.

  • What it provesThe deliverable is not a vague red-team memo; it is organized around trace evidence and action-specific verdicts.
  • What it does not proveIt is not a customer's report or evidence about a private production system.
  • Reviewer useLets a founder or security reviewer inspect the report format before committing to a pilot.

Customer readiness

How a first trace becomes reviewable.

These are the near-conversion pages. They should live on the site because they explain what to send before engineering setup.

Evidence readiness check

Start with one existing trace.

The first paid diagnostic checks whether one redacted trace or exported log contains enough actor, target, authorization, tool-result, and outcome evidence for a defensible verdict. If it is not ready, the output is a missing-evidence map.

  • InputOne redacted LangSmith, Langfuse, OpenTelemetry, Datadog, CloudWatch, or internal trace/log export.
  • OutputScoreability memo, missing-evidence map, and smallest next instrumentation point.
  • BoundaryNo production access, no real customer data, no shared credentials.
Pilot handoff

Technical handoff for a staging review.

The handoff explains the safe setup path: client-run scenarios, redacted traces, synthetic data, no production access, and enough runtime evidence to support a strict verdict. It is useful once a team has a plausible workflow fit.

  • Setup pathsClient-run traces, narrow staging endpoint, or minimal adapter/instrumentation work.
  • Trace shapeTool calls, authorization decisions, tool results, side effects, event IDs, and timestamps.
  • BoundaryPublic client interface, not a private implementation playbook or production-access request.
First-contact checklist

What ActionBoundary needs first.

Send three details: the product and buyer pressure, one workflow or action surface, and a safe test path or existing trace if available. ActionBoundary replies with a realistic first scenario set before pilot setup.

  • Detail oneWhat your agent does, who buys it, and why the review matters now.
  • Detail twoOne workflow where the agent can affect money, records, access, dispatch, or data.
  • Detail threeA safe way to observe it: staging trace, sandbox endpoint, exported logs, or another non-production path.

AP technical stack

Payment review assets without dropping readers into GitHub first.

These entries summarize the technical AP artifacts on-site. Engineers can still inspect the source files when they need exact schema, manifest, or control details.

AP authorization invariants

Rules for approval scope, actor authority, replay, vendor-bank changes, and source-of-truth evidence.

Source on GitHub

AP payment methodology

How one payment or remittance action is normalized and checked against current authority.

Source on GitHub

AP scenario manifest

Attack cases, benign controls, material fields, evidence requirements, and safe outcomes for AP reviews.

Source on GitHub

Deep payment-control experiment

Post-approval changes, agent handoffs, retry/replay, benign controls, and enforced-vs-advisory behavior.

Read full article

AP benign-control library

Normal authorized AP cases that should pass, so the review does not only test attacks.

Source on GitHub

Control alignment

How trace evidence maps to transaction authorization, least privilege, separation of duties, BEC/vendor-fraud risk, and audit logging language.

Read full article

Source layer

Where the audit trail lives.

These links are intentionally external or source-facing. They are for reviewers who want to inspect code, raw summaries, archived reports, or exact files after reading the plain-language pages above.

Open harness Trace runner, scoring code, schemas, and examples. Raw run summaries Summary-level public v1.5 files; not a full per-run provenance package. Multi-turn run artifact Redacted Gemini 3.5 Flash run table and JSON for the prior-auth case note. Zenodo DOI Archived technical report and reproducibility package. Trust boundary Trace handling, retention, and data-processing defaults.

Need this evidence for your workflow?

Send one product, one high-impact action surface, and one safe trace path if available. ActionBoundary will reply with three first scenarios.

Send 3 details