Insights
Insights
The arguments, their sources, and the questions nobody can answer yet.
This is one page rather than a blog. We have a small number of arguments and they are set out here in full, because an index promising articles that do not exist yet is exactly the kind of promise this product was built to argue against. Every dated fact carries the organisation that published it and a link you can open. Where we are reasoning rather than citing, the text says so.
Where the honest answer is that nobody knows yet — including us — there is a section for it at the end. It is the one we would read first.
The record
The dated shift, and how to check it
Each entry below is a dated public fact, published by the organisation it concerns, with a link so you can check it instead of taking our word for it. The lines marked “why it matters” are our reading of the fact rather than part of it, which is why they are labelled.
28 April 2026
Kaseya introduced an agentic IT management platform, powered by its Kaseya Intelligence engine, at Kaseya Connect Global.
Why it matters — Autonomous execution arrived inside a platform many MSPs already run. Nobody had to choose to adopt it.
Kaseya describes it as “the first agentic IT management platform”; that superlative is the vendor's and is not independently established, so it is not repeated as fact here.
Source: Kaseya press release, “Kaseya Unveils the First Agentic IT Management Platform”, 28 April 2026 · verified 2026-08-13
April 2026
The Microsoft Entra Agent ID platform reached general availability. It provides the identity foundation for AI agents inside an organisation's own Microsoft Entra tenant: an agent identity is a service principal that, in Microsoft's words, “can only be issued tokens in the Microsoft Entra tenant where they're created” and “can't access resources or APIs in other tenants”.
Why it matters — Agent identity became a first-class object with a vendor behind it. Identity is not authority, and a tenant-scoped identity does not travel across the customers you manage.
Agent ID works with agents built on Microsoft and non-Microsoft platforms — the boundary is the tenant, not the vendor. Agent identity blueprints can be multitenant, but each tenant gets its own tenant-local identity and the identities themselves always remain single-tenant.
Source: Microsoft Learn — Microsoft Entra releases and announcements (April 2026 entry); Overview of agent identities in Microsoft Entra · verified 2026-08-13
As at 13 August 2026
The Cyber Security and Resilience (Network and Information Systems) Bill would, if enacted, extend the UK's Network and Information Systems Regulations 2018 to certain managed service providers for the first time. The Bill calls them “relevant managed service providers” and excludes micro and small enterprises, so on the Government's own account only some medium and large providers would come into scope. The Commons passed the Bill on 16 June 2026; it was introduced in the Lords on 17 June 2026 as HL Bill 32 and completed second reading there on 14 July 2026, with committee stage due to begin on 1 September 2026. It has not received Royal Assent and is not yet law.
Why it matters — Legislators are reasoning out loud about providers who hold privileged access into many client estates at once. Whatever the Bill's final shape, that is the same structural fact this product is built around.
Position as at 13 August 2026 — a Bill mid-passage. Check the live record at bills.parliament.uk before relying on it. Nothing in the Bill requires ECZ-ID or any named product.
Source: UK Parliament — Bill 4035 stages record; HL Bill 32 as brought from the Commons; Commons Hansard, 16 June 2026 · verified 2026-08-13
9 July 2026
The ITU announced the ITU-T Focus Group on Trust and Identity for Humans and Agentic AI (FG-TIDA), established by ITU-T Study Group 17 in June 2026. It held its first meeting online on 29 July 2026, with a face-to-face kick-off scheduled for 1–4 December 2026 in Paris.
Why it matters — The question of who a machine acts for is now on the international standards agenda. That makes it a legitimate engineering question rather than a vendor talking point — and it constrains what any single vendor, including us, can claim to own.
An ITU focus group is exploratory pre-standardisation work. It is not an adopted ITU standard and imposes no obligation on anyone.
Source: ITU — ITU-T FG-TIDA official page and ITU Media Centre · verified 2026-08-13
16 July 2026
ConnectWise announced the general availability of the ConnectWise Platform, which unifies ConnectWise PSA, ConnectWise RMM, ScreenConnect, ConnectWise SIEM, automation, orchestration and ConnectWise AI Agents into a single platform.
Why it matters — Machine actors are now in production inside the channel's largest PSA and RMM stack. If you run it, they are in your clients' estates whether or not you deployed them yourself.
Source: ConnectWise press release, 16 July 2026 · verified 2026-08-13
2 August 2026
The transparency obligations in Article 50 of the EU AI Act (Regulation (EU) 2024/1689) have applied since 2 August 2026. They were not postponed by the Digital Omnibus on AI (Regulation (EU) 2026/1744, in force 27 July 2026), which deferred the high-risk requirements in Chapter III to 2 December 2027 for Annex III systems and 2 August 2028 for Annex I systems.
Why it matters — A live obligation, frequently misreported as delayed. It is a transparency duty, not a high-risk one, and it does not name any product.
One transitional exception: for AI systems generating synthetic content placed on the market before 2 August 2026, providers have until 2 December 2026 to comply with the machine-readable marking obligation in Article 50(2). Article 50 sets outcome duties and is technology- and vendor-neutral.
Source: Regulation (EU) 2024/1689 as amended by Regulation (EU) 2026/1744, Official Journal of the European Union · verified 2026-08-13
What is deliberately not on this page
There are striking statistics in this market. We have left them out, because each one reached us through a citation of a citation and we have not read the original.
- Survey figures on how many organisations lack visibility of AI agents, or grant agents more access than humans — Available to us only through secondary citation. §21 requires the primary report, its sample and its method before publication.
- Proportion of professionals who cannot say how fast an AI system could be halted — The strongest single statistic available for this argument, and still secondary. Withheld until the primary report is obtained.
- MSP channel profitability and market-growth figures — Analyst material behind licensing, and definitions of the market vary widely enough that the number changes with the definition.
- Machine-to-human identity ratios — Published ratios differ by roughly an order of magnitude depending on who counts and what they count. The disagreement is the honest finding; a single ratio would misrepresent it.
- Return on investment, payback period, attach rate or margin for this service — No validated data exists for this category. Any figure would be invented, and inventing one is the fastest way to lose a technical reader.
- Customer counts, partner counts, member counts or waitlist numbers — We are early and will not manufacture traction.
How this list is maintained
The rules are enforced in the code that renders this page rather than in a checklist. A claim sourced only to reporting about a primary source is not published, however strong it sounds. A claim carrying a number, a date, a legal status or a named third party is not published without a verification date and a link. And a claim about something still moving — a bill mid-passage, a meeting not yet held — carries a re-verification date, after which it is withheld automatically rather than quietly ageing on the page. If you return one day and an entry has gone, that is the mechanism working.
The failure shape
Why an operator's own records cannot close the question
Every system in your stack records what it did, and that is what each was built to do. The question arriving from a customer, an insurer or a customer's enterprise procurement team is a different one, and it is not answerable from execution records alone — not because those records are poor, but because of what they are records of.
Security engineering has a name for the shape: the confused deputy. A deputy is a system that holds broad privileges of its own and acts on requests from others. It receives a request, performs the action using its own privileges rather than the requester's, and the result is indistinguishable — in the log — from the same action performed for a perfectly entitled requester. Nothing is compromised. No credential is stolen. The log is accurate. What the log does not contain is whether the party who asked was entitled to ask.
An MSP is a deputy by design, and that is the service. You hold privileged access into estates you do not own so that your customers do not have to hold it themselves. A machine actor placed inside that access inherits the shape exactly: it acts with your privileges, on behalf of a customer who does not hold them, at machine frequency rather than at the rate a person would.
Execution records answer “what happened” with precision: this account, this action, this endpoint, this time. The question underneath a supplier assurance request is “under whose authority”, and that is not a property of the action. It is a property of an agreement made before the action, usually in another medium — a conversation, a statement of work, an email confirming a change — and it was never an event inside the executing system, so no amount of care with logging will surface it later.
There is a second limit, and it is not technical. The records belong to the party being asked about. Even a complete and honest execution log is the operator's own account of the operator's own conduct, produced by the operator, on request. That is sufficient right up to the moment it is not: a claim, a dispute, an assessment where the whole of the answer is “our logs show”. The customer is being asked to take your word for it, and in the situations where the question actually matters, taking your word for it is the thing they are trying to avoid having to do.
The fix is structural rather than clever. Record authority separately from execution, before the execution, in a record the customer can confirm themselves. Authority becomes its own object with its own lifecycle — granted, suspended, revoked, superseded, expired — referencing the identifier the machine carries in the system it runs in. Execution records carry on doing precisely what they already do. What changes is that they now have something to be checked against which was written down in advance and confirmed by the other party.
That separation has a limit running in our direction, and we would rather state it than have it discovered. A Register entry never proves that a historical action took place. It proves what was recorded, and when it was recorded. Whether a specific machine did a specific thing at a specific moment is a question for the systems that executed it, and those systems remain the evidence for it. ECZ-ID records and proves authority. It does not execute, block, authenticate or monitor, and a record of authority is not a record of behaviour.
- 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
A number we will not give you
Why counting machine identities does not settle anything
There is a family of statistics in this market comparing how many machine identities an organisation has to how many human ones. They are quoted everywhere, they are genuinely striking, and we publish none of them.
The reason is not modesty about numbers. It is that the published ratios disagree with one another by roughly an order of magnitude, and they disagree because they are not counting the same thing. Include service accounts and you get one figure. Include every short-lived workload credential a container platform mints and destroys within the hour and you get a very different one. Add API keys, certificates, OAuth clients, bots, scheduled tasks and integration users and it moves again. A ratio like that is not primarily a measurement of the world. It is a measurement of a definition.
The disagreement is the finding. If the people who count these things carefully cannot agree within an order of magnitude, then the interesting fact is not the ratio — it is that the machine population of an ordinary organisation is not currently enumerable to a shared definition. That is a stronger argument for keeping a deliberate, per-customer record of the machine actors you have actually put in place than any single ratio could be, and it has the advantage of being true.
It is also why we would not publish a ratio even where one was convenient. To use one honestly we would need the primary report, its sample, its definition of an identity and its method. Without those, quoting it would be a citation of a citation, set in our house style. That is why it appears among the figures this site deliberately withholds, with the reason published next to it rather than left implicit.
The same discipline points back at us. We do not publish counts of our own partners or customers either, and not only because we are early. We would still have to tell you what we were counting, and a number that needs a paragraph of definition before it is honest is doing less work than the paragraph.
The honest register
What we do not know
Everything above is either sourced or reasoned, and labelled as one or the other. This section is neither. These are the open questions our own argument rests on, written down here rather than left for you to discover after you have bought something.
- Whether customers will actually check
- Independent re-check is the part of the model that makes a record worth more than an assertion. Whether a small business, handed a link by its provider, routinely opens it and reads it is unproven. We have built for it and we think pressure from insurers and enterprise buyers will pull it into normal practice — but we cannot show you that it happens as a matter of course, because nothing has been running long enough for anyone to say so.What would settle it — Re-check behaviour across a real partner base over a meaningful period. When we have it we will publish what it says, including if it says we were wrong.
- What this service line is worth
- We do not publish an ROI figure, a payback period or an attach rate for this service. We have no validated data for this category, and we are not going to model one and present it as evidence. If you are shown such a figure — by us or by anyone — ask what it was measured on, and how many customers were in the sample. There is also no comparable service line with published pricing to triangulate against, because the category does not have one yet. That is why partner terms are agreed in writing with each firm rather than published — an absence of data rather than coyness.What would settle it — Partners running the line long enough to have renewal and retention experience, and being willing to let us publish what it showed.
- Whether demand is real at the small-business end
- The demand signals we can point to sit with insurers and with enterprise procurement. The supply-chain duty quoted below places the consideration on the in-scope entity, and the questions travel outward from there to that entity's suppliers, which is how they reach you. We argue from there to the small-business client by proxy: if the question is being asked up the chain, it will be asked down it. That is an inference, and we are labelling it as one, because it is the single assumption this business is most exposed to.What would settle it — Small-business clients raising the question unprompted with their provider, rather than it arriving through a larger customer or an insurer.
- Whether the platform vendors will do this themselves
- The vendors whose platforms carry these machine actors could decide to record customer authority natively. If one of them did it properly, including independent customer re-check, the case for a separate record inside that vendor's estate would be considerably weaker. Our reason for thinking the cross-vendor part is hard for any single vendor is that the record has to span tools the vendor does not own and would not want to vouch for. That is a reason. It is not a proof, and we are not going to dress it up as one.What would settle it — A vendor shipping it across vendors, with a proof the customer can open. We would rather be early to a real question than right about an invented one.
- What the standards work concludes
- So far, the international standards work touching this question is exploratory: pre-standardisation, imposing no obligation on anyone, and entirely capable of reaching conclusions that differ from the model we have built. If it does, we would rather change than argue. A record format that disagrees with the eventual standard would be a worse product, whatever we had already shipped.What would settle it — Published output from that work. Until it exists, nobody — including us — can tell you what interoperable machine authority will finally look like.
- Whether the law lands where the drafts point
- Legislation in this area is tracked here as a position at a verification date, carrying a re-verification date after which the entry is withheld automatically, because a bill mid-passage becomes false without anyone editing it. Whether any particular bill becomes law, and in what shape, we do not know. What we will say plainly is that no instrument requires ECZ-ID: buying this does not make you compliant with anything. If every bill currently before a legislature fell tomorrow, the argument on this page would be unchanged, because one operator holding privileged access into many estates, with machine actors inside them, is a structural fact rather than a legislative one.What would settle it — Royal Assent and a final text, then the transposing detail. Until that exists, treat every dated entry on this site as exactly what it says it is.
The sourced part of the proxy argument
Under Article 21(3) of the NIS 2 Directive (Directive (EU) 2022/2555), essential and important entities must, when considering which supply chain security measures are appropriate, take into account the vulnerabilities specific to each direct supplier and service provider, and the overall quality of products and cybersecurity practices of their suppliers and service providers.
The duty falls on the in-scope entity and applies through national transposing law. Article 21(3) does not itself bring a supplier into scope — but note that Annex I lists managed service providers and managed security service providers as a sector of high criticality, so an MSP may be in scope in its own right under Articles 2 and 3.
Source: Directive (EU) 2022/2555, Article 21(3), Official Journal L 333/80, 27.12.2022 · verified 2026-08-13
This section stays as long as the questions stay open, and it gets updated when they close — including in the direction that is bad for us.
Where to go next
Test the argument against your own estate
Two things on this site are more useful than further reading. Neither is gated and neither asks for an email address.
Who Can Act For Your Clients?
AI, authority and evidence across the client estate — an executive briefing for MSPs and MSSPs.
The first two pages stand alone. If you read nothing else, you will have the decision. The rest is for whoever you forward it to.
Free Machine Trust Check
The same questions applied to your own client estates. Findings, not a score — and where the answer is that you have nothing to record yet, it says so.
No signup. Your answers are evaluated in your browser and are never transmitted.