Microsoft Agent Framework
A resolvable identity for agents built on Microsoft Agent Framework.
Publish the agent's ECZ-ID alongside the workload identity it already runs under. The two answer different questions and neither replaces the other.
- From
- Microsoft
- Languages
- .NET, Python
- Integration
- Works today — no library required
- Passport
- £0 — no card required, permanent
What one Passport covers
One logical agent — including on Microsoft Agent Framework.
The subject is the agent, not the deployment
Versions, deployments, replicas, regions and platforms of that agent are not separate Passports. The test is whether it is a distinct thing your organisation operates — not how many processes, containers or regions it happens to occupy this quarter.
The runtime is not the subject either
A Passport identifies your agent, not Microsoft Agent Framework and not the model behind it. Rewrite the agent on a different framework and the identifier is unchanged, because the thing it names has not changed.
Someone has to stand behind it
Every Agent Passport is linked to the organisation that operates the agent — its Parent. That relationship is the point: an agent identity with no accountable operator behind it answers nothing worth asking.
How you publish it
A file you serve, not a library you take on.
Claim the identity
One sign-in issues a permanent ECZ-ID for the agent and puts your organisation on the record as its operator. £0, no card required.
Serve one static file
Publish the record at /.well-known/ecz-agent.json on a surface the agent already exposes. Publish the agent's ECZ-ID alongside the workload identity it already runs under. The two answer different questions and neither replaces the other.
Anyone can read it
A counterparty who finds the file has an identifier they can resolve without asking you for anything. Public Resolver reads and public machine-readable records are never metered, never authenticated and never counted against any allowance.
/.well-known/ecz-agent.json
Illustrative shape — not the schema
{
"ecz_id": "ECZ-GB-XXXXXX::AGENT_PASSPORT-YYYYYY"
}The identifier is the declaration. Everything else — the operator, the current published state, the declared bindings, and the list of things the record explicitly does not establish — lives on the record itself rather than in a file you maintain by hand. That is deliberate: a copy kept in your repository would go stale the moment anything changed, and nobody reading it would know.
The record, for people
https://resolver.ecocitizenz.org/p/ECZ-GB-XXXXXX%3A%3AAGENT_PASSPORT-YYYYYY
The record, for machines
https://api.ecocitizenz.com/api/p/ECZ-GB-XXXXXX%3A%3AAGENT_PASSPORT-YYYYYY.json
The identifiers above use the placeholder form ECZ-GB-XXXXXX::AGENT_PASSPORT-YYYYYY and resolve to no record. The canonical schema for the well-known file, including any field not shown here, is published on the Developer Gateway rather than restated on this page.
There is nothing to install, and we are not going to invent one.
No ECZ-ID client library, plugin or Microsoft Agent Framework integration package is published today, so this page shows no install command and no import. Nothing here asks you to add a dependency, pin a version or change a single line inside the agent loop. If a library is published later it will appear on the Developer Gateway(opens in a new tab — developers.ecocitizenz.com) first.
On this runtime
Where an ECZ-ID sits beside Microsoft Agent Framework.
It works alongside what you already run
ECZ-ID works alongside your agent framework, OAuth, native IAM and workload identity. It does not replace any of them.
It is not in the execution path
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 that none of them do
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.
Boundaries
What an ECZ-ID does not do on Microsoft Agent Framework.
It does not verify the agent
A VERIFIED or ASSURED Parent does not verify the agent. The parent organisation's identity is verified. The machine is not. An agent linked to a VERIFIED Parent is described exactly that way — linked to a VERIFIED Parent — never as a verified agent.
DECLARED is not a check
DECLARED does not mean independently verified. It records what an organisation says about itself, with the date it said it — not the outcome of a check.
A Passport is not a Credential
An Agent Passport is not an Agent Credential. The Passport is identity: who this agent is, who operates it, and what is published about it. A Credential is a separate, specialist strengthening product with its own evidence and its own scope.
The record is not a verdict
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.
An absent record is not a finding
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.
It says nothing about behaviour
The record publishes who operates the agent and what is declared about it. It does not read your prompts, your traffic or your tools, it grants and withholds no permission, and it makes no statement about what the agent will do next.
An ECZ-ID does not make an agent safe, certified, approved or compliant, and buying one does not make you compliant with anything.
Next
Get the identity first. Wire it in second.
Running agents on more than one runtime?
The route is the same on all of them, which is the point of publishing a file rather than shipping a dependency.