ECZ-ID Trust MCP for buying organisations
Govern what your AI agents rely on.
Your agents are already calling MCP servers your organisation did not build. ECZ-ID Trust MCP is the identity, authority, evidence and current-state layer that answers three questions about each of those surfaces — who operates it, what it is actually bound to, and whether that is still true today — in a form your agents can read and your reviewers can re-check without asking us.
It is not a gateway, a scanner, a certification or an approval. It does not sit in the execution path and it never decides what your agents are allowed to do. It makes the thing your policy engine needs to decide with — a current, independently resolvable answer — available at the moment of reliance.
Neutral by design. No score. No badge. No approval. Every state is re-checkable at a public URL.
The governance gap
Your agents rely on things nobody in your organisation approved
An MCP server is a dependency that can act. It is added by a developer in an editor, by a platform team in a manifest, or by a model that discovered it at run time. Unlike a library, it is remote, it is operated by someone else, and it can change after you assessed it. Third-party risk processes were built for suppliers you onboard. This is a supplier your software onboards, in seconds, on its own.
Who operates it?
A hostname is not an operator. Behind an MCP endpoint there is a legal entity in a jurisdiction, or there is not — and today most enterprise answers to that question are a screenshot of a marketing page taken by whoever raised the ticket.
What is it bound to?
An operator claiming a domain, an API, a repository or an agent's authority is a claim. A binding you can resolve is a different object. The distinction matters most in exactly the cases where nobody checks it.
Is that still true today?
An assessment is a photograph. Operators get acquired, records get revoked, authority gets superseded, evidence goes stale. The governance question is not “was this fine in March” — it is “is this fine at the moment my agent is about to rely on it”.
No single system in your stack was built to answer all three from outside its own tooling. That is the gap this layer fills — and the only gap it fills.
What you are looking at
One layer, five named surfaces
ECZ-ID Trust MCP is the layer. Everything below is a surface of it, and each does one job. Nothing here is renamed, rebranded or bundled — when a page names a surface, it says which surface it is.
Trust MCP Server
- What it is
- Machine surface. A live Streamable HTTP MCP server, JSON-RPC 2.0, seven tools — six anonymous and read-only, one OAuth2-protected.
- Where
- trust-mcp.ecocitizenz.com/mcp
- Who uses it
- Your agents and MCP hosts
ECZ-ID MCP Verifier
- What it is
- CI/CLI surface. An npm package and a GitHub Action that check a target and return one of eighteen result states.
- Where
- @ecocitizenz/ecz-id-mcp-verifier
- Who uses it
- Your platform and build engineers
ECZ-ID MCP Trust
- What it is
- Editor surface. A VS Code extension that inventories local MCP configuration and detects change.
- Where
- developers.ecocitizenz.com/mcp-trust
- Who uses it
- Your developers
ECZ-ID Resolver
- What it is
- Proof surface. The public, read-only projection. Human page and machine JSON at canonical URLs.
- Where
- resolver.ecocitizenz.org
- Who uses it
- Your reviewers, auditors and anyone you send a link to
TrustOps
- What it is
- Commercial surface. Entitlement, orders and lifecycle. Authoritative for order and payment status.
- Where
- trustops.ecocitizenz.com
- Who uses it
- Your procurement and finance teams
Websites explain. TrustOps operates. Backend truth decides. Resolver proves.
Canonical state is held by the ECZ-ID backend. The Resolver is a read-only projection of it, never a source. The MCP surfaces distribute and explain that projection; they never write it. This website creates no authoritative state of any kind — including when you pay it money.
The boundary, stated first
ECZ-ID is not in the execution path
This is the sentence most likely to be misread on this page, so it is the one we put first.
ECZ-ID does not allow or block anything.
It has no position in the request path between your agent and a third-party MCP server. It cannot permit a call, deny a call, throttle a call or terminate a session. Your gateway, your policy engine, your IdP and your egress controls decide what happens next. They already do, and nothing here changes that.
ECZ-ID answers a question your controls can ask.
Those controls decide well when they have a current, neutral answer about the counterparty, and badly when they do not. The layer's whole job is to make that answer resolvable at the moment of the decision, from outside the vendor's own tooling, by anyone — including your auditor, six months later, without our involvement.
Where the decision is enforced is entirely yours.
Fail closed at the gateway, at the agent framework, in CI before a server is ever added to a manifest, or at all three. We publish states. You write the policy. We are never the party that executed it, and we will never be able to tell you that we were.
The governance primitive
Eight states your agents can be configured to fail closed on
The public resolver payload carries a machine_policy block. Inside it is fail_closed_states: a finite, enumerated list of the conditions under which a machine should stop rather than proceed. It is not advice we wrote for this page. It is a field in the JSON, published on every record, readable without authentication.
This is what makes the layer usable as governance rather than as reassurance. Your AI governance policy can name these states. Your gateway configuration can match on them. Your CI can break a build on them. And because the same names appear in the machine payload, in the ECZ-ID MCP Verifier's result states and in the Trust MCP Server's tool responses, the policy you write in a document and the behaviour you get in a pipeline are describing the same object.
REVOKED
The record has been withdrawn by the authority that issued it.
Reliance has been actively removed, not merely left unrenewed. This is the strongest signal in the set.
SUSPENDED
Reliance is withdrawn for now, pending resolution.
A temporary state is still a current state. Treating it as “probably fine” is the failure mode it exists to prevent.
DEGRADED
The record resolves, but one or more parts of it cannot currently be established.
Partial answers are the hardest to govern by hand. A machine should treat an incomplete answer as an unusable one.
MISMATCH
What resolved does not agree with what was presented.
Someone or something is asserting a relationship the record does not carry. Proceeding here is the case you would least like to explain.
PROOF_UNAVAILABLE
Proof could not be retrieved at the moment of the check.
You did not get an answer. That is different from getting a negative answer, and it is not a reason to assume a positive one.
PUBLIC_PROJECTION_UNAVAILABLE
The public projection surface did not return a projection.
The read surface itself is unavailable. Fail closed here, or your policy silently degrades to no policy whenever ours has a bad day.
ACTIVE_ABUSE_FLAGGED
An abuse state is currently recorded against the record.
A recorded abuse state is a fact about the record, not a judgement about the operator — and it is exactly the fact a high-impact action should not be taken over.
UNKNOWN
No determination could be made.
The honest terminal state. A layer that never returns UNKNOWN is inventing certainty; a policy that does not handle it is inviting it.
The eight names are published in the record. The one-line meanings beside them are our own conservative rendering, not a canonical state dictionary — where the exact semantics matter to a control you are building, read them from the record rather than from this page.
What this list is not
ECZ-ID does not enforce any of these states. It publishes them. Nothing in the layer stops a call, and no configuration you make in your systems is visible to us. If your agent proceeds on a REVOKED record, that happened inside your estate, under your controls, and we will have no record of it.
Fail-closed is a policy your organisation writes. This is the vocabulary it can be written in.
Absence of proof is never rendered as failure
There is deliberately no FAILED_VERIFICATION state anywhere in this layer. The ECZ-ID MCP Verifier distinguishes NO_PUBLIC_RESOLVER_PROOF_FOUND — this operator has published nothing — from PARTIAL_PUBLIC_PROOF_FOUND, and both from REVOKED, which means something was published and has since been withdrawn. PROOF_UNAVAILABLE is different again: it means the check itself did not complete.
Most MCP servers in the world have published no ECZ-ID proof at all. That is a statement about adoption, not about the operator, and the layer will not let itself be read as saying otherwise. If your policy chooses to fail closed on “no proof found”, that is a legitimate and increasingly common procurement stance — but it is your stance, and the tooling will keep reporting the two conditions separately so that your reviewers can see which one they are looking at.
Four of the eight names — REVOKED, SUSPENDED, DEGRADED and MISMATCH — are also result states in the ECZ-ID MCP Verifier, which is how a CI check and a runtime policy can be written against the same words. The verifier's full result set is larger, because a build-time check faces conditions a runtime check does not.
See a real record
Every claim on this page is checkable against a live public record. EcoCitizenz publishes its own: the human page, and the same record as machine JSON.
- resolver.ecocitizenz.org/p/ECZ-GB-RBS1NW (opens in a new tab — resolver.ecocitizenz.org)
- api.ecocitizenz.com/api/p/ECZ-GB-RBS1NW.json (opens in a new tab — api.ecocitizenz.com)
Read it adversarially. When this page was written you would have found, among other things, that the binding state is NO_PUBLIC_PROOF and the agent-trust status is AGENT_CREDENTIAL_MISSING — because we have not issued an agent credential, and the record says so rather than staying quiet about it. That is what this layer looks like when it has nothing flattering to report.
Those two values were read from the record on 23 August 2026 and are quoted here, not fetched. The record is live and can move — including in our favour — so resolve it yourself rather than trusting this paragraph.
What to read
Six fields, and a rule about which reader gets which
The payload separates what a machine should act on from what a human should read. Both lists are published in the record itself, under machine_policy.
machines_should_use
state.lifecycle_statestate.reliance_levelbinding.stateevidence.public_receipt_stateledger.public_receipt_stateagent_trust.status
humans_should_read
reliance.summaryagent_trust.human_copy
The separation is deliberate. A machine acting on prose is a machine acting on ambiguity, and a human reading enum values is a human filling in the gaps with assumptions. So the record carries both, marked, and the layer never asks either reader to interpret the other's field.
Two further fields tell a machine what posture to take rather than what state exists: recommended_machine_action, and high_risk_action, which on a record with no live binding reads FAIL_CLOSED_UNLESS_LIVE_BINDING_AND_EVIDENCE_AVAILABLE. Your policy may of course be stricter. It should not be looser without someone writing down why.
The reliance boundary
What you may rely on, and what you must not infer
Every record publishes both lists. They are fields, not disclaimers — which means a machine can read the limits of its own evidence, and a reviewer can see that the limits were declared by the system rather than negotiated afterwards.
You may rely on
reliance.can_rely_on
record_existenceactive_parent_statecurrent_parent_tierpublic_resolver_visibility
Do not infer
reliance.do_not_infer
legal_namedomain_controlapi_controlrepository_controlwallet_controlasset_controlagent_authorityinsuranceregulatory_approvalsafetycompliancebusiness_qualitylive_operational_monitoring
Read the right-hand list twice. It says that a resolvable ECZ-ID record does not establish that the operator controls the domain you reached them on, that any agent is authorised to act for them, that they are insured, that they are approved by any regulator, that they are safe, that they are compliant, or that anyone is watching their systems right now. Those things may all be true. This record is not the evidence for any of them.
A record that resolves tells you that a record exists, what state it is in, what tier it holds, and that it is publicly visible. Everything else has to be bound, and a binding that has not been published resolves as NO_PUBLIC_PROOF — which is the honest answer, and the one most vendors would have found a way not to give.
This identity has not issued an Agent Credential. Do not infer agent authority from the parent ECZ-ID.
agent_trust.human_copyThat sentence is generated by the record, not by us. An operator having an identity is not the same as an agent having authority to act for that operator, and the layer refuses to let the first be read as the second.
Stack position
What each layer answers — and the question none of them answers
Those systems remain essential, and nothing here says otherwise. What they may not provide on their own is a neutral, independently resolvable view of a counterparty you did not onboard, in a form an external relying party — your auditor, your insurer, your customer — can re-check without depending on your tooling or ours. ECZ-ID's contribution is that independent layer, and only that layer.
ECZ-ID does not replace an identity provider, a gateway or a firewall, and does not aspire to. If a vendor tells you their trust layer removes the need for one of those, ask them which packet it inspects.
For the file
What lands in your reviewer's folder
Security review, third-party risk and procurement all end in the same place: a document someone has to be willing to attach to a decision. Here is what exists, where it lives, and what it explicitly does not establish.
The live record for the counterparty
- Where it lives
- resolver.ecocitizenz.org and the machine JSON URL
- What it is not
- Not an approval, not a score, not a rating
The reliance boundary for that record
- Where it lives
- reliance.can_rely_on and reliance.do_not_infer in the same payload
- What it is not
- Not a warranty about anything on the do-not-infer list
The delivery templates behind our own work
- Where it lives
- Issued with the engagement that produces them, each carrying its own limitations section
- What it is not
- Not a certification scheme and not an audit standard
Corporate and contractual position
- Where it lives
- /terms, /security, /privacy and the footer disclosure
- What it is not
- Not a compliance attestation of any kind
There is no published preview of those templates on this site yet. Publishing one means quoting each template's limitations section on a public page, and we will not do that while the published text could drift from the document a customer actually receives — so for now the templates reach you with the engagement that produces them, and each one states its own limits on its own first page.
What every engagement delivers, and the form each artefact takes
Buyer-side product
State your acceptance policy in a form machines can read
Everything above this line is free to read and free to check. This is the one thing an enterprise buys.
ECZ-ID MCP Policy™
Publish machine-readable buyer-side acceptance policy for MCP surfaces — what your organisation will and will not accept from what it consumes, stated under your own authority.
Best for: Buying organisations consuming third-party MCP surfaces.
Most organisations already have an acceptance policy for MCP surfaces. It exists as a paragraph in a standards document, an opinion held by one architect, and a Slack thread. None of those is readable by the agent that is about to add a server to its manifest.
MCP Policy is the same statement, published under your organisation's own authority, in a form the checking tools can consume: which states you accept, which you fail closed on, what you require before a high-impact action, and what you will not infer. It is your policy, not ours. We do not write it, we do not approve it, and we cannot enforce it.
These packages are not certification, not compliance approval and not a security guarantee; MCP Policy is buyer-side policy that does not replace an identity provider, a gateway or a firewall.
Publishing a policy does not make anyone comply with it. It makes your position checkable, quotable and versioned — which is the difference between a governance control and a governance intention.
The vendor
Who you would be contracting with
A company selling identity and evidence infrastructure that will not disclose its own identity has answered the most important question on the page before you asked it.
- Legal entity
- ECOCITIZENZ LTD
- Company number
- 17348848
- Jurisdiction
- England and Wales, United Kingdom
- Incorporated
- 20 July 2026
- Registered office
- 66 Paul Street, London EC2A 4NA, United Kingdom
- Trading name
- EcoCitizenz
Those fields also appear on our own public record, classified as externally referenced with Companies House named as the source and a checked-on date recorded against each one. We publish them here because a procurement reviewer should not have to resolve an identifier to find out who we are — and we publish the record link because you should be able to check that the two agree.
We are a young company. Incorporation in July 2026 is a fact a reviewer is entitled to weigh, and hiding it would be a worse answer than stating it.
Engagements
Two fixed-price ways to have this done rather than read
Everything above works without buying anything from us: the resolver is public, the verifier is free to use under the ECZ-ID Proprietary Limited-Use License, and the Trust MCP Server's read tools are anonymous. These engagements exist for organisations that want the assessment, the design and the evidence produced by someone who does this full time — with the price published before the conversation.
Enterprise MCP Pilot
A complete, evidence-backed MCP pilot for one enterprise use case — discovery to handover, with the documentation security and procurement actually ask for.
The only engagement in which a rollback is exercised, and it is exercised in a non-production environment only. The Production Evidence Pack it produces includes the procurement appendix, the traceability matrix, the residual-risk register, the negative authorisation test record, the state and authorisation data-flow summary and the change log — the artefacts your reviewers ask for by name.
EMA/ID-JAG Design & Pilot
Enterprise-managed authorization (EMA) and identity-assertion grant (ID-JAG) design for MCP — cross-app access, token exchange and identity boundaries, piloted against your identity provider.
Identity and authorisation design applied to your existing identity infrastructure, piloted against it. This engagement never positions EcoCitizenz as an identity provider — we do not replace, resell or operate yours.
Published totals and milestone schedules. Fixed-scope engagements, not subscriptions — they never convert into one, and buying an engagement never enrols you in a package. Your delivery schedule is confirmed during intake. Payments and order status are handled by TrustOps.
The questions a review board actually asks
Does ECZ-ID sit in our execution path?
No. ECZ-ID does not sit in the execution path and does not allow or block actions. Gateways and policy engines control what happens next; ECZ-ID makes what happened — and who had authority — provable afterwards. The two are complementary.
Is ECZ-ID required by any regulation?
No, and we will not pretend otherwise. No regulation names ECZ-ID, and nothing you buy from us makes your organisation compliant with anything. What the layer provides is the identity, authority and evidence record that makes compliance conversations — and customer, auditor and insurer questions — answerable with something other than assertion.
Do you certify or approve MCP servers?
No. There is no ECZ-ID certification, no approval, no security rating and no score. A record resolves or it does not, and the state it carries is a fact about the record — not a judgement about the operator, their software or their suitability for your use case. That judgement is yours and stays yours.
Are you a security scanner?
No. Nothing in the layer inspects a third party's code, probes their infrastructure or tests them for vulnerabilities. The free Config Check on this site is a separate, passive, client-side tool that reads configuration you paste into your own browser. The trust layer answers identity, authority, evidence and state questions — which is a different question from whether something is secure, and we do not let the two be conflated.
What happens when the resolver is unavailable?
Your policy decides, and this is why PUBLIC_PROJECTION_UNAVAILABLE and PROOF_UNAVAILABLE are separate named states rather than an error. A policy that silently proceeds when the check fails is not a policy. We recommend failing closed on both for high-impact actions, and we recommend testing that path deliberately rather than discovering it during an incident.
Most MCP servers we use have no ECZ-ID record. What does the layer tell us about those?
That no public proof was found — nothing more. NO_PUBLIC_RESOLVER_PROOF_FOUND is not a verdict on the operator, and the layer deliberately has no FAILED_VERIFICATION state, because absence of evidence is not evidence of a problem. Whether “no proof” is acceptable for a given class of action is a policy position your organisation takes. Many organisations start by accepting it for read-only surfaces and refusing it for anything that writes.
If we adopt this, what are we depending on you for?
Read access to a public projection. The resolver is read-only and anonymous, the verifier is a free npm package that can run offline against a cached payload, and six of the seven Trust MCP Server tools require no authentication. Canonical state is held in the ECZ-ID backend; if you need a contractual position on availability rather than a technical one, that belongs in an engagement, not on a marketing page.
Who is EcoCitizenz?
ECOCITIZENZ LTD, company number 17348848, incorporated 20 July 2026, registered office 66 Paul Street, London EC2A 4NA, United Kingdom. Those fields are also on our own public record with Companies House recorded as the source. We are a young company and we state that plainly rather than leaving you to find it out.
What would make this the wrong choice for us?
If your requirement is to block agent behaviour in line, buy a gateway — this is not one. If your requirement is a certificate to put in front of an auditor, no such certificate exists here and we will not manufacture one. If your MCP surface is entirely internal and you already have machine identity across it, the third-party question this layer answers may simply not be your problem yet.
Start by checking something you already rely on
Pick one third-party MCP server your agents call today. Resolve whoever operates it. Read what the record does and does not establish. That exercise takes ten minutes, costs nothing, and will tell you more about your exposure than this page can.
Neutral, resolver-verifiable identity, authority, evidence and current-state infrastructure. No score, no badge, no approval, no gate.