How it works

How it works, and what it proves.

Give an agent a bounded invoice job. Let agreed work move, bring another person in for exceptions, and keep a signed record you can both check.

Try together Security and diligence Connect your agent

You
Agree on the job
Set the budget and when someone must decide.Invite a reviewer to the shared room.
The gate
Check each payment
Supported payments are checked before they run.Exceptions wait for an exact, signed decision.
Together
Review the result
See what happened in the sandbox ledger.Accept the work or request a revision.
Anyone with the files
Check the evidence
Download the signed record and open Verify.Check its integrity, authority and stated limits.

The hosted trial uses fictional invoices and simulated money. Guided requests and a live agent use the same supported payment controls. A signed result records the service’s observations; it does not independently establish that every possible action was covered.

Choose a guided walkthrough, give a live agent the job, or test rules together with isolated sample ledgers. Proposals do not change an active agreement. A reviewed comparison can start a separate trial.

Where each control is checkedTechnical reference: policy, receipts, receivers and human decisions.

This matrix describes controls across supported workflows. A run must supply the relevant policy, receipts, receiver evidence or attestation; these controls are not all implied by using a hosted room or installing a gateway.

Control	Where	When	Who can recompute it
Which tools, by exact name	The gate	Before the call runs	Anyone: the policy and its digest are in the record
Rules over time (no B after A, at most N in a window, A before B)	The history of calls	At every receipt	Anyone holding the receipts, with the receipt where a rule broke named
Amounts and approvals	The records, and the service's receiver where one runs	After the work, and at the moment of spend	The verifier, from the decisions and readbacks
The network rule	The environment	Attested with the run	Anyone reading the attestation; the gate sees calls, not packets
Sentences no control can check	A named person	Before the work is relied on	Recorded with who judged them and when

What a signed record proves, and what it does not

A valid signature shows that the signed fields are unchanged and identifies a key. The record can bind rules, decisions and outcomes together. Input truth, signer identity, independent observation and coverage still need their own evidence.

What a signed record provesIntegrity, committed authority and supported replay checks.

Signed, not trusted

Signed records bind their disclosed fields to a key. An edit to a signed field fails verification. Local verification checks the supported signatures and commitments; it does not turn every displayed status into independently signed evidence.

Deterministic policy

The Cedar policy engine produces the same decision for the same inputs, every time, on any machine. The decision is a function of the mandate, not an opinion.

Bound to a committed mandate

Records cite the authority they were made under. For example, the Meridian sample cites mandate 4108ec3e…. Compare that commitment with the agreement or standard you accepted; the digest alone does not establish prior acceptance.

Verification runs locally

Opening an evidence file in Verify checks it in your browser without uploading its contents. Hosted jobs, model assistance and shared pages use the service as described below.

Requirements and decisions are signed records too

A recipient can sign what evidence would change its decision (write a Proof Request), read a governed action against it (see one payment governed), and sign the decision. All three verify on the verify page or with the CLI, without an account.

Verified runs, and the keys to pin

An agent's benchmark run can carry the same proof: every tool call receipted, the model attested inside a confidential machine, three gradings, provenance verified, paid once on a simulated ledger (see the live run). The verifier asks you to pin the signing keys through a channel you already trust; this page is one, the public repository another. Maintainer key, signs each run's standard: recipient:e1b6a9c5f64f7310, Ed25519 68d517450a1885865c9f2719df6b9beff19e91b40e5c12c649b3e31626dad00f. Grader key, signs our second grading: harness:c9f76087922bdbbb, df5226e53373611b20f0ffa5dcff1495b8126d237ccd58821b411ec0f1bfe45f. The simulated ledger on Verify signs payment records under receiver:simulated-ledger, 414c7179f80e431e10a7b6e370cba85055b58c979cc16b94de6f2b84468a4caf, a key derived from a public seed: real signatures, no money. Both maintainer and grader keys since 12 September 2026; a change will be announced here and in the repository.

What it does not proveInput truth, key custody, complete history and absence of leakage.

Input accuracy

