Workflow · Receiving agent
Receiving-agent workflow
How a relying agent or platform consumes an Agent Action Envelope before allowing another agent to act. Re-check before reliance. Local policy decides.
Sequence
- 1. Receive the calling agent’s Agent Action Envelope or fetch its manifest reference.
- 2. Resolve the declared parent ECZ-ID and Agent Credential against the public Resolver.
- 3. Read the ResultState and ReasonCodes.
- 4. Apply local policy (OPEN, PREFER, or REQUIRE) to decide allow, warn, or require.
- 5. Re-check Resolver before any subsequent high-risk action.
What the receiving agent must not do
- Do not infer safety from RESOLVER_VERIFIABLE alone.
- Do not treat NO_PUBLIC_RESOLVER_PROOF_FOUND as proof of unsafe.
- Do not mark BOUND on its own surface. Only the canonical authority changes verification state.
- Do not invoke an autonomous LLM/agent decision-maker on behalf of the relying party.
No overclaim posture
- No public resolver proof found yet does not mean unsafe.
- Re-check before reliance.
- Local policy decides.
- The verifier does not create or change verification state.
ECZ-ID separates setup, verification state, and public proof so operators can prepare evidence and relying parties can re-check before they act. TrustOps handles setup. Resolver remains the public proof surface. The verifier does not create or change verification state. Start setup in TrustOps when you operate the target. Share resolver guidance when you do not. Local policy decides. Re-check before reliance.