Most AI security threat modelling is about prompt injection. It is a real class of attack and it deserves a control. It is also one control out of roughly thirty, and it is not the one that fails first.
What fails first is shadow AI. Nobody knows which tools are running.
Two thirds of employees use AI at work. Fewer than one in five organisations has a policy for it (2026 industry surveys). 82% of what people paste into these tools goes through personal accounts, on services nobody administers, and roughly a third of that content is sensitive (Cyberhaven, 2026).
One in five organisations has already had a breach involving AI nobody approved, and unmanaged AI adds about $670,000 to the average breach cost (IBM, 2025).
Below is the checklist we use. Seven sections, each with the check that tells you whether the control actually exists rather than whether someone wrote it down.
1. Inventory
You cannot secure what you cannot name, and most organisations cannot name their own AI tools. 60% of IT leaders say they lack visibility into which generative AI tools their workforce uses (Zylo, 2026).
What to look for. Every AI tool in use, sanctioned or not. The chatbot someone signed up for on a personal account. The transcription bot added to a recurring meeting. The industry tool that quietly shipped an AI feature in a minor release.
How to verify. Four sources, none of which need new tooling:
- Network and DNS logs for traffic to model providers
- Identity logs for OAuth grants and app consents in your tenant
- Expense claims and corporate card statements for individual subscriptions
- The connected-app list in Microsoft 365 or Google Workspace
None of this is complete. Someone on a phone on their own network stays invisible. But the gap between what you know today and what a week of looking produces is usually the whole problem.
2. Access
An assistant inherits the identity of whoever runs it. That is the sentence to hold on to, because it explains why a tool that "only reads documents" is a data exposure question rather than a productivity question.
What to look for. What each tool can reach, and as whom. Whether it runs under a personal account, a shared account, or a properly provisioned corporate identity. Which connectors are enabled and what they index.
How to verify. Sign in as a normal user with the tool enabled and ask it for something it should not be able to see. A finance document, an HR file, a repository outside their team. If it answers, the scope is wrong, and no amount of prompt filtering fixes that.
3. Data
What to look for. Where prompts and uploads land. Whether that data trains the model. Who inside the provider can read it. Which jurisdiction it sits in, and under whose legal reach.
How to verify. Read the tier you are actually on, not the marketing page. Consumer tiers and business tiers of the same product routinely differ on training and retention. Then confirm the setting is applied in your tenant rather than available in principle — the two are not the same, and the default is usually the one that suits the provider.
4. Agents
An agent is not a person typing. It is software acting with somebody's permissions, at machine speed, and the controls that work for a chatbot do not transfer.
What to look for. Whether each agent has its own identity rather than a shared service account or somebody's personal token. What it is allowed to install, call or push. Which actions it can take without a human.
How to verify. Ask who the agent authenticates as, and whether revoking it would break anything else. If the answer is a shared token, the agent cannot be revoked, rate-limited or audited independently — those three properties all depend on it having its own identity.
Then check the irreversible actions specifically: sending mail externally, deleting data, moving money, pushing to production. Each of those wants a human in the loop, and the check is whether the approval exists in the workflow rather than in the policy document.
5. Policy
What to look for. Which data classes may be sent to which tools. What the approval path is for a new tool. Who owns the decision.
How to verify. Ask three people in different departments what they are allowed to paste into an AI tool. If the answers differ, the policy is not operating, whatever the document says. A policy nobody can recite is not a control.
6. Configuration
A policy that the platform does not enforce is a preference. This section is what turns the previous one into a control.
What to look for. Company accounts rather than personal ones. Retention configured. Training opt-out applied. Connectors scoped. Unapproved tools blocked at the network or device layer.
How to verify. Change nothing and try to break the rule. Attempt to sign in to the sanctioned tool with a personal account. Attempt to reach a blocked tool from a managed device. If either succeeds, the setting is not doing what the policy claims.
7. Logging
Turn it on with the first agent, not the first incident. This is the only item on the list that cannot be reconstructed after the fact — the others can be assessed at any time, but a log you did not enable in March tells you nothing about March.
What to look for. Which prompts and responses are recorded, which agent actions are recorded, how long any of it is kept, and whether anyone can query it.
How to verify. Pick a day last month and ask what a given user asked an assistant, and what it did in response. If nobody can answer, the logging is not sufficient for an investigation, which is the only situation in which you will need it.
The order matters
Inventory comes first, and not for tidiness. The other six sections all assume you know what is running: you cannot scope access for a tool you have not found, or write a policy that covers it, or log it.
Most organisations start at section five, because writing a policy is the part that requires no access to anything. That produces a document describing a fleet nobody has counted.
Want help putting this into practice?
We work alongside your team to design, build, and operate the controls described above.