Skip to content

Enterprise and platform

Tell us the requirement first.

Above the published tiers, arrangements are made by negotiation rather than by self-serve. We do not build a bespoke fork of an identity system without a real, identified need behind it — a private variant is a permanent obligation, and one built speculatively decays until it is worse than nothing.

So this page is not a pitch. It is the list of things worth knowing before either of us spends time, and the address to send them to.

Who this is for

Four positions where the identity question changes shape.

Not because the record is different at scale — it is not — but because the reason you need it, and the systems it has to reach, are.

Platforms

You host or orchestrate agents that other organisations operate. The identity question is not yours alone — it is one you have to answer on behalf of every tenant, and the answer has to be readable by their counterparties, not only inside your platform.

Insurers and underwriters

You are being asked to price exposure created by software that acts. A persistent identifier with a named operator behind it is a fact you can attach a file to. What that fact is worth in your model is your decision.

Procurement and vendor risk

You assess suppliers who now ship agents inside their products. The useful question is not whether a supplier claims something, but whether what they claim is published somewhere you can re-check without asking them again.

OEMs and embedders

You embed an agent in a product you sell onward. The agent has an operator, and at some point a customer or a regulator will ask who that is. Deciding it deliberately is easier than discovering it under pressure.

The Requirement Profile

Eight things to prepare before you write to us.

Send these and you will usually get a real answer in one reply instead of a discovery call. Approximate numbers are fine — the shape of the estate matters more than its exact size.

Check the published ladder before you read any further.

The published Agent capacity ladder runs up to 500 managed bindings at £79.99 a month or £799 a year (≈ 2 months free). If your estate fits inside that, an arrangement is the wrong instrument and we will tell you so. Self-serve capacity is not open yet. These are the published list prices; when a tier opens you will be able to move onto it without your ECZ-ID changing.

Read the published capacity ladder

The eight fields of an enterprise Requirement Profile, what to tell us in each, and why each one changes the answer
FieldWhat to tell usWhy it changes the answer
Estate sizeHow many logical agents you operate, how many managed bindings those agents have across deployments, platforms and regions today, and the direction of travel over the next twelve months.The published ladder is an absolute total, not an increment. If your estate fits inside a published tier there is nothing to negotiate, and that is the answer you should get.
Identity familiesAgent only, or Agent plus MCP, API, SDK, or Service and Workload.Each family is a separate subject with its own allowance. An estate that is small in one family and large in another is a different arrangement from one that is uniformly large.
Monitoring cadenceHow often published identity state must be re-evaluated, which changes must raise something, and who or what has to receive it.Free identities get current state on demand, when someone actually asks. A schedule is a different product with a different shape, and the cadence you need decides whether it is one you should wait for.
Evidence volume and retentionRoughly how many identity events a month, how long the record of them must remain retrievable, and in what form you have to hand it to someone else.Retention and export are the two requirements that most often come from your own obligations rather than from ours, so we need yours rather than a general answer.
IntegrationsWhere an identity has to appear: a vendor or supplier register, a CMDB, a policy engine, an API gateway, a catalogue, a marketplace listing. And which way the data has to flow.Reading a public record needs nothing from us — it is unauthenticated and open. Writing into your systems, or receiving from them, is the part that has to be designed.
SLAThe availability and response expectations you are contractually required to meet, and whether you have to pass them through to your own customers.We publish no service-level number on this site, because we would be inventing it. Tell us the one you are held to and we will answer against that rather than around it.
Data handlingResidency constraints, sub-processing constraints, anything that may not leave a jurisdiction, and whether anything you would send us is personal data.ECZ-ID records are public by design, which removes most of this question and sharpens what is left. The part that matters is the material that is not the public record.
Procurement routeVendor onboarding, the security questionnaire you use, the contract vehicle, purchase order and invoicing arrangements, and who signs.This is usually the longest part of the timeline and the easiest to start early. Telling us the route at the beginning is the single biggest thing you can do to shorten it.

The link below opens an email with those eight headings already in the body. There is no form on this site, no lead-capture step, and nothing in front of the address.

Start a Requirement Profile

How an enquiry actually goes

Four steps, and one of them is us telling you to buy nothing.

  1. You send the profile

    Plain email. No form, no qualification call in front of it, and no obligation created by asking.

  2. We say whether you need us

    Most estates are already covered by a published tier. When that is true it is the whole answer, and it takes one reply rather than a proposal.

  3. We scope against your profile

    What already exists, what would have to be built, what is planned and not yet released, and what we are not going to build at all.

  4. Only then, terms

    Allowances, cadence, deployment, data handling and procurement, written against the requirement rather than against a tier sheet.

What you will not find quoted on this page

No service-level number, no named support tier, no certification, no audit, no customer list and no case study. None of those exist to quote, and a page that invented them would be asking you to rely on exactly the kind of unverifiable claim this whole property argues against. Deeper technical reference lives on the Developer Gateway.

Developer Gateway(opens in a new tab — developers.ecocitizenz.com)

Not on the table

Five things no arrangement changes.

These are the parts a negotiation cannot move, and they are the reason an ECZ-ID means the same thing whoever is reading it.

Identity stays free

Identity is free. A Passport is never metered, and issuing one consults no entitlement.

The identifier is fixed

Your ECZ-ID does not change. No arrangement, allowance, cadence or contract term rewrites an identifier, a record or a resolver URL.

Nothing bought verifies an 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.

Public reads stay public

Public Resolver reads and public machine-readable records are never metered, never authenticated and never counted against any allowance.

Capacity is only an allowance

Capacity is an allowance for managed bindings. It is not a second Passport, it never changes an ECZ-ID, and running out never deletes, detaches or unpublishes anything.

An ECZ-ID does not make an agent safe, certified, approved or compliant, and buying one does not make you compliant with anything. That sentence does not soften at any size, and we will not write a variant of it for a private arrangement.

Send the requirement, not the request for a call.

One email, eight headings, and a real answer — including the answer that you already have what you need.