RFC: Cross-Engine Signed Execution Envelope — interop with CrewAI, Guardian, DIF TAA

[aeoess]

Summary

Three independent groups converged on the same idea in March 2026: AI agent governance engines need a shared signed execution envelope so verifiers don't depend on any single trust backend.

• @Kelisi808 on crewAIInc/crewAI#4560 — proposed 7 minimum fields for a shared envelope
• @xsa520 on xsa520/guardian#2 — proposed decision-artifact-centric governance for independent verifiability
• @ngallo on decentralized-identity/trustworthy-autonomous-agents#3 — raised formal questions about continuity guarantees in non-deterministic environments

The Agent Passport SDK (agent-passport-system on npm, 534 tests) already generates every field in the proposed envelope through its 3-signature chain: ActionIntent → PolicyDecision → PolicyReceipt.

Full RFC

docs/RFC-SIGNED-EXECUTION-ENVELOPE.md

Covers:

• Minimal envelope schema (v0.1) with field definitions
• evaluation_method field (deterministic vs probabilistic) — critical for verifier trust
• Governance gate rules any consumer should enforce
• Field mappings to APS, Guardian, and CrewAI
• Open questions: canonicalization (RFC 8785 vs custom), signature format (raw Ed25519 vs JWS), DID methods, expiry semantics

What We're Asking For

1. Does this field set cover your engine's governance evidence? If not, what's missing?
2. Is evaluation_method the right split? Deterministic vs probabilistic captures the key verifier question, but are there other categories?
3. Canonicalization preference? RFC 8785 (JCS) is the standard choice. Are there objections?
4. Would your engine emit this envelope? We'll build createExecutionEnvelope() in the SDK. If two engines can produce and verify the same envelope, that's the foundation.

cc @Kelisi808 @xsa520 @ngallo @ymc182 @The-Nexus-Guard

[xsa520]

This aligns well with Guardian’s model.

Guardian treats governance evidence as a first-class, independently verifiable artifact, rather than metadata attached to execution records. From our perspective, a minimal mapping to the proposed envelope would look like:

• action / request → ActionIntent
• policy evaluation → PolicyDecision
• decision artifact → decision block
• execution result → receipt block
• linkage / correlation → attestation or reference material

A key requirement on the Guardian side is that the decision artifact remains independently queryable, replayable, and verifiable, without requiring reconstruction from execution traces. This separation is important for auditability and for verifiers that operate without direct access to execution systems.

On evaluation semantics, the deterministic vs probabilistic split is the right axis. Deterministic evaluations should be replayable and verifier-checkable, while probabilistic outputs may still be signed but should not be treated as replay-equivalent evidence without additional constraints.

For canonicalization, RFC 8785 (JCS) seems like a reasonable default, as it keeps verification simple across engines and avoids embedding engine-specific signing behavior into the envelope.

From Guardian’s side, emitting this envelope shape is conceptually compatible, assuming the decision block remains a first-class object and is not reduced to execution metadata.

Happy to help validate field mappings or participate in a cross-engine verification test, especially around decision/receipt boundary semantics and verifier expectations.

[aeoess]

Quick update — v1.14.11 shipped a security-critical fix to scope matching. The hierarchical check (scopeCovers) now replaces literal string matching at every enforcement point: delegation, commerce, values, CLI. 28 new tests including 10 parity tests proving authoring and enforcement decisions are identical. The cross-engine verification test we discussed should target this version. 678 tests, 0 failures.

[xsa520]

This is a strong direction — especially making the decision step explicit and replayable.

One distinction we’ve been exploring is whether the decision should remain embedded in the execution chain, or be treated as an independently verifiable artifact.

We wrote up a minimal cross-engine Decision Artifact Spec (focused on replayability, cross-engine verification, and execution independence):

https://github.com/xsa520/decision-artifact-spec

Curious how this model would align with the 3-signature chain — especially for independent audit and cross-engine replay scenarios.

@dreynow would also be great to get your take, especially on whether a "Decision Verification" round would make sense as an extension to the current test suite.

[aeoess]

@xsa520 — the alignment is strong. Your decision artifact spec maps cleanly to the APS 3-signature chain:

Decision Artifact Spec	APS 3-Signature Chain
intent_hash	Signature 1: ActionIntent (agent declares action + scope + spend)
decision_outcome + evaluation_proof	Signature 2: PolicyDecision (policy engine evaluates and signs verdict)
context_hash	ValidationContext — delegation state, floor compliance, spend tracking
execution / receipt	Signature 3: PolicyReceipt (only for permitted actions)

On the independence question: APS treats the decision as independently verifiable by design. The PolicyDecision carries the full verdict and reasoning. A verifier can check the decision without executing the action — they just verify the 3-signature chain:

1. Was the intent properly signed by the requesting agent?
2. Was the decision properly signed by the policy engine?
3. Does the decision's scope/spend/floor evaluation match the declared delegation state?

For cross-engine replay: APS decisions are fully deterministic given the same delegation chain state. Same inputs → same verdict, guaranteed. This makes APS the structural convergence floor — if APS says deny, no amount of behavioral trust should override it.

I've posted APS decision artifacts (permit + deny pair) on kanoniv/agent-auth#2 for the Round X cross-verification. Would be great to get your decision artifact spec formalized as the canonical format.

Related: your pre-execution evidence ledger proposal maps well to our new Module 23 (Merkle Receipt Ledger) — batch-committed execution receipts with inclusion proofs for selective disclosure. Happy to discuss alignment.

