Shadow AI Posture Framework

Same four people, same number of AI tools, either way. The only variable is whether anything sits between them and what they reach for, tracking which tools, which data, and whether any of it was ever approved.

Same four people, same number of AI tools, either way. The only thing that changes is whether anything is actually watching.

Illustrative, not literal. The point is the checkpoint, not the specific tool names, which are examples only. The Handle stage below is where this becomes a real disposition on a real row.

This is an example, not a literal picture of your setup. The point is that something checks, not these exact tool names. Step 4 below is where this turns into an actual decision on your own list.

Three ways in, depending on what you already have. You do not need to read the whole page to get something useful out of it.

Pick whichever one sounds like you. You do not have to read the whole page.

Most organisations respond to unsanctioned AI with an email. An email does not produce an inventory, a score, or a trend line. This framework treats shadow AI the way a mature programme treats any other unmanaged asset: discover it, characterise it, rate it, dispose of it, and measure whether the population is getting safer.

It is any AI tool people use for work that nobody officially approved. Someone signs up with their own email, pastes in something they should not, and now company information sits on a computer you do not control and cannot get it back from. Most companies react by sending a warning email. An email does not tell you what is being used, how risky it is, or whether things are improving. This page does.

The five stages

The five steps

You are not buying a discovery product. You are querying logs you already pay for. Each source below sees something the others cannot, which is why one source is never enough and three is the working minimum.

You do not need to buy anything. Your company already keeps records of what its computers do. Each type of record shows something the others cannot, so use at least three.

The category everyone forgets: AI you already bought

The bit everyone forgets: AI you already pay for

Shadow AI is not only tools staff signed up for. A large share of it is AI capability that appeared inside sanctioned platforms and was enabled by an admin, a team lead, or a default. It never went through review because it never looked like a purchase. Check the admin console of every major platform you own for: meeting assistants and transcription, summarisation of tickets and threads, AI search across connected content, code assistants, agent or workflow builders, and any feature that sends content to a model hosted outside your tenant boundary.

Shadow AI is not only tools people signed up for themselves. A lot of it arrived quietly inside software you already use. A new AI button appears in an update, someone switches it on, and nobody ever reviewed it because nobody ever bought it. Go into the settings of your five biggest work tools and look for anything that says it will summarise, transcribe, search or write for you.

AI signal dictionary

A starting list of destinations worth querying for. It is deliberately incomplete and will age. Filter it, then generate a ready-to-paste query for your own tooling. Contribute additions in your own fork.

A list of AI websites worth looking for. It is not complete and it will go out of date. Tick the kinds you care about, then pick a format at the bottom and copy the result straight into your work tools.

Why the app list is where an attacker looks first

Why this list matters more than the others

A consent grant is not a login. When a user approves a third-party app, the platform issues that app an access token and a refresh token. From that point the holder does not need the password and is never asked for the MFA code, because nobody is signing in. That is why a grant is worth more to an attacker than a stolen credential: it is durable, it is quiet, and it was authorised by a real employee. Whether disabling the account also kills the grant depends on the platform and how it is configured. Do not assume it does. Test it on one account before you rely on it.

When someone clicks Allow on an outside app, that app is handed its own key. It does not use the person's password after that, and it is never asked for a code from their phone, because it is not logging in as them. That is why these are worth more to an attacker than a stolen password. The key keeps working, it is quiet, and a real employee approved it. Changing the password does not take the key back. Somebody has to go and cancel it. And do not assume that switching off the person's account cancels it either. That depends on the system. Test it on one account and find out.

The names are boring on purpose. Meeting Scheduler. PDF Utility. Notes Sync. A low-traffic app with read scopes trips no brute-force rule, no impossible-travel rule and no anomalous-login alert, which is exactly the point. And a grant outlives its reason: somebody connects a tool for a two-week project, finishes, and forgets, while the scopes stay live for years. The same holds for grants you approved yourself. A legitimate vendor with wide access to your tenant is a legitimate route in for whoever breaches that vendor.

