Ecosystem adopter proposal: Veritas Acta / ScopeBlind as ATF Element 2 & 5 implementation

[tomjwxf]

Hi ATF maintainers, really nice work on the specification. The five-element framing (Identity, Behavior, Data, Segmentation, Incident Response) and the Intern → Principal maturity model both read as well-considered. The CSA publication gives it the kind of multi-stakeholder legitimacy that most agent-governance work lacks.

Filing this as a proposal to add an ecosystem-adopter entry to ECOSYSTEM.md, following the existing pattern set by Microsoft AGT and VERA.

What we do that maps onto ATF

We implement the technical layer that underpins Element 2: Behavior ("what are you doing?") and Element 5: Incident Response ("what if you go rogue?") via cryptographically signed decision receipts for each agent tool call.

A decision receipt is a JCS-canonical, Ed25519-signed record of one policy evaluation (tool call, sensor reading, API access). Each receipt carries:

• The decision (allow, deny, alert)
• The policy that governed it (name + SHA-256 digest)
• Timestamp
• Hash link to the previous receipt in the chain
• Signature over the JCS-canonical payload

Chains are tamper-evident as a whole: insertions, deletions, and reorderings all break later receipts. Verification is fully offline with any conformant implementation.

Mapping to ATF elements:

ATF Element	What we implement	Notes
2. Behavior ("what are you doing?")	Per-tool-call signed receipts forming a tamper-evident audit chain. Anomaly detection can run on the chain directly since it captures every decision.	Primary fit
5. Incident Response ("what if you go rogue?")	Cedar policy evaluation runs BEFORE each tool call with fail-closed semantics; deny receipts prove the kill-switch held	Directly addresses "kill switches, circuit breakers, containment"
1. Identity ("who are you?")	Receipts bind to a supervisor-hook identity (not the agent identity) for signer authenticity; agent identity layer is complementary	Partial fit, orthogonal

We do not claim coverage of Elements 3 (Data Governance) or 4 (Segmentation). Those are addressed by the tools we compose with (protect-mcp for MCP tool call gating, Cedar for policy evaluation, and the host sandbox for segmentation).

Proposed ECOSYSTEM.md entry

