The NCSC Said You Cannot Manage What You Do Not Know. Ten Days Later It Published How to Find Out.

01 Why a survey undercounts

The number everybody is quoting this month comes from one study, and the NCSC blog links straight to it. Censuswide surveyed 2,003 UK employees aged 18 and over in October 2025, commissioned by Microsoft, with at least 100 respondents each from financial services, retail and consumer goods, education and health and social care, and a minimum of 500 from large businesses and 500 from the public sector [ Microsoft / Censuswide 2025 ] . Seven in ten of them, 71%, said they had used unapproved consumer AI tools at work. The figure the NCSC did not quote is the sharper one: 51% carry on doing it every week.

Read the qualifiers before you put that slide in front of a board. The study is UK-only. It measures consumer tools, which is the whole point, since a governed enterprise deployment of the same product is not shadow AI. It is eleven months old today. And Microsoft commissioned it while selling the approved alternative, which does not make it wrong and does mean you should say so out loud.

Now the harder problem. A survey asks people to report themselves, and the NCSC has already explained why that reporting collapses. Its shadow IT guidance, reviewed on 14 August 2026, instructs security teams to “always take a positive and no-blame approach to people who have been forced into adopting shadow IT”, because “if you blame or punish staff, their peers will be reluctant to tell you about their own unsanctioned practices, and you’ll have even less visibility of the potential risks” [ NCSC shadow IT ] . The same page states that “a poor security culture means you’re much less likely to detect shadow IT”. Your internal survey inherits that bias. It counts the confident and misses the cautious.

Reach for a cloud access security broker and you inherit a second bias. The NCSC states the limit in one sentence: a CASB “can help to identify use of unapproved cloud services, although without breaking/intercepting encrypted connections will not be able to identify unapproved use of approved cloud services (i.e. personal accounts) or provide visibility into what users are doing in approved services” [ NCSC shadow IT ] . Personal accounts on approved domains is precisely the case the broker cannot see. The Censuswide sample points at that case directly: 41% said consumer AI at work is what they are used to in their personal life [ Microsoft / Censuswide 2025 ] .

02 The method the NCSC named ten days later

On 17 September 2026 the NCSC published “Adversary simulation: what you need to know”. It is written for the organisations buying the service. Read it as a shadow AI document instead and it answers the question the 7 September blog left open.

Start with who does the looking. In an adversary simulation, “the team undertaking the adversary simulation is responsible for carrying out reconnaissance activity on the customer’s organisation to inform their attack plans, rather than using commercially-procured threat intelligence and threat scenarios to drive the approach” [ NCSC adversary simulation ] . Through that activity, the team “develops an understanding of the customer organisation’s technology, exposure, and threat landscape”. Exposure is the word doing the work. Nobody hands the team an inventory, because building one is the job.

Then look at what the customer supplies. “The customer should provide only the minimum information necessary to begin the reconnaissance stage of the exercise. For example, the primary domain name of the organisation, or the system name.” A domain name starts it. That is a lower bar than most security teams assume, and it is why the method reaches tools your asset register never captured.

The NCSC then enumerates the sources. Passive collection is “done with stealth, that is without interacting with the target organisation” and covers “using online databases / search engines / looking up IP/DNS registrations / certificate information / relevant social media”. Active collection adds “limited port scanning / visiting the customer organisation’s websites / surveying available online services”. Every artefact in the next chapter comes from that list, written by the national technical authority rather than by a supplier.

One more line settles the argument about where to start. An assumed-breach engagement starts from a point inside the customer network, and it “will not tell the organisation what information they may deliberately or inadvertently be making publicly available (which could be of interest to an attacker)”. The NCSC adds that “a full spectrum approach starts from outside of the network”. Shadow AI leaks outward, into repositories, certificates, sign-up records and credential dumps. Skip the outside phase and you have bought the one test shape that is blind to it.

03 What the outside view returns, and what needs a tenant

Shadow AI discovery gets bought as one product. It is two jobs with different access requirements, and confusing them is how a programme ends up with a report that promises more than it looked at. Ask any supplier which of the two they are quoting for.

What an outside view returns, from a domain name and nothing else. API keys and tokens committed to public repositories, which the NCSC lists as an unmanaged service in its own right when it names “code stored in unmanaged repositories”. Certificate transparency and DNS records, which expose subdomains created for pilots nobody decommissioned. Build and CI logs left readable, where agent tokens surface. Online services that answer when surveyed, including the internal tool somebody published to make a demo easier. And staff accounts on AI services, enumerable from corporate email addresses that appear in public breach and stealer-log corpora.

That last artefact deserves its scale. Have I Been Pwned listed 1,036 breaches on 21 September 2026 [ HIBP API v3 ] . Among the verified credential corpora it carries Combolists Posted to Telegram at 361,468,099 accounts, ALIEN TXTBASE Stealer Logs at 284,132,969, and June 2026 Stealer Logs at 56,278,397, breached and added on 15 June 2026. Every one of the three lists email addresses and passwords among its data classes, because a stealer log pairs the address with the password the malware captured from the browser. Nobody publishes a per-service breakdown of those corpora, so treat any figure claiming how many of those credentials belong to AI services as invented. You get the address and the fact of exposure, which is enough to ask the next question.