The names are dull on purpose. Meeting Scheduler. PDF Utility. Notes Sync. A quiet app that only reads things sets off none of the alarms that catch someone guessing passwords, and that is the point. These also outlive their reason. Somebody connects a tool for a two-week job, finishes, and forgets, and the access carries on for years. That is true of apps you approved too. If the company behind a trusted app gets hacked, whoever hacked them now has a legitimate way into your systems.

What a bad one looks like

What a bad one looks like

• Sort every grant list by last used, first. Anything unused for 90 days is either dead weight or a foothold. Both need the same action, so you do not have to tell them apart to act.
• Scopes wider than the app's stated job. A scheduling tool asking to read mail is not a misconfiguration, it is a claim you should make it prove.
• One user, recently granted, unverified publisher. Consent phishing lands on individuals, not fleets. A single grant nobody else in the organisation has is the shape to look for.
• A publisher name that does not match the app name. Or a verified-publisher field that is simply blank.
• A grant that survived offboarding. Cross-check the grant list against your leaver list. A live grant on a disabled account is the finding that funds the programme.

• Sort the list by when each app was last used. Anything untouched for three months is either forgotten or is somebody quietly keeping a way in. You do not need to work out which, because the answer is the same either way.
• An app asking for more than its job needs. A calendar tool that also wants to read your email is not a mistake. Make it explain itself.
• One person, added recently, from a company you cannot verify. These scams target one person at a time. An app nobody else has is the one to look at.
• The company name does not match the app name. Or there is no company name at all.
• Somebody left and their app is still connected. Compare the list against people who have left. A live connection on a closed account is the thing that gets your boss to take this seriously.

Where to click, if you have no log access

Where to click, if you cannot search logs

Third-party app grants are the highest-value, lowest-effort source, and every major platform exposes them in its admin console without a query language.

The quickest win needs no searching at all. Every big work platform has a settings page listing the outside apps people have connected to it. That list is often where the AI is hiding.

Signals are not an inventory. An inventory has one row per tool, a human owner, and a claim about the data that can be checked. This is the register schema the scorecard below reads and writes.

A pile of website addresses is not a list. A list has one line per tool, a real person responsible for it, and an honest note about what goes into it. Here is what each line needs.

One exposure score per tool, 0 to 100, from five dimensions scored 0 to 3. Weights are fixed and published so two analysts scoring the same tool land in the same band, and so anyone can argue with the model rather than with you.

Every tool gets one score out of 100. You answer five questions, each worth a different amount. The sums are printed here so anyone can check your working, or argue with the method instead of with you.

score = (a×30 + b×20 + c×20 + d×20 + e×10) ÷ 3, rounded to a whole number. All five answers at 3 gives exactly 100.

Each of the five answers should trace to something you can point at: a log line, a screenshot, an admin console entry, not a guess about what a tool probably does. An unsupported score is an opinion wearing a number.

Each answer should come from something you can actually show someone: a log, a screenshot, a setting you saw with your own eyes, not your best guess about what a tool probably does. A guess dressed up as a number is still a guess.

Known enterprise tiers, a quick reference

Some of the big ones, already checked for you

A hand-checked starting point for the vendor-handling question on five tools people actually use. This is the paid business or enterprise tier specifically, checked against each vendor's own current documentation, not the free or personal version of the same product, which usually has none of these. Vendor terms change; re-verify before relying on this for a live decision.

A starting point for five tools people actually use, checked by hand against what each company actually says. This is about the paid business tier specifically, not the free or personal version, which usually does not have any of this. Companies change their terms, so check again before you rely on this for something that matters.

All five say no to default training and yes to enforced company sign-in and an admin console, at this tier. That is not a coincidence, it is what makes a tier sanctionable. The gap this framework exists to close is personal-account access to these same products, where none of the above applies.

