What Legate proves. What it does not.
A result shows which requirements of a named standard this evidence established, which it did not, and what stays unresolved. Whether to rely on it still depends on who held the key, what was covered, how fresh it is, and whether you accept those limits for your purpose. Five lines say it; everything below is the evidence, one control at a time.
- A result shows which requirements of a named standard this exact evidence established, which it did not, and what stays unresolved, at this time, as checked by open code, inside the coverage it declares. A record can be intact and still report that the standard was not met.
- It does not show who holds the keys, that every route was covered, or that relying on it is wise. Undeclared routes, source completeness, and organisational authority stay outside the claim unless the standard carries evidence you accept for them. A true signature can sit on a false statement, a declared route list can be incomplete, and a check can run a mistranslated rule perfectly; the result names its own basis so you can judge each.
- Your data is read where it lives. What travels is counts, digests, and the fields you approve for release; only what you choose to export leaves your browser.
- Signing keys stay under your control. ScopeBlind never holds them, and receives nothing from a check or a comparison. Anchoring, if you switch it on, sends a digest of each result to the public log, never the result. The contact form sends what you type.
- Check any of this yourself: drop the file on Verify or run the open CLI.
Jump to a control13 diligence sections
01 · Enterprise security packData boundaries, customer ownership, engagement artifacts, and the audit-bundle shape.
The enterprise posture is simple: Legate is a local control plane for agents. ScopeBlind should not need your book, prompts, model outputs, provider keys, client data, or private keys to govern or bill the deployment. The only server-side commercial signal is limited to account metadata and one idempotent closed-Case credit, only when billing is explicitly enabled.
Read the security packthe whole document, on this page; the download is the same text
Legate Enterprise Security Pack
One-line architecture
Legate runs the agent-control plane locally. ScopeBlind does not receive raw positions, prompts, model output, provider keys, PII, or mandate source text. In a paid deployment, ScopeBlind may receive account metadata, Case identifiers, workflow status, and cryptographic commitments. Local receipts are not metered.
Data flow
- A desk commits a mandate.
- An agent proposes an action.
- The local Legate gateway evaluates the action against the committed mandate before the tool runs.
- The gateway allows, holds, or denies the action.
- The gateway signs the decision receipt locally.
- The customer exports an audit bundle or a position-blind evidence pack when they choose.
What never leaves the customer environment
- Raw positions, orders, fills, NAV, P&L, prompts, model I/O, provider keys, private keys, client data, research, and strategy notes.
What may leave, only when configured or explicitly exported
- Position-blind evidence packs exported by the customer.
- One idempotent closed-Case credit record if feature-flagged billing is enabled.
- Support logs only if the customer explicitly shares them.
Threat model summary
- Insider mandate edits: mitigated by committed mandate digests and signed receipts.
- Network attacker: cannot forge signed receipts; can only delay/drop traffic.
- Verifier compromise: mitigate by verifying locally or on multiple devices.
- Selective disclosure: mitigate with sequence checks, receipt heads, and administrator/custodian reconciliation where integrated.
- Key compromise: out of scope for cryptography; production deployments should use customer key custody and device co-sign.
Acceptance criteria for an engagement
- Install gateway locally.
- Load a sample or customer-approved read-only book.
- Commit one mandate.
- Run one governed action.
- Hold one consequential action for approval.
- Export one audit bundle.
- Verify one receipt offline.
Explicit non-claims
- The hosted browser demo is not a live trading system.
- Legate does not currently sit on the live FIX/OMS order path unless separately integrated.
- A signature proves bytes and key possession, not economic truth.
- A single pack does not prove completeness unless paired with sequence/reconciliation controls.
Mandates, books, prompts, and model calls remain in the customer environment.
Allowed, held, and denied actions produce local receipts that verify offline.
Billing can count closed point-in-time Cases without counting local receipts or receiving activity payloads.
| Surface | Default disposition | Plain-English boundary |
|---|---|---|
| Positions, prompts, model I/O, provider keys, PII in your data | Never collected | Remain in the customer environment. Not sent to ScopeBlind for billing, support, or verification. |
| Contact details you submit | Sent on submit | The work email and any setup context you type into the enquiry form go to ScopeBlind and are kept for up to 120 days. Nothing else on this site sends contact details. |
| Proof Request drafts | This browser only | Saved in your browser as you type so a reload does not lose them; never sent. Starting a blank request or clearing site data removes them. The signing key is not saved. |
| Mandate source text | Local by default | Receipts bind the mandate digest. The text itself is shared only if the customer exports it. |
| Decision receipts | Customer-owned | Signed locally. Shared only by export or by an explicitly configured sync path. |
| Billing signal | Closed Cases only | If enabled, ScopeBlind records one idempotent credit for a closed point-in-time Case. Local receipts are not metered. |
| Support artifacts | Explicit share | Logs, screenshots, packs, or configs are support material only when the customer chooses to send them. |
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.
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.
Where data goes, at a glanceWhere each kind of data lives, what ever leaves the device, and what a checker can conclude from a shared proof.
| Data | Disposition | What a verifier can conclude |
|---|---|---|
| Positions, sizes, prices, the book | Local-only | Nothing about them. Adherence packs and Cases carry digests and counts, not positions. A payment presentation discloses only the fields the recipient's Proof Request names. |
| Prompts, model I/O, provider keys, PII | Local-only | Nothing. None of it is collected by ScopeBlind or written into a pack or Case. A payment presentation carries the approved amount, destination, and reference the recipient asked for; never prompts, model I/O, or keys. |
| The mandate (its rules) | Hashed | That every decision ran under that exact committed mandate digest, fixed before the period. |
| Each decision + determining rules | Signed & shared | That the decision is unaltered since signing and follows from the committed mandate. |
| The signing key | Public part only | Pack integrity. Not who signed, unless you pin that key out of band. |
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 leaves your machine, and what never does
03 · Data pathThis page is static and runs client-side; positions you import never leave the tab.
04 · Key custodyYour signing key is generated in your browser; we never see, transmit, or escrow it.
05 · What is never collectedPositions, NAV, strategy, keys, credentials, analytics: never collected.
The demo includes no analytics, no cookies, no third-party scripts, and no third-party requests. The only fetches are the page's own assets (self-hosted fonts included) and, on pages that load it, the Cedar policy engine (WASM); no request carries your data.
How it behaves at the edges
06 · Failure postureFail-closed by construction; the worst failure mode is a held order, not a wrong trade.
07 · 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. This hosted site uses only synthetic sample data; higher-assurance paths require a local integration, set up with a team.
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 adversaryTLS in transit and an Ed25519 signature on every receipt: an interceptor can delay or drop, not forge or alter.
In a Legate deployment, traffic between agent and policy runtime rides TLS (confidentiality) and every receipt is Ed25519-signed (authenticity); an interceptor can delay or drop messages but cannot forge or alter a receipt. In this browser demo the path is in-process.
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
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
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.
10 · Build integrity and cryptographySource identity, release manifest, and the offline verification path in one place.
This is the canonical provenance record for the hosted Legate 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.
b06eb75b9539c3b36cd51e6a1cc0ca098ffa23edHEAD# inspect the hosted artifact manifest curl -fsS https://legate.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
11 · 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.
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.
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 bytesCanonical bytes: the receipt JSON re-serialized one deterministic way (keys sorted, no whitespace), so the same record always hashes identically. The signature is over these bytes, which is why any edit is detectable..
12 · 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: Legate supplies the technical control and the cryptographic evidence; regulatory sufficiency is the firm's compliance and legal determination. Where a mapping has a boundary, it is stated.
Full mapping with per-control source references is maintained in docs/compliance-mapping.md.
Five properties are designed to hold together, and most systems have at most one. This hosted surface demonstrates the first two; the remaining controls are labelled by their actual availability:
- It prevents, it does not just log. A block is enforced before the action runs, and every denial cites the exact clause it broke, so the block is auditable, not a black box.
- Prove without exposing. A pack is position-blind by default and each field opens to the right party, so you share verdicts and counts, not the book.
- 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.
Security questionnaires, data-flow diagrams, or a walkthrough for your team: write to us directly. Ready to start? See the plans.