We verify signatures, not truth. An operator-signed NAV could be wrong. An authenticated source pull or source-owner signature strengthens provenance, but source authority, coverage, recipient trust, and acceptance remain separate checks.

Key safety

A signature proves the holder of a private key signed it, not that the key is still in the right hands. If the operator's key is stolen, an attacker can sign as that operator. There is no ScopeBlind recovery backdoor.

A complete history

A single exported pack is not proof you have seen everything. Trimming or rewriting a record is detectable to anyone who retained an earlier head and checks the ; it is not detectable from one pack in isolation.

No side-channel leakage

Position-blind adherence packs omit positions, but other exports can disclose records and decisions. Timing or size metadata may also reveal information. Review the actual format and fields before sharing.

Local examples use demonstration keys. The shared invoice trial uses browser participant keys and a separate service authority over a simulated ledger. Published runs and configured gateways have their own keys, routes and evidence limits.

Where your data goes

The mode determines what stays on your machine, what is stored by ScopeBlind, and what a model provider receives.

Hosted collaboration

A shared room uses the service

ScopeBlind stores the room’s names, agreement, sample records, actions and results, and runs its sandbox gate and ledger. Browser signing keys stay in their browsers.

Guided: Scripted requests; no live model.
Live agent: The brief and sample records go to the model provider. Your own agent may send them to its configured provider too.
Two-person agreement: Shared mandates and proposals are visible to both people. A private brief is available to its author, their authorized agent, ScopeBlind, and the hosted provider when used. Shared exports omit private briefs.
Rules rehearsal: Tests run in isolated service ledgers. Optional readback sends your text and sample invoice context to the model provider.

Use fictional information. The model proposes work; the gate checks the supported payment route. No bank or outside account is connected.

Configured local gateway

Your setup defines the boundary

The installed gateway evaluates configured tool calls and writes receipts locally. Credential isolation and coverage depend on your agent, hooks and destination setup.

Your agent’s model and tools have their own data paths. Optional reporting sends disclosed receipts to a hosted standard page; exports share the files you select.

The hosted trial does not certify this deployment. Check the installed version, policy, credentials and routes before relying on its controls.

Verification and sharing

Checking a file runs locally

Files opened in Verify are checked in your browser without uploading their contents. A local CLI check can also run offline once its software and files are available.

Publishing a standard or creating a hosted share sends the selected content to the service. Downloaded exports and proof-carrying links disclose their contents to whoever receives them.

A valid signature establishes integrity and the signing key. It does not establish input truth, independent observation or complete route coverage.

On Write, optional model assistance sends the conversation, current readback and tool context through ScopeBlind to the configured provider. Signing a draft and publishing its page are separate actions.

What shared evidence disclosesFormats carry different fields; inspect the actual export.

Evidence	Disclosed content	Verification boundary
Shared job or rehearsal	Agreement, selected inputs, decisions, outcomes and signed commitments for that format	Service-observed sandbox work or included tests, not independent execution observation
Position-blind adherence pack	Selected digests, counts and verdicts; no positions in that pack format	Integrity of those assertions, not the truth or completeness of the underlying book
Published run or gateway receipts	The supplied policy, receipt readbacks, call evidence and attestations	The supplied record and supported checks; omitted routes need separate coverage evidence
Signing keys	Public keys and signatures; keep private keys out of exports	Pin the expected signer out of band before relying on its claims

Key custodyParticipant keys, service authority and local demonstration keys have different custody.

Shared-room participant keys stay in the browser

The trial generates a non-extractable Ed25519 private key and stores it in that browser’s IndexedDB. Public keys and signed requests go to the service; invitations do not contain the private key. Clearing site storage can remove access from that browser.

The hosted service has its own signing authority

ScopeBlind operates the sandbox gate and signs its observations using a separate service key. Participant signatures and service signatures have different roles. The service’s signature does not create an independent observer.

Local examples and installed gateways

The Meridian sample uses a deliberately public demonstration key; some browser examples retain demo keys in localStorage. An installed gateway uses its configured local signing key. Inspect custody for the package and deployment you run; a demo key establishes no production custody assurance.

