Skip to content
ECZ-ID Agents
Free Passport

Bindings

Tie the agent's identity to the places it really runs — and say how fresh that is.

A binding connects the agent's ECZ-ID to an asset you control. It starts as your statement, becomes verified when you prove control, and then ages — so the record always says when it was last verified and when its freshness window ends.

Get a FREE Agent PassportOpen your ECZ-ID console(opens in a new tab — trustops.ecocitizenz.com)

£0 · No card required · Permanent, not a trial. Basic bindings are included.

The lifecycle

Passport, bind asset, proof, review, verification, Resolver, operate.

The same seven steps in your console and on the public record.

  1. Passport

    Start from the FREE Agent Passport: one persistent ECZ-ID for the agent, with your organisation on the record as its operator.

  2. Bind asset

    In your ECZ-ID console, add an asset the agent really uses or appears on — the host that serves its manifest, a repository, a registry listing, an API or MCP endpoint you operate. It starts as a declared binding: your statement, labelled as one.

  3. Proof

    Show control of the asset. For an agent host, publish the agent manifest at /.well-known/ecz-agent.json declaring the agent's ECZ-ID; other asset types use the proof your console issues for them.

  4. Review

    The proof is checked against the asset. A failed or incomplete proof leaves the binding declared — it is never silently upgraded.

  5. Verification

    A passing check marks the binding verified, with the moment it was verified. It establishes control of that asset at that time — not the agent's behaviour, not its authority, and not forever.

  6. Resolver

    The binding, how it was established, when it was last verified and when its freshness window ends appear on the public Resolver record and in its machine JSON.

  7. Operate

    Keep the proof in place. Verification ages: ECZ-ID does not renew a bound binding, and once its freshness window ends a new binding is the fresh proof. Nothing is verified permanently.

A verified binding proves control of one asset at the moment it was last verified. It is never permanent, it never verifies the agent itself, and it gives ECZ-ID no control over what the agent does.

The agent manifest

One static file on a host the agent already serves.

Publish /.well-known/ecz-agent.json on the host your agent runs from, declaring its ECZ-ID. It is the proof for that host, and the place other agents and platforms look first.

Where it lives

https://your-agent-host/.well-known/ecz-agent.json

On your host, not on this website — this site serves no agent endpoint and publishes no manifest of its own. ECZ-ID stays outside the execution path. It does not broker your agent's calls, hold its credentials, or sit between it and the systems it uses.

Its schema

Full integration reference, schemas and API documentation live on the Developer Gateway. This property gets you an identity and points you at the right place to wire it in. This page names the path and what it proves; it does not restate the fields.

Developer Gateway(opens in a new tab — developers.ecocitizenz.com)

Freshness

Every verified binding carries its age.

Re-check before reliance. State can change between the moment a badge is drawn and the moment an agent acts.
Last verified
The moment the proof for this binding last passed a check. A time, not a status.
Freshness
How recent that verification is. An old verification is weaker evidence than a recent one, and the record does not pretend otherwise.
Re-check due
When the binding's freshness window ends. After that date, treat the last result as history: ECZ-ID does not renew a bound binding, and a new binding is the fresh proof.
Re-check before reliance
Read the live Resolver record at the moment you rely on it — never a badge, a screenshot or a copy you made earlier.

MCP servers and APIs

Bind what you operate. Relate to what someone else operates.

Authority is delegated by the operator, inside the operator's own systems — OAuth, IAM, MCP and API configuration. ECZ-ID can publish what the operator declares about that delegation; it never grants, enforces or revokes it.

What you operate: bind it

The host that serves the agent's manifest, its repository, its registry listing, and any MCP endpoint or API you run for it. You can prove control of these, so each can become a verified binding — or, for an MCP server or API in its own right, a FREE MCP or API Passport of its own under the same organisation, once that family's free door is open.

What someone else operates: relate to it

An MCP server or API run by another organisation is its own subject with its own operator. Your agent's record can declare that it calls it; that relationship is labelled as declared. Whether that server or API is who it says it is is answered by its own Passport, not by yours.

Neither is a permission

A binding records control of an asset; a relationship records a connection. Neither grants the agent access to anything. Authority to call a server or an API is delegated in your own OAuth, IAM, MCP and API configuration.

Bindings, versions, replicas, endpoints and deployments never consume AEC and never become a second Passport. Identifying an agent is not controlling it. ECZ-ID does not authorise, restrict, supervise, pause or stop what an agent does — its operator and the party relying on it stay responsible for that.

Agents and MCP Read a binding on the Resolver Get told when a binding changes