Skip to content

Agent use cases

Where an AI agent needs an identity someone else can check.

Six situations agent operators, builders and reviewers meet today — and, for each, the ECZ-ID Passport, product or page that serves it, and the limit that applies.

£0 · No card required · Permanent, not a trial.

Use case 1

A purchasing agent that buys on your organisation's behalf

Procurement, finance and operations teams deploying agents that order, book or pay.

The situation

An agent places orders, books services or pays suppliers within limits your organisation sets. Each supplier's systems need to know which agent is asking and which organisation stands behind it; your own team needs the limits written down, and each proposed purchase evaluated against them before your systems act.

Without a checkable identity

Suppliers see an API key or an email address, not an accountable organisation, and the agent's limits live only in its configuration, where nobody outside the build team can read them.

What serves it

  • FREE Agent Passport

    A permanent ECZ-ID for the agent, published against your organisation as its accountable operator.

  • ECZ-ID Intent

    The authorised objective, constraints and validity of what the agent may set out to do, authorised by an owner or administrator — nobody authorises their own request.

  • ECZ-ID Intent Control

    Each proposed purchase evaluated against authority, the Intent, policy and optional counterparty context. Decisions are EVALUATED, never ENFORCED.

  • ECZ-ID Receipts

    The receipts your ECZ-ID products create, kept in your Receipts Vault and searchable within the plan's retention period.

  • DCI — Digital Counterparty Infrastructure

    A path, for people and for software, from the agent a supplier meets to the organisation behind it.

  • Business Passport — VERIFIED and ASSURED

    Independent checks of the organisation a supplier is really relying on. A verified organisation never verifies the agent.

The limit: Identifying an agent is not controlling it. ECZ-ID does not authorise, restrict, supervise, pause or stop what an agent does — its operator and the party relying on it stay responsible for that.

Use case 2

A customer-support agent that answers on every channel

Customer-service and digital teams running one assistant across web chat, email and partner platforms.

The situation

One support agent answers on your website, in email and inside partner platforms, and it is updated every few weeks. Customers and partners need to check that the agent in front of them is yours, wherever they meet it, and that it is the same agent they met last month.

Without a checkable identity

Every channel and every release looks like a different bot, and nobody can show a customer which organisation is accountable for the answer they were given.

What serves it

  • FREE Agent Passport

    One agent, one Passport: your customer-support agent keeps one Passport whichever version, deployment or platform it runs on.

  • Badge, QR code and Publish Kit (free)

    A website badge and a QR code that open the live Resolver record, and a Publish Kit for your agent card and website.

  • Cross-platform Agent Identity Integration

    Scoped help, by arrangement, carrying the one identity across the platforms the agent runs on.

  • PulseGuard

    The current state of the agent's public record, evaluated so you see what changed and why before a customer does.

  • ECZ-ID Watch

    Partners who rely on your agent can follow its public record and see what changed — always back to the live Resolver record.

The limit: Versions, deployments, replicas, regions and platforms of that agent are not separate Passports.

Use case 3

An agent receiving a request from another organisation's agent

Platform and integration teams whose agents accept tasks from agents they did not build (A2A).

The situation

Your agent receives a task or a request from an agent it has never met. Before your systems act on it, they need to know which agent is asking and which organisation is accountable for it — from a record neither of you controls, readable by software.

Without a checkable identity

The only evidence is what the calling agent says about itself, and every integration invents its own allow-list.

What serves it

  • Verify an ECZ-ID

    Resolve the calling agent's ECZ-ID: the live public Resolver record, and the same record as machine-readable JSON.

  • Interoperability: A2A, MCP, OAuth, IAM

    Where ECZ-ID sits beside A2A and the systems you already run, and what it does not replace.

  • ECZ-ID Intent Control

    Evaluate the proposed action with counterparty context; the decision is returned to your systems, which decide what happens.

  • ECZ-ID Watch

    Follow the counterparty agents you rely on and see what changed in their public records.

  • ECZ-ID Graph Intelligence

    Follow the published relationships around a counterparty agent — its operator and what it is bound to.

The limit: 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. ECZ-ID tells you what is published and by whom. What that is worth in your context is your policy's decision, not ours.

Use case 4

An enterprise agent inventory, and Know-Your-Agent review

Risk, security, procurement and AI-platform teams in organisations where agents arrived team by team.

The situation

Agents have arrived across teams, platforms and vendors. Risk, security and procurement need one list: which agents exist, who is accountable for each, what each has been delegated, and whether it is still the same agent next quarter.

Without a checkable identity

The inventory is a spreadsheet that is out of date the week it is finished, and Know-Your-Agent questions are answered from memory.

What serves it

The limit: KYA Authority is never a certification, and no ECZ-ID product grants, enforces or revokes what an agent may do.

Use case 5

An agent that calls tools through MCP servers

Agent builders and platform teams whose agents reach tools through MCP servers they, a vendor or a partner operate.

The situation

Your agent calls tools through MCP servers. A reviewer will ask what the agent can reach, who operates each server, and whether the evidence for the agent and for its servers agrees.

Without a checkable identity

The agent and its servers are reviewed separately, or merged into one vague 'system', and nobody can say who is accountable for which part.

What serves it

The limit: A call path is a dependency, not a permission: authority to act is still granted inside your own systems.

Use case 6

An agent vendor answering an enterprise security review

Companies that sell an agent, or a platform that runs agents, into enterprises and regulated buyers.

The situation

Every enterprise customer asks the same things: who operates the agent, what authority it has been delegated, how a change is evidenced, and what they can re-check without asking you.

Without a checkable identity

Each review is a fresh questionnaire answered from scratch, and the answers point at nothing a reviewer can check independently.

What serves it

The limit: The Kit organises evidence; it does not certify the agent as safe or compliant. The reviewer re-checks the live Resolver record before relying on it.