The model
How the model works
Identity is not authority. Authentication is not authority. A permission in your RMM is not a customer's authority. Each of those tells you that a machine exists, or that it may connect — none of them tells you that a named customer agreed it could act for them, or lets that customer check the answer without asking you.
The invariant this page exists to explain
OPERATOR_DELEGATION_SCOPEis a subset ofCUSTOMER_AUTHORITY_SCOPE
What you delegate to a machine is always inside what the customer authorised. Always, with no exception, enforced where the record is written.
The authority model
Two grants, and a hard invariant between them.
Most systems hold one grant: a permission, issued inside a platform, to an account. This model holds two, written at different times by different parties. The customer grants authority to you. You delegate part of it to a named machine. The second is bounded by the first, and that bound is the whole model.
Customer Authority
Granted by the customer
What this customer has authorised: which action classes, on which surfaces, from when, reviewed when, expiring when. It is written as the customer's grant to you, not as a description of what a platform happens to permit, so it stays true when the platform changes.
Operator Delegation
Granted by you, to one machine
What you passed to a specific machine actor under that authority. One delegation, one actor, one parent authority — so the question “under whose authority was this agent acting?” has a single answer with an identifier, rather than an inference drawn from a group membership.
The invariant
OPERATOR_DELEGATION_SCOPEis a subset ofCUSTOMER_AUTHORITY_SCOPE
Operator delegation scope is always a subset of customer authority scope. The check runs on both halves of a scope — the action classes and the named surfaces — and it runs on the write, in the service layer, not in the form that submitted it.
You cannot delegate more than you were given
A delegation carrying an action class or a surface that the customer authority above it does not carry is refused when it is written. Not flagged afterwards, not reported in a weekly digest — refused.
A delegation cannot outlive its parent
A delegation can only be created under an authority that is currently active. There is no path that attaches a machine to an authority which has been suspended, revoked, superseded or expired.
Revoking the authority revokes what sits beneath it
Withdrawing a customer authority cascades to the delegations made under it, and each one records that the cascade is what changed it and which authority caused it.
Narrowing never silently widens
When an authority is replaced by a narrower one, a delegation that still fits inside the new scope is carried across as a new record; a delegation that no longer fits is suspended rather than quietly kept alive.
The invariant is structural, not a report
There is no state of the system in which a delegation is wider than the authority above it, so there is no reconciliation job that finds one and no dashboard that has to be watched for it.
- 01CustomerThe business the work is done for
- 02Customer AuthorityWhat the customer has authorised
- 03MSP / accountable operatorWho is answerable for the machine
- 04Operator DelegationWhat the MSP passed to the machine
- 05Machine actorThe agent, automation or integration
- 06Native identityIts identifier in the system it runs in
- 07Action surfaceThe MCP server, API or console it reaches
- 08EvidenceWhat was referenced, and when
- 09Current stateActive, suspended, revoked, superseded, expired
- 10Independent re-checkThe customer confirms it themselves
Canonical objects
The objects the record is made of.
These are the nouns. They are deliberately few, deliberately boring, and each one has a single job — because an object model that a customer's auditor cannot read in one sitting is not evidence, it is furniture.
| Object | What it is |
|---|---|
| MSP | The accountable operator — your firm, recorded as the party answerable for every machine actor, delegation and evidence reference beneath it. |
| CustomerTenant | One customer of yours, held as an isolated record: no customer record is reachable from another customer's, and the isolation is enforced in the service layer every call passes through rather than in the interface that displays it. |
| MachineActor | An agent, automation or integration that can act — named, typed by what kind of actor it is, and associated with the customers it acts for. |
| NativeIdentityReference | The identifier that actor already carries in the system it runs in, recorded as a reference to that system's identity rather than as a competing identity issued by us. |
| MCPApiSurface | A door the actor can reach — an MCP server, an API or a console — held as its own object so that authority can be scoped to specific surfaces instead of granted in general. |
| CustomerAuthority | What the customer has authorised, recorded as the customer's own grant: a scope of action classes and surfaces, with an effective date and, where they apply, a review date and an expiry. |
| OperatorDelegation | What you, as the operator, passed to one machine actor under one customer authority — always a subset of that authority, never wider than it. |
| ActionClass | The vocabulary a scope is written in — READ, WRITE and ADMIN, with deterministic subclasses permitted underneath — so that a scope written against one vendor's tooling can be compared with a scope written against another's. |
| EvidenceReference | A pointer to material that supports a record, carrying its type, the system it came from, the reference to the record inside that system and, where one exists, a digest of it. |
| ActionEvidenceReference | A reference to a consequential action that a source system recorded, filed against the actor, the authority, the delegation and the surface it happened under, with its action class and its source event reference. |
| LifecycleState | The current state of a record — active, suspended, revoked, superseded or expired — where revocation is terminal and nothing is deleted to achieve it. |
| StateEvent | An append-only entry written on every state change, carrying the state moved from, the state moved to, the time, who or what caused it, whether it was direct or a cascade, and the reason given. |
Why native identifiers are referenced, not replaced
The identity of a machine actor already exists in the system that runs it. Re-issuing it here would create a second identity to keep in step with the first, and the second one would be wrong first. ECZ-ID holds the relationships — authority, delegation, evidence, lifecycle, resolution — and points at the identifiers you already have.
Why the action vocabulary is three words wide
READ, WRITE and ADMIN are coarse on purpose. A scope has to mean the same thing when it is written against an RMM, an MCP server and a mailbox, and it has to be readable by the customer who is being asked to confirm it. Finer subclasses are permitted underneath, provided they are deterministic.
Assurance states
A claim by you and a confirmation by your customer are different objects.
Every authority record carries the basis it rests on, and there are three of them. They are a ladder, never a synonym: each surface that shows an authority also shows which of the three applies to it, including the Evidence Pack and the proof view your customer opens themselves.
01
MSP_DECLARED
You have recorded what you understand the customer to have authorised, with a scope, a time and your firm named against it.
Asserted by
The operator, alone.
What it does not establish
That the customer has seen this wording, or that anything outside your own record supports it.
02
EVIDENCE_REFERENCED
The declaration carries references to the material it rests on — the written authorisation, the export, the contract clause — each pointing at the system that holds it.
Asserted by
The operator, with pointers that someone else can follow.
What it does not establish
That the referenced material has been read and agreed by the customer, or that it says what the record says it says.
03
CUSTOMER_CONFIRMED
The customer answered a confirmation request themselves, and their answer — confirm, request a change, or decline — is recorded against the exact scope they were shown.
Asserted by
The customer, directly.
What it does not establish
That any later or wider scope inherits the answer. A different scope is a different record and needs its own.
The strongest state is not yours to write
An authority can be created as declared or as evidence-referenced. It cannot be created as customer-confirmed: the attempt is rejected as invalid, by the service rather than by convention. That state is reachable only through the customer's own answer, which means it cannot be reached by an operator in a hurry, and it cannot be reached by us.
A confirmation request the client answers directly — confirm, request a change, or decline — without needing an account or a subscription.
Why the ladder is worth the friction
If a declaration and a confirmation are displayed the same way, a reader who cannot tell them apart has to treat every record as the weaker one — so conflating them does not raise the value of your declarations, it destroys the value of your confirmations.
A confirmation is also bound to the version of the scope the customer was shown. Widen the scope afterwards and you have a new record, at the basis you can honestly claim for it, until they answer again.
Lifecycle and revocation
History is kept, and revocation is terminal.
Every grant carries one current state. Changing it appends an event rather than overwriting a row, which is what allows an earlier moment to be answered later — at a renewal, in a questionnaire, or in the reconstruction after an incident when the people who were there have left.
| State | Meaning | Reversible | Rule |
|---|---|---|---|
| ACTIVE | Authority stands and the machine actor may act within it. | Yes | Can be suspended or revoked at any time. |
| SUSPENDED | Authority is paused. Nothing is deleted and the history stays. | Yes | Reinstatement is a recorded event, not a silent restore. |
| REVOKED | Authority is withdrawn. | No | Terminal. A revoked grant is never resurrected — a new grant is a new record with a new identifier. |
| SUPERSEDED | A newer grant replaced this one. | No | The superseded record is retained so that what was true at an earlier time is still answerable. |
| EXPIRED | The grant reached the end of its term. | No | Expiry is recorded as an event with its time, not inferred from a missing row. |
Nothing is deleted
A state change appends an event rather than overwriting a row. The record of the earlier state is what makes the earlier moment answerable.
Revoked is terminal
There is no transition out of a terminal state. A replacement grant is a new record with a new identifier, so a revocation can never be quietly undone by reinstating the same object.
Expiry is an event, not an absence
A grant that reaches its expiry is moved to expired and the move is recorded with its time. Nothing is inferred from a row that stopped appearing.
What was true at time T is answerable
Because every change is an ordered event against a subject, the state of a grant at a past instant is reconstructed from the events rather than remembered by whoever was on shift.
What revoking in ECZ-ID does not do
It does not disable a key, close a session or switch anything off. The credential lives in the system that issued it and that is where it is withdrawn. What ECZ-ID records is that the authority was withdrawn, when, by whom, for what reason, and with what effect on the delegations beneath it — in a form your customer can check without asking you. The record is not the act. It is the answer to the question the act provokes.
How fast can you turn it off, and who can independently verify you did?
Suspension and revocation are recorded events with a time, not a silent change to a permission somewhere. A revoked grant is terminal — it is never resurrected, and a replacement is a new record with a new identifier. Your client can check the current state themselves without asking you and without taking your word for it.
Evidence semantics
A digest proves integrity. It never proves truth.
This is the section most likely to be overstated by a vendor, so it is stated flatly here. An evidence reference is a pointer with a fingerprint attached. It establishes that the thing referenced has not changed since it was referenced, and it establishes which relationship it was filed against. It establishes nothing at all about whether the source system told the truth.
What it holds
- actor_ref
- Which machine actor the source system attributed the event to.
- customer_authority_ref · operator_delegation_ref
- The two grants the event is filed against.
- mcp_api_surface_ref
- The surface the action reached, where the source records one.
- action_class
- READ, WRITE or ADMIN.
- decision_outcome · decision_reason_ref
- What the source system decided, and its own reference for why.
- source_system · source_event_ref
- Where the original record lives, and how to find it there.
- evidence_digest
- A digest of the record that was referenced.
- occurred_at · recorded_at
- When the source says it happened, and when the reference was written. Two separate fields, because they are two separate facts.
What it does not hold, and does not prove
- The telemetry itself. Logs, payloads, traces and console output stay in the system that produced them, under that system's retention and access controls.
- A copy of the source record that could be read here instead of there. The reference points; it does not duplicate.
- Any assurance that the source system recorded the event correctly, completely, or at all when it should have.
- Proof that a machine acted. A Register entry describes a relationship and its state; where an action is claimed, it is the source system's own record that is being pointed at.
- Authority that the two grants did not already carry. Evidence is filed against a delegation; it never creates or widens one.
Telemetry stays where it was produced
We do not ingest your logs and we do not want them. Copying telemetry into a governance record would create a second, staler copy of your customers' operational data, inside a system that has no business holding it, and it would make the record harder to trust rather than easier — because the copy would have to be trusted too.
What a Register entry is, exactly
A record of a relationship and the state it is in: this actor, under this authority, delegated this scope, currently in this state, as of this time. It is not a record that the machine did something. Where an action is claimed, what is being pointed at is the source system's own event — and what is proven is the pointer, not the event.
Boundaries
What ECZ-ID is not
This is the short list, stated plainly, because a governance product that is vague about its boundaries is indistinguishable from one that overreaches.
ECZ-ID does not replace your RMM, PSA, IAM, identity provider, OAuth, Entra, SIEM, SOAR, EDR, MDR, MCP gateway, workflow engine or orchestration platform.
- ECZ-ID does not execute anything in your customers' systems.
- ECZ-ID does not authenticate users or machines.
- ECZ-ID does not monitor, detect or alert on threats.
- ECZ-ID does not block, throttle or intercept a machine action.
- ECZ-ID does not manage endpoints, tickets, contracts or billing.
- ECZ-ID does not certify you as compliant with anything, and buying it does not make you compliant with anything.
ECZ-ID records identity, authority, delegation, state and evidence, and projects a proof your customer can check independently.
Next
Check the model against what the product actually produces.
A model is easy to write and harder to operate. Every line below is a capability claim held in this site's own claims register, sourced to the delivery readiness matrix, and rendered here only while it passes the gate — if a claim is withdrawn, it disappears from this page rather than waiting for someone to remember it.
- A Machine Trust Register listing the machine actors associated with each client, their native identifiers, and the surfaces they reach.Populated by an ECZ-ID operator during the audit, from tested import code. The self-service console is built but is not switched on in production yet.
- A customer authority record stating what the client has authorised, separate from what any system happens to permit.Recorded by an ECZ-ID operator during the audit, on the canonical authority model.
- A confirmation request the client answers directly — confirm, request a change, or decline — without needing an account or a subscription.Issued by an ECZ-ID operator. The page your client answers is built and tested; it is not self-service for you yet.
- Current state for every grant — active, suspended, revoked, superseded or expired — with history retained and revocation treated as terminal.Maintained on the canonical model by an ECZ-ID operator. Self-service state changes are not switched on yet.
- Attention Required: deterministic findings that surface what has changed or lapsed across the client base.Produced by the deterministic rule engine and delivered by an operator. The live queue view is built, not yet switched on.
- An Evidence Pack per client: a versioned document you can hand over at a review, a renewal or an audit.Generated from the canonical record and delivered by an operator.
- Independent re-check: a proof view the client can open themselves, without going through you.Issued by an ECZ-ID operator. ECZ-ID’s own public resolver record is checkable today; customer relationship proofs are not switched on yet.
No signup, and your answers never leave your browser.
If the model does not fit how you operate, that is worth finding out before anyone signs anything. The published exclusions are here.