Interoperability
It sits beside your stack. It never sits inside it.
ECZ-ID works alongside your agent framework, OAuth, native IAM and workload identity. It does not replace any of them. 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.
What it adds is the layer none of those provide: a persistent public identity for the agent itself, tied to a named operator, that someone outside your organisation can resolve and re-check.
The three sentences that matter
Complementary, outside the path, additive.
It complements
ECZ-ID works alongside your agent framework, OAuth, native IAM and workload identity. It does not replace any of them.
It stays out of the way
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.
It adds one thing
What it adds is the layer none of those provide: a persistent public identity for the agent itself, tied to a named operator, that someone outside your organisation can resolve and re-check.
Alongside
What each neighbour does, and what is added beside it.
| Alongside | What it does | What ECZ-ID adds | Replaces it |
|---|---|---|---|
| MCP | Connects an agent to tools and data through a defined server protocol. | A resolvable identity for the agent and, separately, for the MCP server it uses — each with a named operator. | No |
| A2A | Lets agents discover and talk to one another. | A persistent public identity a counterparty agent can resolve and re-check outside the conversation itself. | No |
| OAuth and OIDC | Delegates authorisation and authenticates a principal for a session. | A durable public record of the agent and its operator that outlives any token and is readable by parties who hold none. | No |
| Native IAM and workload identity | Governs what a workload may do inside a cloud account, tenant or cluster. | An identity that is meaningful outside that boundary, to someone with no access to it. | No |
| SPIFFE and service accounts | Issues short-lived workload identity inside infrastructure. | A stable public identifier for the logical agent, rather than a rotating internal one for a running process. | No |
The last column is a field on the data rather than a sentence someone typed. It is false for every row by type, so turning one of these into a replacement claim would mean changing a boolean that a test asserts.
In detail
Five neighbours, described as their own users would describe them.
MCP
Which tools may this agent reach, and through what server?
MCP defines how an agent connects to tools and data through a server. It answers a connection question, and it answers it well. What it does not carry is who operates the server at the other end, or who operates the agent doing the connecting — and those are very often two organisations who have never met.
ECZ-ID adds a resolvable identity on each side of that connection, each with a named operator. It adds nothing to the protocol, defines no new message, and does not sit on the transport.
A2A
Who am I talking to, and does that answer survive the conversation?
A2A lets agents discover one another and interact. The discovery it performs is scoped to the interaction: it reports what an agent presents itself as, at the moment it is asked, on the address it was asked at.
ECZ-ID adds a record that exists outside the conversation and can be resolved and re-checked afterwards, by a party who was never in it. It is not a transport, not a discovery mechanism, and not a replacement for A2A.
OAuth and OIDC
Is this principal authorised for this call, right now?
OAuth delegates authorisation and OIDC authenticates a principal for a session. Both answer their question precisely, and both answer it inside a trust relationship that already exists between two parties, for the lifetime of a token.
ECZ-ID publishes a durable record of the agent and its operator that outlives every token and is readable by parties who hold none. It issues no tokens, validates none, and takes no part in the authorisation decision.
Native IAM and workload identity
What may this workload do inside our account, tenant or cluster?
Entra workload identity, AWS IAM, Google Cloud workload identity federation and their equivalents govern what a workload may do inside a boundary you control. That is the correct home for the question, and ECZ-ID does not attempt to be a second one.
The limit here is scope rather than quality: an IAM role is invisible to a counterparty with no access to your account. The public record is the part they can actually read. Your roles and policies are untouched either way.
SPIFFE and service accounts
Which running process is this, right now, inside the mesh?
SPIFFE and Kubernetes service accounts issue short-lived workload identity to running processes. The rotation is the feature: a credential that changes constantly is harder to steal and reuse, and it is meant for infrastructure that already trusts the issuer.
A rotating internal identifier is the wrong thing to publish outward, and it does not survive a redeploy. ECZ-ID adds one stable public identifier for the logical agent, which does. It issues no workload credentials and rotates nothing.
What ECZ-ID is not
Six things it will never become.
Not a runtime
It does not run, host, schedule or supervise your agent. Nothing about a Passport executes when your agent does.
Not an authorisation system
It grants no permission and denies none. It never appears in an allow or deny decision, and nothing should be built so that a Resolver read gates a call.
Not a gateway
It does not proxy, broker or route traffic. There is no ECZ-ID endpoint between your agent and the systems it uses, and no availability of ours that yours depends on.
Not a secrets store
It holds no keys, tokens or credentials for your agent and asks for none. Everything a Passport publishes is public by design, which is only defensible because none of it is secret.
Not a policy engine
It publishes what is declared and what evidence exists. ECZ-ID tells you what is published and by whom. What that is worth in your context is your policy's decision, not ours.
Not a replacement for A2A or MCP
Those are protocols for how agents connect and converse. This is a record about who the parties are. Dropping either because you hold a Passport would leave your agent unable to do anything at all.
The record is not proof. It publishes what is currently declared and what evidence exists, with the time it was read. Re-check the live record before you rely on it.
A2A Agent Card
This site publishes no Agent Card, on purpose.
An Agent Card is a machine-readable claim
It asserts that an invokable agent exists at an address and describes what it can be asked to do. A machine reader does not weigh that claim the way a person weighs a marketing page. It acts on it.
Publishing one here would be false
A card at this origin would route counterparty agents to an endpoint that answers nothing — and it would do so in precisely the format designed to be trusted without a human ever reading it.
And it would contradict the argument
A property whose entire case is that published claims should be checkable cannot publish an unbacked machine-readable claim about itself. That is the exact failure this site asks its readers to watch for elsewhere.
What this origin does publish for machines
A sitemap, an llms.txt route inventory, and per-page metadata — every entry of which describes a page that genuinely exists. Machine-readable identity records live on the Resolver, against real identifiers, and are never mirrored here.
Read the absence correctly
No public ECZ-ID Passport found is not a safety finding. It means this identifier resolves to no published record — nothing more. Most software has no ECZ-ID yet. The same reading applies here in reverse: no card means no endpoint. It is not a position on A2A, which this property neither competes with nor argues against.
If ECZ-ID ever serves an A2A endpoint, a card will follow that endpoint rather than announce one in advance.
How identity actually gets published
A static file on a surface you already serve.
The well-known path
/.well-known/ecz-agent.json
Provider-neutral and framework-neutral because it is a file rather than a dependency. Nothing to import, nothing to pin, and nothing that breaks when your framework ships a major version.
There is no ECZ-ID agent SDK today
No package name, no install command and no framework plugin is published here, because none is published anywhere yet. 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.
Developer Gateway(opens in a new tab — developers.ecocitizenz.com)
Nothing in your stack has to move for this.
Keep your framework, your gateway, your IAM, your tokens and your mesh exactly as they are. Publish one record beside them, and give a counterparty something they can resolve without an account.