All five say no to training on your stuff by default, and yes to a proper sign-in and an admin view, at this level. That is the whole point of paying for the business version. Using the personal or free version of the exact same tool gets you none of this, which is the actual gap this whole page is about.

Bands and override flags

What the score means

• Secrets or credentials observed in prompts, so Critical. The exposure already happened. Rotation, not review.
• Regulated data plus a personal account, so Critical. You have regulated data in a place you cannot subpoena, revoke or audit.
• No named owner and write access, so escalate one band. Something can change your systems and nobody has agreed to answer for it.
• Vendor trains on inputs with no verified opt-out, so escalate one band. Your inputs are now somebody else's training corpus, permanently.
• A standing grant or API key that survives a credential reset, so escalate one band. Resetting the password and re-enrolling MFA does not touch an issued token. Only revoking the grant does, and nobody does that at offboarding unless a process makes them.

• Somebody pasted in a password or a key. Straight to the worst level. It has already leaked. Change the password today.
• Private details about real people, on somebody's personal account. Straight to the worst level. You cannot get that back and you cannot prove what happened to it.
• It can change things and nobody is responsible for it. One level worse. Something can act on its own and there is nobody to ask about it.
• The company behind it learns from whatever you type. One level worse. What went in is now part of their system forever.
• It holds a key that still works after the password is changed. One level worse. Changing the password does not lock it out. Somebody has to go and take the key back, and almost nobody remembers to.

Nothing escalates past Critical. The first two set the band outright, whatever the score. The override set moved from four conditions to five when the standing-grant condition was added; scores recorded under the earlier set are unaffected, because that condition is off unless you tick it.

Nothing goes past the worst level. The first two set it outright, whatever the score. There used to be four of these and now there are five. Any score you wrote down before still stands, because the new one is off until you tick it.

If leadership tracks one number from this page, make it Handled rate, the share of your High and Critical rows that are actually enforced, not just decided. Everything else on the scorecard below is diagnostic. Track it over time; the trend is your migration signal, the pace at which shadow tools are actually being replaced, not merely found.

If your boss only wants one number from this whole page, give them Handled rate, how many of your worst tools are actually sorted, not just decided about. Everything else below is detail. Watch it over time, since a number that climbs is the actual proof this was worth doing.

A score with no decision attached is a report. Every row leaves this stage with one of six dispositions, a named owner and a date. The band sets the default; the owner can override it in writing, which is itself the audit trail, and Accept below is that override made a real option in the table rather than just a sentence here.

A score on its own is just a number. Every tool leaves this step with a decision, a person and a date. The score suggests the decision. A person can choose differently, as long as they write down why.

What "route to a sanctioned equivalent" looks like

What that actually looks like

The High and Critical rows above both point at the same fix: something has to sit between people and the tools they reach for, or "sanctioned" is just a word in a spreadsheet. That's the before/after shown near the top of this page, under "How bad is Shadow AI, actually?" This is the stage where it becomes a real disposition on a real row.

The two worst rows above both say the same thing: something has to stand between people and the tools they reach for, or "approved" does not actually mean anything. That's the before/after shown near the top of this page, under "How bad is Shadow AI, actually?" This is the step where it turns into an actual decision on your own list.

Before you revoke anything

Before you switch anything off

A revoked grant does not warn anyone. It stops working, silently, and the first person to notice is often a customer. Mass revocation is the fastest way to turn a security finding into an outage, and an outage is how a programme loses the mandate it just earned. Contain in this order.

When you cut off an app, nothing announces it. It just stops working, and the first person to notice is often a customer. Switching off everything at once is the quickest way to turn a good piece of work into a disaster your team gets blamed for. Do it in this order.