Key possession is not identity or safe custody

Pin expected public keys through a trusted channel. A stolen private key can sign as its holder, and browser storage does not establish a person’s identity. Review backups, revocation and custody with the relevant deployment.

Collection boundariesLocal checking, hosted work and explicit sharing are separate actions.

Local verification does not upload the opened file

The browser checks the supported file formats locally. Loading site assets or fetching a shared record is separate from sending a file to the service.

Hosted work stores collaboration state

Names, agreements, sample records and recorded work are service data. Live agents and optional readback send their stated context to a model provider. Use fictional information in the trial.

Publishing and sharing disclose selected content

A hosted standard page, receipt-reporting route or hosted share stores the content sent to it. A downloaded export or proof-carrying link shares its actual fields with the recipient. Do not treat every evidence format as position-blind.

Security and diligence

The material a security, operations, or compliance reader files: failure posture, source assurance, the threat model, what runs where, the enterprise pack, the control register, and the regulatory mapping. Each section is anchored and prints.

Jump to a control13 diligence sections

Enterprise security packData boundaries, customer ownership, engagement artifacts, and the audit-bundle shape.

Use this pack to review a configured local gateway and its enabled services. Local evaluation, hosted collaboration, optional model assistance and evidence sharing have different data paths. The controls must be checked against the installed version and the routes your agents actually use.

Read the security packthe whole document, on this page; the download is the same text

ScopeBlind Enterprise Security Pack

Deployment scope

The configured local gateway evaluates supported agent tool calls and signs receipts in the customer environment. Credential isolation, approval support and route coverage depend on the installed version and configuration. This pack is deployment guidance, not certification of an installation.

Hosted services are a separate data path

The shared invoice service stores names, agreements, sample records, actions and results, and operates a sandbox gate and ledger. Guided requests are scripted. Live-agent jobs send the brief and sample records to the model provider; optional rehearsal readback sends the supplied text and sample invoice context. An agent you connect may send room data to its own provider. Browser participant signing keys stay in their browsers; the service holds separate operator signing keys.

Optional model assistance on Write sends the conversation, current readback and tool context through ScopeBlind to the configured model provider. Publishing a standard, syncing receipts and creating hosted shares send the selected content to ScopeBlind. Contact details and setup context submitted through the enquiry form are held for up to 120 days.

Configured local data flow

Review a mandate and the installed policy.
Route supported agent actions through the local gateway.
The gateway evaluates each routed action before the tool runs.
The installed policy and approval path determine whether it allows, holds or denies the action.
The gateway signs decision receipts locally.
Export an audit bundle or enable a documented reporting path when needed.

Local data boundaries

Local evaluation and local verification do not require sending raw positions, research, prompts or private keys to ScopeBlind.
Your agent's model provider and destination tools have their own data paths. Review them separately.
Inspect exported and reported fields: some records disclose actions, inputs and decisions; a position-blind adherence pack carries selected digests and counts.
Support logs are shared when the customer supplies them. Do not include private keys, tokens or credentials.
If feature-flagged closed-Case billing is enabled, account metadata and one idempotent credit record can be reported; local receipts are not metered by that mechanism.

Threat model summary

Insider mandate edits: compare committed mandate digests and signed receipts against the authority you accepted.
Network attacker: signatures detect edits to signed fields; an attacker can still delay, drop or replay evidence. Check freshness.
Verifier compromise: verify with a trusted local verifier or on multiple devices.
Selective disclosure: sequence checks, retained receipt heads and administrator or custodian reconciliation strengthen coverage where integrated.
Key compromise: a valid signature does not establish safe custody. Pin expected keys and review the configured custody and revocation controls.

Acceptance criteria for an engagement

Install and identify the gateway version.
Load a sample or customer-approved read-only book.
Review and commit one mandate and its policy.
Run one governed action and confirm the configured route is active.
Hold one consequential action for the configured approval path.
Export one audit bundle and verify one receipt offline.
Check which tools and destinations remain outside the governed route.

Explicit non-claims

