ECZ-ID AGENT TRUST CORRIDOR

Resolve the server. Resolve the agent. Re-check before reliance.

Agents, MCP servers, APIs, tools, packages, and automation surfaces are becoming operational actors. ECZ-ID helps make the accountable operator, target surface, public route, and current proof posture easier to review before machine-mediated work.

This page explains the route. It does not issue credentials, certify safety, approve agents, create checkout, clone Resolver, or write backend truth.

Start Agent / MCP setup Open Resolver Developer Gateway

Agent identity MCP posture API authority Operator context Resolver proof Local policy decides

FIRST FIVE SECONDS

Machine capability is not the same as accountable operation.

Agents can call tools. MCP servers can expose actions. APIs can move data or trigger work. But counterparties, platforms, insurers, procurement teams, and policy engines still need a practical way to ask: who operates this, what surface is being relied on, and where can current public state be re-checked?

For agents

Make agent identity and operator context easier to locate.

ECZ-ID supports a route for making agent identity, operator responsibility, and review context easier to find and re-check through Resolver-linked infrastructure.

Agent Credential KYA Manifest guidance

For MCP servers

Make the accountable server or tool target easier to review.

MCP posture helps reviewers understand accountable operation, authorised origin, manifest posture, and related API or package evidence without claiming ECZ-ID certifies safety.

MCP Verifier MCP Assurance Re-check route

For platforms

Support review, preference, or policy-gated reliance.

ECZ-ID is designed to become easier for agents, tools, platforms, and enterprise teams to review or prefer under their own local policy.

Local policy decides No endorsement claim No checkout clone

CHOOSE THE ROUTE

Four ways into Agent Trust.

This page explains the route. TrustOps starts acquisition and setup. Resolver projects public proof after backend truth exists. Developer Gateway explains how to implement the machine-readable layer.

MCP / tool / API target

I operate an MCP server, tool, package, or API surface.

Start with MCP posture. The goal is to make the accountable operator and target easier to review and re-check, not to claim universal safety.

MCP Verifier MCP Assurance API Passport where relevant

Agent / automation

I operate an agent or automation.

Start with Agent Credential Entry or KYA depending on whether the need is basic resolver-identifiable identity or higher-reliance agent/operator posture.

Agent Credential Entry KYA Starter Verified / Assured KYA

API / action surface

My agent calls APIs or exposes actions.

API authority should not be implied by agent identity alone. Where the agent uses or exposes an API/action surface, the API posture should be handled separately.

API Passport OpenAPI x-ecz-id No copied metadata trust

Reciprocal review

I need to check both sides of an interaction.

Reciprocal reliance means reviewing the agent/operator side and the MCP/tool/server side together. ECZ-ID supports this as a posture route, not as a forced demand system.

Agent side MCP side Re-check before reliance

AGENT + KYA PRODUCT LADDER

Start small. Strengthen when reliance increases.

These are the public Agent and KYA acquisition routes. Product setup, payment, lifecycle, and customer control belong in TrustOps. Public proof belongs in Resolver after backend truth exists.

Agent identity floor

ECZ-ID Agent Credential Entry Pack™

£24.99 /mo

Resolver-identifiable agent identity floor. Not KYA. Not API authority. Not proof of safety.

Start in TrustOps →

KYA starter

KYA Starter™

£34.99 /mo

Starter Know-Your-Agent posture for operators beginning agent accountability setup.

Start in TrustOps →

Verified KYA

Verified KYA Ready Pack™

£149.97 /mo

Business-ready KYA route for agent/operator posture where review friction matters.

Start in TrustOps →

Assured KYA

Assured KYA Ready Pack™

£179.97 /mo

Higher-reliance KYA route for stronger review, policy, and enterprise-facing contexts.

Start in TrustOps →

MCP POSTURE LADDER

MCP is a target posture, not a new passport.