1. Find what depends on it. A grant is often the only thing moving data between two systems nobody thinks of as connected. Check the last-used timestamp and the call volume before you touch it.
2. Name the owner and give them the date. If no owner exists, finding one is the first task, not a reason to wait.
3. Kill the token, not just the login. Disabling the account may leave the grant live. Revoke the grant itself, and rotate any API key that went with it.
4. Stage it. Revoke the worst one, wait a working day, then the next. One failure is diagnosable. Forty at once is an incident with your name on it.
5. Close the door behind you. If nothing stops the same user re-approving the same app tomorrow, you have bought a week. Route high-risk scopes to an admin approval instead of an open consent prompt.
6. Write down what broke. That list is the business case for the consent gate, and it is the only version of that argument anyone believes.

1. Find out what relies on it. These apps are often the only thing quietly passing information between two systems nobody realised were joined up. Check when it was last used before you touch it.
2. Name the person responsible and tell them the date. If nobody owns it, finding someone is the first job, not a reason to put it off.
3. Cancel the key, not just the login. Closing someone's account may leave the app's key working. Cancel the app's access itself, and change any password or key that came with it.
4. Do them one at a time. Cut off the worst one, wait a day, then do the next. If one thing breaks you can fix it. If forty break at once, that is now your problem.
5. Shut the door behind you. If the same person can just say yes to the same app again tomorrow, you have bought yourself a week. Make the risky ones need an admin to approve them.
6. Write down what broke. That list is how you convince your company to fix this properly, and it is the only version of the argument anyone actually believes.

Incident response annex

If something has already gone wrong

A Critical row's disposition says to open an incident record. This is what that record should actually contain, and the one step people skip: evidence comes before remediation. Rotating a key before you have captured what it touched destroys the thing you would have used to answer "what actually left."

The worst-level decision above tells you to write down what happened. This is what to actually write, and the one step people skip: capture the evidence before you fix anything. Changing the password before you have written down what it had access to destroys the only record of what actually happened.

Classify it first, in one of three ways. Confirmed: you can show what left, and when. Suspected: the evidence points to exposure but you cannot yet show it directly. Near miss: caught before anything left. This is a separate axis from the tool's Low to Critical band; a Low-scored tool can still produce a Confirmed incident, and the classification, not the standing band, decides how you respond right now.

Work out which of three this is, first. Confirmed: you can actually show what got out, and when. Suspected: it looks bad but you cannot prove it yet. Near miss: caught before anything left. This is different from the tool's usual score. Even a tool you scored as fine can still cause a Confirmed incident, and it is this classification, not the old score, that decides what you do right now.

1. Confirm scope before you touch anything. What left, when, and who had access. A timestamp range beats a guess. This is the record; write it down before the next step overwrites the evidence.
2. Preserve, then contain. Export or screenshot the logs, grants and messages you are about to revoke. Only then work through the revoke sequence above. Order matters once, and this is the once.
3. Notify by who needs to act, not by who might be upset. Legal or your data protection lead if personal data was involved, the business owner named on the row, and leadership if the classification is Confirmed. Silence is a choice with its own consequences.
4. Record the classification, the timeline and the root cause on the row itself, alongside the enforcement date. A Critical row that closes with no incident note looks identical to one that was never actually reviewed.
5. Decide if the score should change. An incident is often evidence for an override flag you had not ticked, secrets observed, or a standing grant you did not know survived. Update the row rather than filing the incident somewhere the register cannot see it.

1. Work out what actually happened before you touch anything. What left, when, and who could get to it. An actual time range beats a guess. Write this down before the next step wipes the evidence.
2. Save the evidence, then lock things down. Screenshot or export the logs and access you are about to switch off. Only then do the steps above. This is the one time order really matters.
3. Tell the people who need to act, not just the people who will be upset. Your legal or privacy person if anyone's personal details were involved, the person responsible for that tool, and your boss if you are sure something actually got out.
4. Write down what it was, when it happened, and why on the tool's row, next to the date you fixed it. A worst-level row closed with no explanation looks exactly the same as one nobody actually checked.
5. Ask whether the score should change. An incident is often proof of something you had not ticked yet, like a key that still worked after a password reset. Update the row instead of writing the incident down somewhere the list will never see it.