| Project | Organization | Relationship | ATF Coverage | Repository |
|---|---|---|---|---|
| Veritas Acta / ScopeBlind | ScopeBlind (independent) | Built on IETF draft for signed decision receipts; maps to ATF Elements 2 and 5 | Elements 2, 5 (partial 1) | [GitHub](https://github.com/ScopeBlind) |

Supporting evidence

• IETF Internet-Draft: draft-farley-acta-signed-receipts
• Four independent implementations of the receipt format today: protect-mcp, protect-mcp-adk, sb-runtime, and an APS governance hook
• Reference verifier CLI on npm: @veritasacta/verify
• Microsoft AGT integration: PR #667 merged, example at examples/protect-mcp-governed/
• AWS Cedar for Agents: PR #64 merged (policy evaluation WASM bindings)
• In-toto predicate proposal: in-toto/attestation#549
• SLSA for agents discussion: slsa-framework/slsa#1594

Note that AGT is already in your ecosystem list; our integration rides on top of AGT's existing policy framework and adds the signed-receipt layer. If the list naming prefers "independent convergence" or "built on ATF principles," our relationship is closer to the latter: we arrived at the same decomposition (identity / behavior / policy / incident response as orthogonal layers) from the protocol-standards side rather than the governance-spec side, which is a nice bidirectional validation.

Two questions

1. Is there a maturity-model mapping you would like ecosystem adopters to report? Our receipts most directly support the Intern and Junior tiers (continuous oversight / human approval of every action), but the infrastructure is the same across all four tiers; the tier is really about what policy the operator writes, not what the receipt layer captures.

2. Is ATF v1.0 accepting new ecosystem entries, or is the list frozen at the public review draft? If the former, happy to open a PR with the entry above. If the latter, happy to wait and contribute to v1.1.

Offer

Happy to contribute any of:

1. A PR adding the ecosystem entry above, with one-paragraph expanded relationship text in the same style as the MSFT AGT and VERA entries
2. A short case-study doc (markdown, 600-900 words) showing how decision receipts implement a real ATF Element 2 check end-to-end, if that pattern is useful for the spec's implementation guidance
3. Cross-linking from our own docs to ATF as the governance-framework context in which our receipt layer fits

Thanks for the work. The ATF framing is the clearest Zero Trust mapping I have seen for AI agents, and I expect it to age well.

Tom Farley
(Independent capacity; IETF draft author.)

[aeoess]

+1 on tomjwxf's ecosystem entry. The Veritas Acta / ScopeBlind mapping to Elements 2 and 5 is clean and the convergence framing (identity / behavior / policy / incident response as orthogonal layers arrived at from two sides) is correct.

Filing an adjacent ecosystem entry for Agent Passport System (APS). Our coverage overlaps with ScopeBlind on Elements 2 and 5 but extends into Element 1 via scoped delegation chains — which is the piece the decision-receipt layer treats as orthogonal.

What APS adds beyond the receipt layer

ATF Element	APS mechanism	Relationship to ScopeBlind's entry
1. Identity ("who are you?")	Ed25519 passports + scoped delegation chains with monotonic narrowing (authority can only decrease at each hop) + cascade revocation	Primary fit — goes beyond "signer authenticity for the receipt" into "authority structure of the agent"
2. Behavior ("what are you doing?")	Gateway-mediated enforcement records; every tool call produces a signed enforcement record referencing the delegation chain root and evaluated policy digest	Parallel to ScopeBlind's decision receipts; the two verify independently, and APS enforcement records can be co-issued as Acta-compatible v2 envelopes (driver just shipped at ScopeBlind/agent-governance-testvectors#1)
5. Incident Response ("what if you go rogue?")	Cascade revocation — revoking a parent delegation instantly invalidates every descendant without coordination; combined with fail-closed gateway semantics	Direct fit — kill-switch is structural (chain integrity), not just an advisory flag

We don't claim Element 3 (Data Governance) or 4 (Segmentation) — same honest boundary ScopeBlind drew.

On the ecosystem list framing

The MSFT AGT + VERA entries pattern works for APS too. Relationship: independent convergence on delegation-plus-receipt as the natural composition, approached from the protocol side. Coverage: Elements 1, 2, 5. Repository: https://github.com/aeoess/agent-passport-system (Apache 2.0, npm + PyPI, 103 modules).

Proposed entry:

| Agent Passport System (APS) | AEOESS (independent) | Protocol-layer identity + delegation + enforcement; converges with ATF's Identity/Behavior/Incident Response decomposition | Elements 1, 2, 5 | [GitHub](https://github.com/aeoess/agent-passport-system) |

Bridge to ScopeBlind entry

APS and ScopeBlind aren't competing for the same slot — we slot next to each other. A deployment using both gets:

• APS passport + delegation chain → Element 1 (structural identity and authority)
• ScopeBlind/Acta signed receipts → Element 2 audit trail (per-tool-call attestation)
• Either/both → Element 5 (revocation via APS chain + kill-switch receipts via Acta)

This is actually how our ScopeBlind driver works in practice — APS emits enforcement records, wrapped into Acta-compatible v2 envelopes, verifiable by @veritasacta/verify.

Answering the same two questions tomjwxf raised

1. Maturity-model mapping. Same answer — the receipt/delegation infrastructure is tier-agnostic, tiers are a property of the policy operators write. APS delegation scopes naturally narrow as you move toward Principal tier (less approval friction for higher-autonomy agents), but the cryptographic primitives don't change.

2. v1.0 acceptance. Same question. If ecosystem list is still open, happy to file the PR with the entry above. If frozen until v1.1, happy to wait.

Offer

A PR adding the APS entry in the same style, and/or a short case-study showing how delegation narrowing satisfies ATF Element 1 end-to-end. Pairs cleanly with ScopeBlind's Element 2 case study if both are useful to the spec's implementation guidance.

[tomjwxf]

@aeoess +1 on the APS entry alongside this one. The coverage map reads right: APS Element 1 (identity via scoped delegation chains), plus Elements 2 and 5 via the gateway + enforcement record pattern. The framing that your cascade revocation is structural rather than advisory is the right distinction — revocation as a chain-integrity property rather than a flag catches exactly the scenarios where a stale delegation token would otherwise keep signing.

Two framing points worth surfacing for the maintainer review of both entries together:

APS and ScopeBlind cover Element 1 at different layers, not competing for the same slot. Your coverage is the structural authority layer (who delegated what, with what scope, under which principal). My coverage is the signer-authenticity layer (which key signed each receipt). Both are real parts of Element 1 ("who are you?") but they answer different sub-questions. A deployment using both gets cleaner answers than either alone: APS answers "whose authority" and Acta answers "whose signature," and the two compose at the delegationChainRoot reference I just added to in-toto/attestation#549.

The ATF ECOSYSTEM.md entries already model orthogonal implementations (MSFT AGT and VERA cover overlapping elements with different approaches). APS + ScopeBlind slotting into Elements 1-2-5 with a composition link between them fits that same pattern. If the maintainers want, the entries could explicitly note the composition (e.g., in the Notes column something like "composes with ScopeBlind decision receipts at the delegationChainRoot reference") to signal that the ecosystem already has the interop primitive.

Also worth flagging for @jman-msc and the ATF maintainers as they review both entries: the cross-verification via npx @veritasacta/verify landed in ScopeBlind/agent-governance-testvectors as a shared conformance suite earlier today. Both APS and Acta implementations pass the same three-check pipeline (schema, signature, chain). That is an ecosystem interop property the ATF could point at in the spec's implementation guidance section — a reader asking "how do I verify these receipts in practice" gets a single answer that works for multiple ATF-adopting implementations.

On the same two questions we both raised (maturity mapping, v1.0 acceptance): happy to hold both PRs until the maintainers have a chance to pick. If the answer is "v1.0 is frozen, file for v1.1," that is fine and I would suggest both of us wait rather than splitting the timing.

@jman-msc let us know the right sequencing and we can align.

[aeoess]

+1 on both framing points. APS answering "whose authority" and ScopeBlind answering "whose signature" is the right decomposition for Element 1, and the composition via delegationChainRoot reference is now the concrete primitive (in-toto/attestation#549 just added it).

For the maintainer review of both entries: happy for the ATF ECOSYSTEM.md APS entry to carry a Notes column pointing at the ScopeBlind composition. Suggested phrasing: "Composes with ScopeBlind decision receipts at the delegationChainRoot reference (in-toto/attestation#549, Decision Receipt predicate); cross-verification fixture available at ScopeBlind/agent-governance-testvectors." Keeps the interop primitive visible without overclaiming either entry's scope.

On the broader pattern — the ATF ecosystem having explicit composition links between entries is a genuine asset. It tells adopters which implementations work together versus which cover the same slot. APS + ScopeBlind at Elements 1-2-5 + VERA covering its own slots + MSFT AGT covering its own is exactly the shape a multi-implementation ecosystem should have. No maintainer action needed from my side on the framing; I just wanted to flag it as visible.

[desiorac]

Veritas Acta covers the decision plane: what the policy engine chose to allow or deny, signed at evaluation time. There is a complementary gap at the execution plane: what the agent actually sent downstream, independent of what it claimed to send.

Proposing ArkForge Trust Layer as a complementary adopter covering that layer.

Mapping:

ATF Element	Coverage	Mechanism
Element 1 (Identity)	API key bound to proof chain	Each proof includes agent_id derived from the signing key
Element 2 (Behavior)	Per-call certified receipts	Proxy sits between agent and upstream API; records exact request + response
Element 5 (Incident Response)	Circuit breaker + proof revocation	Integrated CB at proxy level; proofs are individually addressable and linkable

Technical approach: neutral proxy (POST /v1/proxy), Ed25519 signature, RFC 3161 timestamp, Sigstore Rekor anchor. Chain hash links successive calls. Offline-verifiable by anyone with the public key; Rekor entry is independently searchable.

Relationship to Veritas Acta / ScopeBlind: orthogonal layers. A Cedar policy can allow a call that ArkForge then proves was never sent (network failure, agent override). Both attestations are needed for complete forensics — decision receipt + execution proof.

Formal spec: ark-forge/proof-spec (v2.1.3, MIT).
Live: https://trust.arkforge.tech — free tier, 500 proofs/month.

Suggested ECOSYSTEM.md entry:

| ArkForge Trust Layer | Element 1 (partial), 2, 5 | Neutral proxy producing Ed25519-signed, RFC 3161-timestamped, Sigstore-anchored execution proofs for agent tool calls | https://github.com/ark-forge/proof-spec | Production |

Happy to add a PR against ECOSYSTEM.md if the format fits.

[aeoess]

@desiorac, the decision-plane / execution-plane split is the right framing, and the case you named (policy allow followed by a call that never went out, or went out differently) is where the decision receipt on its own under-attests.

Reading this alongside the APS + Veritas Acta entries, the three layers actually compose cleanly.

• Delegation plane (APS): whose authority authorized the call. delegationChainRoot links the call back to the principal who granted scope.
• Decision plane (Veritas Acta): what policy allowed or denied at evaluation time. Signed policy digest + evaluated constraints.
• Execution plane (ArkForge): what actually went out the wire. Certified receipt independent of what the agent claimed to send.

A complete forensic record wants all three. Authority without decision is a blank check. Decision without execution is an unverified claim. Execution without authority is a signed orphan. The three attestations reference each other by hash and an auditor walks the composition.

For the ECOSYSTEM.md table, the proposed ArkForge row fits. If the maintainers want to note relationships, the Notes column can carry something like "decision-plane counterpart: VeritasActa; delegation-plane counterpart: APS" on each of the three rows so the composition is visible without requiring the reader to infer it.

On the in-toto composition side: the Decision Receipt predicate at in-toto/attestation#549 already carries delegationChainRoot as an optional field, which handles the APS to VA link. ArkForge's execution proof could reference the decision receipt digest in its own envelope the same way, which would make all three layers chain-linkable without any of them pinning the schema of the others.

+1 on adding the row.

[tomjwxf]

Agreed, this composes naturally: delegation (APS) -> decision receipt (Veritas Acta) -> execution gate (ArkForge/KCCS). The receipt is intentionally algorithm- and transport-agnostic; the cryptographic commitment is the stable interface, which is why APS delegation proofs and ArkForge enforcement decisions can both chain into or out of a Veritas Acta receipt without any of the three owning the others' concerns.

Can contribute a composition-diagram section to ATF if helpful

[aeoess]

The diagram would help. The three-plane separation is the part worth making visual: delegation (APS) carries whose authority, the decision receipt (Veritas Acta) carries what the policy allowed at evaluation, and the execution gate (ArkForge/KCCS) carries what actually went out. Each references the others by hash and none owns the others' concerns, which is what lets an integrator adopt one plane without taking on all three.

If you draft the section, APS can confirm the delegation-plane reference shape (delegationChainRoot as the content-addressed pointer the decision receipt links to) so the diagram's APS edge matches what the SDK emits.

[tomjwxf]

Drafted the composition-diagram section here:

#17

I kept it in IMPLEMENTATION_PATTERNS.md rather than the core specification, and framed it generically:

• delegation plane: whose authority allowed the action;
• decision plane: what policy allowed or denied at evaluation time;
• execution plane: what actually went downstream.

The key normative shape is the one we converged on in this thread: planes compose by content-hash reference, not by re-signing or mutating another plane's artifact. The APS / Veritas Acta / ArkForge mapping is included only as an illustrative implementation example, so the pattern stays usable by other implementations.

[aeoess]

@tomjwxf the three-plane split reads correctly against APS, and keeping it in IMPLEMENTATION_PATTERNS.md with the mappings as illustrative is the right call. The pattern should not depend on any one implementation's field names.

The normative line holds on our side too: planes compose by content-hash reference. The decision plane references the delegation plane's artifact by hash. The execution plane references the decision. No plane re-signs or mutates another plane's record. In APS terms a receipt points at the delegation chain root and the policy digest by reference, and verification walks those pointers. It never rewrites the upstream artifact.

One precision for the diagram caption if useful: content-hash reference also means a plane can be verified against the referenced artifacts without requiring a shared signing key or shared trust root across planes. That is the property that lets heterogeneous implementations compose.