Binding type · Agent
Agent binding
Bind an ECZ-ID Agent Credential to one logical agent. The manifest is a discovery artifact. Backend/Core writes the binding. Resolver projects current state.
When to use Agent Credential binding
- You expose a logical agent that takes actions on behalf of an operator.
- A counterparty needs to verify the agent before allowing it to call APIs or MCP tools.
- You need a tamper-evident reference that can be checked at runtime.
One Agent Credential = one logical agent
One Agent Credential represents one logical agent. Copied JSON does not copy trust.
What "one logical agent" means in practice
- One support agent persona = one Agent Credential, regardless of how many replicas serve it.
- Dev / staging / prod environments can be metadata on the same Agent Credential only if they represent the same logical agent.
- A separate logical agent (different role, different trust scope) requires a separate Agent Credential.
What the agent binding records
- Authorised origin for the agent.
- Agent manifest at /.well-known/ecz-agent.json on that origin.
- Manifest hash for tamper-evident discovery.
- Keyset / JWKS reference if the agent signs requests.
- MCP server / tool inventory hash where applicable.
- API Passport dependency for any authorised API the agent invokes.
Agent manifest example
Publish at /.well-known/ecz-agent.json on the authorised origin. TrustOps generates or guides this manifest during the setup pack.
/.well-known/ecz-agent.json
{
"schema_version": "ecz-agent-json-v1",
"operator_ecz_id": "ECZ-GB-XXXXXX",
"agent_credential_id": "ECZ-GB-XXXXXX::AGENT-4F9Q2A",
"logical_agent_id": "example-support-agent",
"authorised_origin": "https://agent.example.com",
"manifest_url": "https://example.com/.well-known/ecz-agent.json",
"manifest_hash": "sha256:<hash-of-canonical-manifest>",
"jwks_url": "https://example.com/.well-known/jwks.json",
"mcp_servers": [
{ "mcp_server_id": "ECZ-GB-XXXXXX::MCP-9K3R7M", "tool_inventory_hash": "sha256:<hash>" }
],
"api_dependencies": [
{ "api_passport_id": "ECZ-GB-XXXXXX::API-2Q7X9B" }
],
"resolver_url": "https://resolver.ecocitizenz.org/p/ECZ-GB-XXXXXX/AGENT/4F9Q2A"
}API dependency rule
If the agent invokes one or more APIs on behalf of the operator, an API Passport dependency must be declared in the manifest and Resolver must project a BOUND state for that API Passport.
MCP relationship
Where the agent uses MCP tools, the MCP server identity and tool inventory hash may be attached to the agent binding so verifiers can check posture before any high-risk tool call.
What Resolver can safely show
- Current state of the Agent Credential binding (BOUND / unsafe).
- Operator ECZ-ID the credential is bound to.
- Authorised origin and manifest hash observed by Backend/Core.
- Whether declared API Passport dependencies are themselves currently BOUND.
What Resolver never claims
- That the agent is safe, certified, approved, or compliance-guaranteed.
- That the agent will behave correctly in any specific transaction.
- That ECZ-ID indemnifies, insures, or endorses the agent.
ECZ-ID keeps setup, verification state, and public proof separated by design. TrustOps handles setup. Resolver remains the public proof surface. Re-check before reliance.