The hosted invoice trial uses fictional invoices and simulated funds, not a bank or live trading system.
A hosted rehearsal report covers its included test cases, not another deployment or every possible input.
ScopeBlind does not sit on a live FIX/OMS order path unless separately integrated.
A signature establishes signed bytes and key possession, not economic truth or independent observation.
A single pack does not prove completeness without sufficient sequence, coverage and reconciliation evidence.

Configured control

Local evaluation covers routed calls. Review model, tool and reporting paths separately.

Signed evidence

Keep the receipts and expected keys for the configured workflow; verification can run locally.

No surveillance billing

Billing can count closed point-in-time Cases without counting local receipts or receiving activity payloads.

Surface	Default disposition	Plain-English boundary
Local gateway inputs	Configured locally	Local evaluation does not require raw inputs to be sent to ScopeBlind. Model providers, destination tools and enabled reporting have separate data paths.
Hosted shared jobs and rehearsals	Service state	Names, agreements, sample records, actions and results are stored by ScopeBlind. Live work and optional readback use a model provider.
Contact details you submit	Sent on submit	The work email and setup context entered in the enquiry form go to ScopeBlind and are kept for up to 120 days. Shared rooms separately store the names participants provide.
Proof Request drafts	Browser draft	The Proof Request editor saves its draft in your browser. Exporting or sharing discloses the selected content. Write model assistance and hosted standard publishing are separate network actions.
Standards and receipts	Workflow-dependent	The local gateway signs receipts locally. Hosted rooms store their evidence on the service. Published standard pages and optional reporting also use the service.
Billing signal	If enabled	The closed-Case billing mechanism records one idempotent credit for a closed point-in-time Case. It does not meter local receipts.
Support artifacts	Explicit share	Logs, screenshots, packs and configs become support material when you send them. Remove credentials and private keys first.

Engagement artifacts

Deployment guide

Install gateway, configure runtime, set mandate, verify first receipt.

Security overview

Data boundaries, key custody, controls, and non-claims in one pack.

Threat model

Insider, network, verifier, selective-disclosure, stale-evidence, and key-compromise risks.

Audit bundle manifest

Receipts, approvals, mandate digest, evidence pack, verifier command, and local-only raw inputs.

Support process

What to share, what not to share, and how to reproduce without exposing the book.

Audit bundle shape

An engagement should end with a customer-owned folder that can be reviewed offline without calling ScopeBlind.

audit-bundle/
  mandate.digest.txt
  receipts/decisions.jsonl
  approvals/phone-or-desktop.jsonl
  evidence/position-blind-pack.json
  exports/booking-ticket.csv
  verify.sh
  README.md

Verify a pack in this browserPaste a signed pack or load the canonical sample. Nothing is uploaded.

Public verifier: paste and check a pack offline

Paste a signed adherence pack a desk produced (scopeblind.legate.proof-pack.v1), or load the canonical sample. It is verified here, in your browser, offline: the canonical digest is recomputed and the Ed25519 signature is checked against the runtime key the pack carries. Nothing is sent anywhere. Positions are never in an adherence pack, so you verify adherence without seeing the book.

How it behaves at the edges

Failure postureThe hosted payment route and local reference controls have explicit limits.

Hosted invoice controls

The supported payment tool checks the room’s agreement, available budget, duplicate identity and any required exact approval. The model cannot approve its own exceptions. An unresolved outcome remains visible with authority reserved while it is checked; these controls do not cover the agent’s other tools.

Local trading reference: signal loss

The local trading reference watches a liveness heartbeat and degrades in stages rather than freezing the desk on a single missed beat (a hard halt would block risk REDUCTION mid-dislocation, which is its own danger). Fresh heartbeat: decide normally. Stale within a grace window: permit only risk-reducing orders, each requiring a human co-sign, and block all new exposure. Stale beyond grace, or an unreadable heartbeat: hard halt. New risk and unknown liveness always fail closed.

Local demonstration boundary

The browser trading example checks proposed orders without broker credentials or a live order connection. A configured gateway can invoke its destination tools; its effects, credential isolation and fail-closed behavior must be checked for that deployment.