What a tenant review adds, and cannot be done from outside. OAuth grants sitting in the enterprise application list, where an AI tool a member of staff authorised two years ago still holds delegated access to mail and files. Browser extensions with read access to every page the user opens. Egress and DNS analysis from inside the network, which is where per-user, per-destination patterns live. An external test cannot produce any of those three. Ask any supplier who implies otherwise which administrator account they intend to use.

The credential half is where the two views meet, and the NCSC has already written the taxonomy. Its agentic AI blog of 20 August 2026 defines the scope precisely: “Credentials include API keys, OAUTH grants, SSH keys and any authenticated sessions the agent can access or use. These credentials allow the agent to perform actions using the identities and permissions associated with them” [ NCSC agentic AI ] . It adds that the credentials available to an agent “form part of its potential ‘blast radius’ if it behaves unexpectedly”, and that an agent with access to a host environment “may also be able to use credentials that are available to the user account under which it is running”. Every one of those items is a discovery target before it is a governance line.

04 The exposure after a year of pasted contracts

Take the ordinary case. A sales team has been drafting with a consumer chatbot for a year, on personal accounts, because 40% of the Censuswide sample draft reports and presentations that way and nobody told them to stop. Client contracts went in. Pricing went in. The renewal list went in. Ask what you have lost and the NCSC answers without hedging: employees who transfer sensitive or proprietary information to consumer AI services “will likely reduce the organisation’s visibility and control over that information”. The blog gives the reason: that information “may be stored, retained or used to improve the service”, outside established security and governance arrangements, unless specific privacy controls are in place [ NCSC, 7 Sep 2026 ] .

Notice what you cannot do with that sentence. You cannot scope a breach notification, answer a client’s due diligence questionnaire or brief a board, because you do not know which accounts, which service, which period or which documents. The NCSC’s framing of shadow IT covers the position exactly: “There might not be a risk, there might be a critical risk. The organisation simply doesn’t know. Shadow IT is therefore an unmanaged risk” [ NCSC shadow IT ] .

Now add the account. Those personal sign-ups used a work email address and, often, a password the browser stored. That pairing is what stealer logs collect and what the corpora above publish at nine-figure scale. An attacker who buys the list does not need to break the AI service. They sign in as your salesperson and read a year of prompts.

Then add the agents, which is where the risk stops being about documents. “AI agents are complex pieces of software that can have critical security vulnerabilities”, the NCSC writes. “If an attacker successfully exploits a vulnerability, they can gain access to the same data, services, and privileges that the agent has legitimate access to.” It is blunter still about the attacker’s own tooling: “Attackers are highly likely to use agents with looser guardrails to exploit any vulnerabilities or misconfigurations in the wider corporate IT system” [ NCSC, 7 Sep 2026 ] . An unapproved agent holds a credential nobody issued deliberately, runs under a human’s account, and appears in no log you keep. The NCSC prescribes the opposite: every agent gets “its own unique identity in a class which differentiates them from human or individual systems”, and agentic activity is treated “as a form of user activity” [ NCSC agentic AI ] . You cannot assign an identity to an agent you have not found.

05 Discover, then govern

Run this in the usual order and you write the acceptable use policy first, circulate it, add a line to the annual training, and call the risk managed. The policy names the tools the author could think of. Discovery names the tools that exist. Take them in that order and your first inventory arrives the day an incident forces one.

The NCSC sets the goal and the tone. “The use of shadow AI is unlikely to disappear completely. As with shadow IT more broadly, the goal should be to reduce risk rather than assume it can be eliminated.” It states outright that “the NCSC is not recommending that individuals stop using AI” [ NCSC, 7 Sep 2026 ] . Its shadow IT guidance gives the working instruction: “Security people should focus on finding where shadow IT exists, and where possible, bring it above-board by addressing the underlying user needs that shadow IT is seeking to address”, and it reminds you that shadow IT “is rarely the result of malicious intent” [ NCSC shadow IT ] .

So run it in this sequence. Discover from outside first, because that half needs nothing from your staff and returns the artefacts your internal telemetry cannot see. Add the tenant review for OAuth grants, extensions and egress. Put the two lists together and you have a count. Then meet the demand: the 28% who said there is no approved option are telling you which capability to buy. Then write the policy, name the approved tools, assign identities to agents, and turn on the logging. Amnesty on the way in, no blame, or the next round of discovery is as blind as the survey was.

The governance half of this argument, the policy, the ownership and the board reporting, sits on our global hub in Shadow AI: the enterprise risk view. This page is the other half. Find it, then govern it.

The credential half you can start on today, and it also runs from the hub. A free dark web exposure check takes one domain you name and sweeps forums, marketplaces and breach dumps for the corporate addresses and passwords already trading. Passive collection only, so nothing touches your systems, and what comes back is a named list of exposed accounts, the dumps each one came from and which to rotate first. If a year of prompts sits behind a personal sign-up on a work address, this is the artefact that tells you whether somebody else already has the key.

Book the free audit and we start where the NCSC says the work starts, with the outside view. One call, thirty minutes. You tell us what the business runs on. We tell you where an attacker would begin and what your organisation is already publishing about itself. If it becomes a full external test, every finding arrives proven by a CREST-certified operator, with a plain fix beside it and a year of re-tests.

Get a free audit.