MCP makes tools and data available to AI systems.
But exposing a tool is not the same thing as establishing whether an enterprise should rely on it.
This repository provides a practical, implementation-oriented framework for examining the trust boundaries around an MCP server — including identity, authentication, authorization, discovery metadata, instructions, provenance, secrets, agent attribution, lifecycle state and evidence.
Start here: Run the free MCP readiness check
An MCP integration can work perfectly and still leave important questions unanswered.
Who operates the server?
What identity is being relied upon?
Which agent initiated an action?
What authority did that agent have?
Can server-supplied instructions be distinguished from trusted client policy?
What happens when discovery metadata changes?
Can a relying party determine what server state it relied upon yesterday?
Can access be withdrawn?
Can important actions be reconstructed afterwards?
Those are not all authentication questions.
They are identity, provenance, authority, state and evidence questions.
Use these questions when reviewing an MCP server or enterprise MCP deployment.
- Is the MCP server attributable to a known operator?
- Can the operator identity be independently checked?
- Are production, staging and development identities distinguishable?
- Can ownership or operational responsibility change without becoming invisible to relying parties?
- Is authentication present where appropriate?
- Are long-lived shared secrets avoided where possible?
- Are credentials scoped to their intended resource?
- Are credential expiry and rotation defined?
- Is credential compromise recoverable?
- Is authorization performed independently of authentication?
- Can permissions be constrained by tool or action?
- Can agent permissions differ from human permissions?
- Is least privilege applied?
- Are high-impact actions handled differently?
- Can the server distinguish one agent from another?
- Can an agent be associated with an accountable operator?
- Can delegated authority be represented?
- Can an agent credential be withdrawn without disabling an entire organisation?
- Which server supplied the discovery document?
- When was it observed?
- Which version/state produced it?
- Can changes be detected?
- Can previously relied-upon state be reconstructed?
Server-supplied instructions should not silently acquire the trust level of client or system policy.
Consider separately:
content trust — should this instruction influence the model?
and
source trust — who supplied it, from which server state, and when?
These are different controls.
- What MCP metadata is cached?
- Is cached content isolated appropriately?
- Is provenance retained?
- Is freshness defined?
- What invalidates an entry?
- Can withdrawn or changed server state remain trusted because of a stale cache?
For sensitive operations, can a relying party determine:
- which server exposed the tool;
- which tool/version was invoked;
- which agent requested it;
- which operator stood behind that agent;
- which policy permitted the request?
- Does an agent receive credentials it does not actually require?
- Can downstream service credentials remain server-side?
- Are secrets accidentally included in prompts, logs or tool responses?
- Can credentials be independently revoked?
Identity should not be treated as permanently valid merely because an identifier exists.
Consider:
ACTIVE → SUSPENDED → REVOKED → SUPERSEDED → RETIRED
A relying party should know when its understanding of an MCP server or agent needs to be re-checked.
Can important reliance decisions produce evidence showing:
who → under whose authority → requested what → against which service → under which policy → at what time → with what result?
For high-impact machine actions, logs alone may not be enough.
Trust should not necessarily be established once forever.
Re-check when:
- identity changes;
- credentials rotate;
- authority changes;
- server state changes;
- sensitive actions occur;
- evidence becomes stale;
- a relevant credential is withdrawn.
DISCOVER
↓
IDENTIFY
↓
AUTHENTICATE
↓
CHECK AUTHORITY
↓
VERIFY CURRENT STATE
↓
APPLY LOCAL POLICY
↓
ACT
↓
RECORD EVIDENCE
↓
RE-CHECK WHEN REQUIRED
Authentication is one part of this chain.
It is not the entire chain.
If you're building, operating or reviewing an MCP server, you can use the ECZ-ID MCP readiness path to inspect the implementation from an enterprise trust perspective.
No claim is made that an MCP server must use ECZ-ID, or that every MCP deployment requires the same controls.
The objective is simpler:
make the trust assumptions visible before somebody relies on them.
ECZ-ID explores a broader infrastructure model connecting:
ORGANISATION
↓
OPERATOR
↓
AGENT
↓
AUTHORITY
↓
MCP / API / TOOL
↓
ACTION
↓
EVIDENCE
↓
CURRENT RESOLVABLE STATE
This allows a relying party to ask more than:
“Was the credential valid?”
It can also ask:
“Who was behind this machine action, under what authority, against what resource, and what evidence can be re-checked?”
https://resolver.ecocitizenz.org/passport/ECZ-GB-RBS1NW
ECZ-ID — Identity & Evidence Infrastructure for the Machine Economy
Built by EcoCitizenz Ltd.
This repository provides technical and operational guidance. It does not certify MCP servers, replace local security controls, or constitute legal advice.