Tamper-evident records

Every decision receipt and evidence pack is Ed25519-signed over canonical bytes. Any edit to a signed field fails verification; the Verify page demonstrates this live.

Source assuranceWho controlled the evidence source, how it arrived, and what that still does not prove.

Source assurance is not a numeric trust score. The product records who controlled the evidence, how it arrived, and whether another party signed it. Coverage, freshness, recipient trust, and acceptance are evaluated separately. The hosted invoice trial is intended for fictional sample data; a model readback does not authenticate its source. Higher-assurance paths require an appropriate source integration.

Synthetic sampleHosted sample

Synthetic data and demo keys. Nothing real is connected.

Operator-signedLocal setup

The operator signed the inputs. Their bytes are tamper-evident, but the operator still controls the source.

Authenticated source pullIntegration

Inputs came through an authenticated read-only pull from the declared source. Authority and coverage are evaluated separately.

Source-owner signedIntegration

An independently controlled source owner signed the canonical evidence or sidecar manifest. Coverage and recipient trust remain separate decisions.

Threat modelInsiders, transport, compromised verifiers, missing records and stale evidence.

Each row names a threat and the headline mitigation. Open one for the full reasoning.

Insider threatThe mandate digest is shared or published before the period, so later deviation is detectable.

An operator could modify their local mandate or snapshot. Mitigation: the mandate digest is shared with allocators (or published) before the period begins, so any later deviation is detectable.

Network adversaryHTTPS protects hosted transport; signatures detect changes to signed fields. Check freshness and missing evidence too.

Hosted requests use HTTPS. Local transport depends on the deployment. Signatures make changes to signed fields detectable but do not stop delay, omission or replay. The browser-local examples evaluate in-process; hosted rooms use a service.

Verifier compromiseVerify on multiple devices, or run the open verifier locally.

The offline verifier is stateless JavaScript. An attacker who controls the browser the allocator is using could show a fake "valid" result. Mitigation: verify on multiple devices, or run the open verifier locally.

Selective disclosureAdministrator reconciliation and sequence checks strengthen period coverage where integrated.

An operator can withhold packs or act outside the governed route. Administrator reconciliation and visible sequence gaps can strengthen period coverage where integrated; neither replaces an explicit deployment coverage check.

Stale evidencePacks bind a stated period and a signed issued_at; check the dates against your diligence window.

An old pack can be re-presented as current. Mitigation: packs bind a stated period and signed issued_at; check the dates against the period you are diligencing.

History rewriteDetectable to anyone who retained an earlier head and checks the consistency proof against it.

An operator could trim or rewrite an earlier record. This is not caught by any single pack; it is detectable to anyone who retained an earlier head and checks the consistency proof against it.

Advanced · Filed assurance mechanismsTwo bounded capabilities, available to design partners: test the declared evidence boundary, then couple supported completion to required evidence.

These mechanisms extend a point-in-time Assurance Case. They do not create standing assurance, universal route coverage, or trust by themselves. The recipient still decides which inventory, observations, sources, and keys are acceptable.

Could a relevant event have escaped the declared evidence boundary?Claim-directed closure and detectability · Design partner · simulator-tested

AvailabilityDesign partner

What it establishes: a deterministic result over the routes, observation positions, exclusions, and trust domains bound into this Case. Unknown, uninspected, or bypass-capable routes remain visible and prevent an affirmative result when the recipient's policy requires closure.

What it does not establish: that no undiscovered route exists, or that anything outside the inventoried boundary was observed. Australian provisional application 2026906437 was filed on 20 July 2026; filing is not a patent grant.

Could a supported governed action finish without the required evidence?Evidence-coupled authorization · Early access · receiver-participating reference route

AvailabilityEarly access

What it establishes: for the supported reference route, completion requires a one-time capability, the policy's witness acknowledgements, and a receiver-signed outcome. Replay, mutation, missing evidence, and a lapsed completion lease fail closed.

