Before a new AI tool touches your data, somebody has to decide whether it should

The question nobody owns

Most software procurement has a settled shape: a vendor review, a security questionnaire, a data processing agreement, a decision somebody signs. AI tools arrived faster than that process could adapt, and a great many of them were never put through it at all. An engineer installs a coding assistant because it makes Tuesday faster. A researcher signs up for an agent that reads and drafts from company documents. Nobody files a form, because nobody thinks of trying a tool as a decision that needs one.

It is a decision. An AI tool with access to your code, your documents or your systems is not a productivity feature bolted onto a familiar risk profile. It is a new party with standing access to material you would not hand a stranger, run by a company whose incentives are its own, updated on a schedule you do not control, and increasingly capable of acting rather than only answering. Treating that as an IT preference rather than a governance decision is how organisations end up owning an AI estate nobody actually chose.

What we assess

We evaluate a specific tool against a defined standard before it is admitted, and set the terms under which it operates once it is. The assessment has three parts.

Security postureDoes the tool itself introduce risk

Known vulnerabilities, the vendor's disclosure and patching record, what the tool can reach on the machine or account it runs from, and whether its default configuration is safe or merely convenient.

Data and IP exposureWhat leaves, and what could be reconstructed from it

What the tool sends back to its provider by design, what a provider's stated data-handling policy actually commits to, and, distinctly, whether sustained, high-volume use of the tool could let a third party approximate proprietary capability from the pattern of interactions, whether or not any single interaction discloses anything sensitive on its own.

Provider incidence and incentiveWho else the provider answers to, and what else it does

Whether the provider competes in, or could plausibly enter, the client's own market, whether it is subject to jurisdictional pressure that could affect its handling of the client's data, and whether it has a documented history of monitoring practices that exceeded what it disclosed.

None of these questions has a generic answer. A tool that is a clear admit for a marketing team drafting public copy can be a clear decline for an engineering team working on unreleased architecture, and the assessment is written to be repeated, not performed once and filed away.

The decision, not just the checklist

The assessment ends in one of three decisions, each with its own consequence, not a risk score left for someone else to interpret.

Admit

The tool is brought onto the register described in AI governance and ownership, with a named owner, a scoped identity, and a written list of what it may reach.

Admit with restriction

The tool is usable, but not against a defined category of material: no unreleased code, no material non-public information, no regulated personal data, enforced by the access boundary rather than by a policy people are trusted to remember.

Decline

The tool is not admitted, with the reason recorded and revisited on a schedule, because a provider's posture, security record or incentives can change in either direction.

Enforcement without surveillance

A decision that cannot be enforced is a memo. Enforcing an access boundary means the tool itself is technically prevented from reaching what it should not, through scoped credentials, network controls and data-loss rules, rather than left to the honour system. That machinery inevitably produces telemetry, and the telemetry is where a well-intended control can go further than it should.

We design enforcement to answer a narrow question well rather than a broad question badly: is this tool doing what it was admitted to do, on the data it was admitted to touch. That means logging what a tool attempted and whether the boundary held, not the content of what a person asked it or wrote. It means the signal an access boundary raises is an event about the tool's behaviour, not a profile of the individual using it, and it means being explicit, in writing, about what the monitoring does not do: it does not infer who someone is, where they are connecting from, or what team or nationality they belong to, unless that is the specific, disclosed purpose the organisation has decided to build for. A control that quietly grows from enforcing a technical boundary into surveilling the people behind it has solved a narrower problem by creating a much larger one, and it tends to be discovered by the people it was used against, at the worst possible time.

Why this is live now

The pressure behind this standard is not hypothetical. Through 2026, at least one large technology employer reportedly restricted staff use of a widely adopted AI coding assistant after classifying it as high-risk software, and the assistant's own provider has separately alleged, without independent verification available at the time of writing, that a large-scale pattern of automated use by another company amounted to an attempt to reproduce its model's capability from the outside. In the same period, an access-enforcement mechanism built to catch that kind of abuse was reported, in an unverified account, to have inspected connection metadata in a way that read to some users as surveillance rather than security, and the provider is reported to have since narrowed the mechanism. None of these specific claims can be independently confirmed from public reporting alone, and we treat them here as illustrations of a live tension rather than as settled fact. The tension itself is real regardless of how any one dispute resolves: a provider has a legitimate interest in protecting its own model from being copied through sustained use of its tool, and an enterprise admitting that tool has an equally legitimate interest in knowing exactly what the provider's enforcement of that interest is allowed to see. Assessing a tool before admission, and designing its enforcement deliberately rather than accepting a vendor's default, is how an organisation gets to answer that question on its own terms instead of finding out the answer from a support ticket or a headline.

Where this connects

Admission is the gate; what happens afterwards is the ongoing discipline set out in AI governance and ownership, where an admitted tool joins the live register, gets a named owner and a scoped identity, and is evaluated for quiet failure like anything else in the estate. Keeping that admission decision current as a provider's posture, security record or product scope changes is part of managed AI and technology. And where the tool in question is itself a model rather than an application built on one, the same questions about who controls the weights, the data and the resulting advantage connect to how we choose and combine models in the first place.