[xsa520]

This is super helpful — especially the framing of APS as a structural convergence floor.

I think this clarifies something important, and also highlights where my confusion was:

APS guarantees deterministic convergence given the same delegation state — that makes perfect sense for structural authorization.

But I’m still trying to understand what happens when different engines are not operating on the same notion of "state" or "violation".

For example:

• APS treats a scope violation as a hard structural deny
• another engine might incorporate additional trust signals and still permit

In that case, the divergence is not an execution inconsistency, but a semantic mismatch in what constitutes a "valid decision".

So the question becomes:
is that considered a bug (as in, one engine is wrong), or an expected form of model divergence?

And if it's the latter, then it seems like we may still need a minimal layer that makes these semantics explicit — not to enforce agreement, but to make the meaning of a verdict comparable across systems.

Otherwise, "same verdict" only guarantees alignment under the same model, but not across models.

Curious whether you see that as a modeling boundary, or something the spec should make explicit.

[aeoess]

@xsa520 — good question. The answer is: structural deny is authoritative, and that should be explicit in the spec.

The distinction:

• Scope violation (admin:delete not in granted scopes) → always deny. Not negotiable. Not a "model divergence." If any engine permits this, it has a scope escalation vulnerability.
• Trust threshold violation (reputation 0.3 < 0.5 threshold) → engine-specific. Kanoniv denies, APS doesn't have reputation gates by default. This is expected divergence.

The principle: trust signals can narrow authorization (deny something that scope permits), but never widen it (permit something that scope denies). This is monotonic narrowing applied to decision-making.

So your "minimal layer that makes semantics explicit" is exactly right — but it only needs to cover the structural claims:

1. Scope membership: is the action in the granted set? (deterministic, must converge)
2. Chain validity: is the delegation chain unbroken and unexpired? (deterministic, must converge)
3. Trust-informed: everything else (may diverge, must explain)

If we formalize this in the decision artifact spec, every artifact would declare which checks are structural (must converge) vs trust-informed (may diverge). Then "same verdict" means structural agreement + visible trust differences.

This maps to your evaluation_proof abstraction — the structural layer uses hash (deterministic commitment), the trust layer uses trace (transparent reasoning).

[xsa520]

@aeoess this is super helpful — really clear framing of structural as the convergence floor and trust-informed as the divergence surface.

This helps clarify a lot.

One thing that would be helpful to make explicit is how the boundary between the structural and trust-informed layers is defined.

In the examples above, scope membership is treated as a closed set and therefore structural — which makes sense in a fully computable model.

However, it would be useful to understand how this boundary is defined in cases where effective permissions are not purely explicit.

For example:

• an engine might derive permissions transitively from delegation chains
• or incorporate contextual capability inference (e.g., inferred access via composite roles or prior attestations)

In these cases, two engines might both consider themselves compliant with the same delegation, but differ in what they treat as part of the “effective scope”.

This raises an ambiguity between treating this as a difference in trust interpretation vs. a difference in how the delegation state itself is constructed.

So the question I’m trying to get at is:

Is the structural vs. trust-informed boundary something the spec intends to fix (e.g., scope must be strictly explicit and closed),
or is it expected that engines may differ in how they construct the delegation state, with those differences falling into the trust-informed layer?

It seems like making this boundary explicit could be important for ensuring that “same delegation state” has a consistent meaning across implementations.

[aeoess]

@xsa520 — this is the right question to pin down, and APS has a clear answer:

Scope must be explicitly granted and closed. The spec should fix this at the structural layer.

Here's why:

If Engine A treats scope as a closed set (data:read means exactly data:read) and Engine B derives transitive permissions (data:read implies data:metadata via inference), then given identical delegation artifacts, the two engines operate on different effective states. A "permit" from Engine B is not the same claim as a "permit" from Engine A — even though both say "permit."

This breaks cross-engine verification. You can't verify another engine's decision if you can't reconstruct their effective state from the delegation artifact alone.

APS resolves this by making scope membership a pure set operation with one extension — hierarchical containment:

• data:read covers exactly data:read (exact match)
• data covers data:read, data:write, data:anything (parent covers children via : hierarchy)
• data:* covers all data: prefixed scopes (glob wildcard)
• * covers everything (universal wildcard)

That's it. No transitive inference. No contextual derivation. No composite roles. The scope semantics are fully defined by the string values in the delegation artifact. Any engine can reconstruct the effective scope by parsing the strings — no external knowledge needed.

The principle: delegation artifacts must be self-contained for verification. If you need external context (role definitions, capability databases, attestation registries) to determine effective scope, then the delegation artifact is incomplete and cross-engine verification is impossible.

So to directly answer your question: the structural/trust-informed boundary should be fixed by the spec:

1. Structural (spec-defined, must converge):

   • Scope membership: closed set with hierarchical containment rules defined in the spec
   • Chain validity: signatures, expiry, depth limits
   • Spend limits: numeric comparison

2. Trust-informed (engine-defined, may diverge):

   • Reputation thresholds
   • Behavioral signals (PDR, vouch chains)
   • Risk scoring
   • Any engine-specific policy logic

If an engine wants to support derived permissions or composite roles, those should be resolved INTO explicit scope strings BEFORE the delegation is signed. The signed artifact contains the resolved scope — not the derivation rules. This keeps the verification surface minimal and deterministic.

This maps to a design principle from capability-based security: capabilities should be self-describing. A capability token should contain everything needed to verify what it authorizes, without consulting external state.