What it does not establish: atomic completion for an externally irreversible system that does not participate in the protocol. Australian provisional application 2026906436 was filed on 20 July 2026; filing is not a patent grant.

Machine-readable release scope, schemas, and the evidence-authorization conformance vector are published in the A/C conformance manifest.

Hosted shared invoice serviceGuided jobs, live agents and rules rehearsals use the service.

The service stores collaboration state, checks supported sandbox payments and records its outcomes. Guided jobs use scripted requests; live jobs use a model provider when available. Rules rehearsals exercise included cases in isolated service ledgers. Optional readback suggests a case; it does not change the rules or run a test.

Browser-local reference tools and additional integration paths are listed separately below. Their availability does not mean they are connected to a shared room.

Browser-local reference toolsPolicy examples, signatures, imports and verification.

Cedar policy evaluationAvailable now

Ed25519 signing & verificationAvailable now

CSV portfolio importAvailable now

Evidence pack generationAvailable now

Offline verifierAvailable now

Additional configured integrationsAvailability depends on the integration and deployment.

Prime broker API connectionLater

Signed administrator reportDesign partner

Authenticated source attestationDesign partner

Claim-directed route closureDesign partner

Evidence-coupled receiver completionEarly access

Phone approval for held actionsEarly access

Hardware-backed key supportEarly access

Build integrity and cryptographySource identity, release manifest, and the offline verification path in one place.

This is the canonical provenance record for the hosted ScopeBlind surface. The build manifest binds each generated page to the source commit below. Receipt verification is separate: it recomputes canonical bytes and verifies the Ed25519 signature locally.

Hosted build

Source commite1f742a5cf8a77fb50cea55000f030bd4cb2e443

Source branchcodex/agent-devices-decisions

Source treeClean

Built2026-09-16

Manifestbuild-provenance.json

Verification primitives

Ed25519 signatures

Bind a receipt to a signing key and make any byte-level edit detectable.

Canonical JSON

Produces one deterministic preimage for the same disclosed fields.

SHA-256 commitments

Bind hidden or externally retained material without publishing it.

Open verifier

Runs without a ScopeBlind account or hosted verification dependency.

# inspect the hosted artifact manifest
curl -fsS https://scopeblind.com/build-provenance.json

# verify a shared receipt offline
npx @veritasacta/verify receipt.json

A valid signature proves integrity and key possession. Trust still requires the recipient to pin the expected signer, check source assurance and freshness, and decide whether the stated coverage is sufficient.

Compliance and audits

Control posture (SOC 2 criteria)The SOC 2 Trust Services Criteria, mapped to live controls.

We will not claim a certification we do not hold. This is the control posture: what a buyer can verify today, what is in progress, and what is on the roadmap to a SOC 2 examination, mapped to the Trust Services Criteria.

Security

Strict content security policydefault-src 'none'; connect-src 'self'; no third-party script or beacon. Inspect the response headers.Verifiable today

No data egress from the demoPositions, prompts, and keys stay in the browser; verification runs offline. Watch the network tab.Verifiable today

Tamper-evident recordsEvery decision is an Ed25519 signature over canonical bytes; any edit breaks the digest.Verifiable today

Independent verification pathReceipts and packs re-verify with any Ed25519 library and the open CLI, with no vendor call.Verifiable today

Authentication, SSO and RBACOn the commercial console (WorkOS SSO); the accountless demo has no login by design.In progress

Dependency and supply-chain reviewPinned dependencies; the signing path is a small audited surface (noble curves/hashes).In progress

Independent penetration testScoped against the commercial issuance API before first paid deployment.Planned

SOC 2 examinationControls are being assembled toward a Type I; we will publish the report, not a logo.Planned

Availability

Stateless, edge-served verificationThe verifier is static JavaScript on a global edge; checking a pack needs no server up.Verifiable today

Managed issuance SLAAvailability target + status page for the commercial VOPRF issuance API.Planned

Confidentiality

Position-blind disclosureThe allocator pack carries counts, verdicts, and digests, never positions or sizes. Toggle it on /proof.Verifiable today

Encryption in transitTLS on every surface; the demo makes only same-origin requests.Verifiable today