Closing a row

Ticking a tool off the list

A decision that is never applied is indistinguishable from no decision at all, so the register carries three fields that turn a disposition into work somebody can be held to. replacement names the sanctioned thing people go to instead. review_due is the date this row is looked at again; the band suggests the interval, annually down to thirty days. enforced is the date the decision was actually applied, and until it is filled the row is decided but not done.

A decision nobody carries out is the same as no decision, so every tool on the list has three extra boxes that turn a decision into real work. One says what people should use instead. One says when you will look at it again. One says the day you actually did it. Until that last one is filled in, you decided and then did not do it, and the list will keep saying so.

One rule is enforced rather than suggested: a High or Critical row cannot be marked done without a named replacement. Blocking with nothing to offer does not remove the demand that created the tool, it relocates it somewhere you cannot see. If most of your High rows have that field empty, the honest finding is not that people misbehaved, it is that the organisation has a capability gap, and the register now counts it for you.

One rule is not a suggestion: you cannot tick off a bad one until you name the safe thing people should use instead. Taking a tool away does not remove the reason people wanted it, it just moves it somewhere you cannot see. If you keep leaving that box empty, the honest finding is not that people misbehaved, it is that your company has not given them a good enough tool. The list counts that for you now.

The register measures tools. This measures you. Thirteen controls across four domains, each scored 0 to 3, re-run quarterly so the trend is the deliverable rather than the snapshot. Every control maps to a published NIST AI RMF subcategory and an ISO/IEC 42001 Annex A control, so the output survives contact with an auditor.

The list measures your tools. This measures your team. Thirteen questions in four groups. Score each one from 0 to 3 and do it again in three months, because the improvement is the point, not the snapshot. Each question is tied to an official standard, so an auditor will recognise it.

This score needs an owner the same way a register row does. Name one accountable person for the quarterly re-run before you close this page; an assessment nobody owns is the one that quietly stops happening.

This score needs a person responsible for it too, the same as every tool on your list does. Pick one real person who will actually do the re-run in three months, or it just quietly stops happening.

Two different clocks are running here, and conflating them causes confusion. Each register row's review_due is set by its own band, thirty days for Critical up to annually for Low. This maturity score runs on a separate, fixed quarterly cadence regardless of what any individual row scores. Re-running one does not re-run the other.

There are two different clocks here, and it is easy to mix them up. Each tool on your list gets checked again on its own schedule, anywhere from a month to a year depending how bad it is. This team score above is separate: check it again every three months, no matter what any one tool scored. Doing one does not do the other.

Your work lives in this browser only. That is the privacy guarantee and it is also the risk, so take a copy. The save file carries the register, the assessment and your language setting.

Everything you type stays inside your own browser. That is good for privacy, but it means it can vanish if you clear your history or switch computer. Take a copy.

The thirteen controls, mapped to the frameworks your auditors and customers already ask about. Subcategory text is from NIST AI 100-1; Annex A control titles are from ISO/IEC 42001:2023; the LLM references are the OWASP Top 10 for LLM Applications, 2025 edition. One row also carries a statutory citation where a specific law, not just a voluntary framework, already requires it.

This bit is for auditors and compliance people. Each of the thirteen questions is tied to a numbered rule in the official AI standards, so nobody has to take this page's word for anything. One row also names an actual law, not just good practice.

A first pass that fits around an existing job. It produces a register, a scored population, decisions on the worst rows, and a baseline you can re-run. It does not produce a finished programme, and saying so out loud is what makes the plan credible.

A first go that fits around a normal job. At the end you have a list, a score for each thing on it, decisions on the worst ones, and a starting number to improve on. It will not be finished, and saying so is what makes the plan believable.