MCP posture routes help MCP servers, tools, packages, providers, and APIs become easier to review and re-check through TrustOps setup and Resolver-linked public proof. They do not create a separate MCP Passport and do not certify universal safety.

Free checker

ECZ-ID MCP Verifier™

Free

Frictionless checking and guidance. No binding required. No certification claim.

Open in TrustOps →

MCP assurance

ECZ-ID MCP Assurance™

£199 /mo

One production MCP target made easier to review through resolver-verifiable posture.

Start in TrustOps →

Provider-grade

ECZ-ID MCP Assurance Plus™

£499 /mo

Provider-grade MCP posture for higher-value targets, dependencies, and review needs.

Start in TrustOps →

Policy-grade

ECZ-ID MCP Policy™

£1,499 /mo

Enterprise policy/export posture for policy-gated review and operational governance.

Start in TrustOps →

HOW THE ROUTE WORKS

Explain, start setup, bind, prove, re-check.

This keeps .com in its correct role: explanation and conversion routing. It does not sell directly, write truth, clone Resolver, or activate proof.

Learn

.com explains the corridor, the use cases, the product ladder, and the proof boundaries.

Start

TrustOps handles acquisition, setup, payment, lifecycle, and customer control.

Bind

Backend/Core owns canonical binding and entitlement truth. TrustOps displays state but does not decide it locally.

Prove

Resolver projects public read-only state and machine-readable proof after backend truth exists.

Re-check

Agents, tools, platforms, insurers, and counterparties re-check current state before reliance under their own policy.

MACHINE-READABLE ROUTE

Built for humans, agents, and LLMs.

Agents should not have to scrape vague marketing copy. This page provides explicit, structured route targets for acquisition, proof, implementation, and governance.

Structured public routing summary

{
  "surface": "ecocitizenz.com/pages/agents-mcp-kya",
  "role": "explanation_conversion_routing",
  "primary_action": {
    "label": "Start Agent / MCP setup in TrustOps",
    "url": "https://trustops.ecocitizenz.com/start#mcp-kya-agent-trust"
  },
  "proof_surface": "https://resolver.ecocitizenz.org",
  "implementation_surface": "https://developers.ecocitizenz.com",
  "governance_surface": "https://www.ecocitizenz.org"
}

NO-OVERCLAIM BOUNDARY

What this does not claim.

ECZ-ID helps make operators, agents, MCP targets, APIs, packages, and related surfaces easier to review and re-check. This is not a demand-proof system and not a universal approval layer.

No “AI safety certified” claim. No platform endorsement claim. No guarantee of security, compliance, or fitness. No checkout, payment, or proof activation on .com. No Resolver clone or public directory claim. No autonomous LLM decision-maker inside TrustOps or Resolver. No copied manifest or copied JSON treated as trust. Local policy decides whether to allow, warn, review, prefer, or require proof.

STAKEHOLDER ROUTES

One corridor, many reviewers.

Agent operators

Start with Agent Credential Entry or KYA, then use Developer Gateway for manifest and binding guidance.

MCP providers

Use MCP posture routes to make server, tool, provider, package, repo, or API context easier to review and re-check.

Enterprise policy teams

Use Resolver and machine-readable outputs as inputs to your own Open, Prefer, Review, or Require policies.

Developers

Use Developer Gateway for schemas, route indexes, .well-known files, manifests, and implementation examples.

Insurers and auditors

Use Resolver state and governance surfaces to understand what is publicly projected and what must not be inferred.

Adversarial reviewers

Expect no source upload, no hidden telemetry promise, no proof cloning, and no claim that this page writes truth.

START THE CORRIDOR

Make your agent, MCP target, or machine-action surface easier to review and re-check.

Start in TrustOps for setup and acquisition. Use Resolver for public proof. Use Developer Gateway for implementation. Use .org for governance and specification reference.

Start in TrustOps Check Resolver Open Developer Gateway Governance & specifications