Encryption at rest for managed dataFor the commercial persistence layer; the demo persists nothing server-side.Planned

Processing integrity

Deterministic, fail-closed policy engineCedar evaluates the committed mandate in-browser; the gate fails closed to review on any engine disagreement.Verifiable today

Recomputable signed outputsA signed risk run is reproducible from its bound risk_model_digest; the mandate digest is the SHA-256 of the Cedar text.Verifiable today

Privacy

Data minimizationThe demo collects nothing. A pilot request stores only a work email plus optional context you type.Verifiable today

Sub-processor register + DPAPublished list of sub-processors and a data-processing agreement for the commercial product.In progress

The instant-try demo is deliberately accountless and local. Authentication, SSO, RBAC, and a managed persistence layer are properties of the commercial product, not of this demo, and a live receipt or pack proves integrity without any of them.

Certifications and auditsCurrent audit status and published verification artifacts.

SOC 2Later

External security auditLater

Open verification pathAvailable now

Supply-chain provenance (SLSA, CycloneDX SBOM, OpenSSF Scorecard)Available now

Blockchain or tokenNone, by design

We will not claim certifications we do not hold, and there is no blockchain or token anywhere in this system; tamper-evidence comes from plain Ed25519 signatures over canonical bytes.

Regulatory control mappingHow the controls map to NIST, the EU AI Act, DORA, SEC, and MiFID II.

A control-and-evidence mapping, not a certification. Apply each row only where the named control is configured and its evidence is present. Hardware co-signing, source integrations and witnessed records are separate deployment capabilities, not guarantees of the hosted invoice trial. Regulatory sufficiency is the firm's compliance and legal determination.

NIST SP 800-207 (Zero Trust)Per-action enforce-before-action decisions, a least-privilege signed agent manifest (fail-closed), and signed, freshness-stamped context state.

OWASP Agentic AI Top 10Bounded agency via the manifest and committed mandate; a restraint receipt on every block; hardware human co-sign; tamper-evident, offline-verifiable audit.

EU AI Act, Art 12-15Signed, tamper-evident logging and offline-verifiable records can support transparency and oversight. Human approval and failure behavior depend on the configured route; this page does not establish article-level compliance.

DORA, Art 9Enforce-before-action prevention, a degraded-mode kill switch, and a witnessed, timestamped append-only record.

SEC 17a-4(f) / 204-2Customer-owned WORM storage plus a separately pinned third-party timestamp can strengthen retention and timing evidence. Boundary: those controls do not prove route coverage or legal sufficiency; the firm still needs the required storage configuration and counsel, and most fund and adviser prospects are not broker-dealers.

MiFID II, RTS 6Pre-trade mandate limits enforced by the gate, with signed control records. Boundary: today ScopeBlind governs agent-proposed actions in the research and operations loop; the live FIX/OMS order-path integration is the next step.

Full mapping with per-control source references is maintained in docs/compliance-mapping.md.

Related assurance mechanismsDeployment-specific controls and their current availability.

These mechanisms belong to distinct evidence formats and deployment paths. Check the stated availability and integration before applying a claim to your own workflow:

Enforcement on a configured route. The hosted payment gate checks supported requests before they run. Other gateways and integrations require their own coverage and activation checks.
Position-blind adherence format. The specialist adherence pack shares selected digests, verdicts and counts. Other exports can disclose inputs and records; inspect their fields.
Device-bound human co-sign (early access) on held actions, so a paired deployment can bind approval to a registered device rather than a generic checkbox.
Signed input provenance (design partners), so a configured source adapter states where each input came from and how far a recipient should discount it.

A fifth property, issuer-blind verification (receipts checkable without revealing who issued them, so privacy comes from the math), is specified for the managed issuance layer (production ships signed credentials today; blinding is on the roadmap), not in this browser demo, which uses plain Ed25519. The verifier is open; the issuer is the commercial layer.

Questions

Security questionnaires, data-flow diagrams, or a walkthrough for your team:Request the security questionnaire. Ready to start? See the plans.