Developer Gateway · Agents hub
Agents on ECZ-ID
Resolve the agent. Re-check before reliance. ECZ-ID gives autonomous agents and the platforms relying on them a resolver-first way to verify operator identity, agent authority, dependencies, and current state — before high-risk use.
What agent trust on ECZ-ID is
An Agent Credential ties one logical agent to one accountable operator, declares its API and MCP dependencies, and lets a relying party verify current state in the public Resolver before allowing the agent to act.
Role split
- 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 acquisition, setup, payment, and lifecycle.
- Resolver remains the public proof surface for current state.
- Developer Gateway documents and routes.
- External subscription or commerce surfaces handle acquisition only — they cannot create or change verification state.
Agent pages on Developer Gateway
- ECZ-ID Agent Credential Entry Pack™ — resolver-identifiable agent identity floor.
- KYA Starter™ — low-friction Know-Your-Agent starter proof.
- Verified KYA Ready Pack™ — business-ready KYA proof path.
- Assured KYA Ready Pack™ — high-reliance KYA proof path.
- Receiving-agent workflow — how a relying agent or platform consumes an Agent Action Envelope.
- Fail-closed verification — when the verifier blocks the call.
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.