Veteran Forge Strategies Deck Log article graphic — Approved. Your riskiest app is probably sanctioned. Status cards show shadow AI used by 45 percent of employees after tripling in a year, 67 percent of that AI use running on personal accounts outside single sign-on, and free discovery methods including DNS logs, expense reports and OAuth grants. Shadow IT feature by John Farmer.
| |

Most of Your Shadow IT Is Approved

ByJohn Farmer

Everyone worries about the app nobody authorized. Almost nobody re-reads the contract they signed three years ago with the vendor who now holds half their customer data.

The department you didn’t hire

Every organization has one. The free file-sharing account someone opened to hit a Friday deadline. The personal cloud drive with a folder of company documents in it. The spreadsheet that quietly runs a core business process, maintained by exactly one person, who is going on vacation next week.

None of that was malicious. That is the first thing worth getting right, because it determines whether the rest of your response works.

People don’t route around IT to cause trouble. They route around IT because the sanctioned path was slower than their deadline. Every shadow tool in your environment is a piece of feedback: the approved option is too clunky, too slow to request, or does not exist. Treat the finding as evidence of a gap and you get cooperation. Treat it as a discipline problem and it goes deeper underground, which is strictly worse — because now it is still happening and you cannot see it.

That framing is right and I want to keep it. But it is incomplete in a way that matters, and the current breach data shows exactly where.

First, an honest correction about where the risk is

The instinct is to treat unsanctioned tools as the hidden danger and approved tools as the safe part. The numbers do not support that split.

The 2026 Verizon Data Breach Investigations Report finds that nearly half of confirmed breaches — 48% — now involve a vendor, contractor or partner, and that third-party involvement jumped 60% year-over-year. Those are not rogue apps. Those are relationships somebody approved, signed, and then stopped thinking about.

The same report is unflattering about the state of those approved vendors: only 23% of third-party organizations had fully remediated MFA issues on their cloud accounts, and permission misconfigurations and weak passwords took a median of roughly eight months to resolve.

So here is the uncomfortable version. If you run a shadow-IT discovery exercise, find eleven unsanctioned apps, block four and sanction seven, and then never apply that same scrutiny to the twenty vendors already in your stack — you have carefully policed the smaller half of your exposure.

This is not an argument against the discovery work. It is an argument that the discovery work is step one of a review that has to keep going past the interesting part. The rogue app is more visible as a problem. The approved vendor with stale permissions and no MFA on its admin accounts is more likely to be the one that hurts you.

The part that genuinely got worse: AI

If shadow IT used to be a slow-moving governance annoyance, one category turned it into a live data-loss problem in about eighteen months.

The DBIR’s shadow-AI findings are stark. 45% of employees now regularly use AI tools on corporate devices — up from 15% the year before. A tripling in one year. Shadow AI is now the third most common non-malicious insider action in data-loss-prevention telemetry, a fourfold increase. Across the analyzed DLP events — 858,440 of them involving uploads to generative-AI tools — the most commonly leaked data type was source code. And the average company has more than 15% of its users running unauthorized AI browser extensions.

But the number I would put in front of leadership is this one:

67% of those employees reach AI services through non-corporate accounts.

Sit with what that means operationally. There is no single-sign-on record. There is no audit log you own. There is no admin console you can query. And on the day that person leaves, there is nothing to disable — the account is theirs, it was never yours, and whatever they put into it stays exactly where it is.

That is not an application problem. It is an identity and offboarding problem wearing an application’s clothes, and it is invisible to every control built around your directory.

It is also, in fairness, the most understandable shadow IT there has ever been. The tools are genuinely useful, they are free, and in most small organizations no sanctioned alternative exists. Which brings us back to the operating stance: that gap is the finding.

How to actually discover it, without buying anything

You do not need a CASB to start. For an organization under a few hundred people, four free methods will surface most of it — and all four are really the same discipline I argued for in knowing what hardware and software you actually own, pointed at the things that never showed up on a purchase order.

DNS and firewall logs. Everything talks to something. A week of outbound DNS queries, sorted by unique destination, is the single highest-yield hour you will spend on this. You are looking for domains nobody can explain. This is the same telemetry that earns its keep for knowing about problems before your users report them — you already have it, you are just asking it a different question.

OAuth and app-consent grants. In Microsoft 365 or Google Workspace, look at which third-party applications users have granted access to their accounts and what scopes those apps hold. This is the most underused discovery method in existence and frequently the most alarming, because a consent grant is a standing authorization to read mail or files that survives password changes and rarely gets reviewed. Most administrators have never opened this screen.

Expense reports and the credit-card statement. Software bought on a card is software IT does not know about. And here is where I will admit an advantage that is not typical for someone in an IT role: a good chunk of my career has run along the seam between IT and finance — ERP implementations, custom job-cost and management reporting, a QuickBooks integration I built from scratch. So when I say go read the GL, I mean it literally. Most IT leaders cannot get at that data easily and never think to ask. Pull twelve months of card transactions, filter for recurring charges under a couple hundred dollars a month, and you will find subscriptions nobody remembers authorizing — including, reliably, some nobody is using at all.

Ask people. Not in a compliance survey. In a conversation that opens with “what’s the most annoying part of your workflow, and what did you do about it?” You will learn more in four conversations than from most tooling, and you will learn why, which is the part that tells you what to build.

Triage: four outcomes, not two

Once you have the list, the mistake is treating it as a binary. Almost everything lands in one of four buckets.

  • Sanction it. The tool is fine, the risk is acceptable, and people already like it. Bring it under a company account with SSO, admin visibility, and a real owner. You have converted a liability into an asset and spent almost nothing.
  • Replace it. The need is legitimate, the specific tool is not. Provide something equivalent that is at least as easy — and understand that “at least as easy” is the whole requirement. A clunkier approved replacement gets abandoned and you are back where you started, minus the goodwill.
  • Wrap controls around it. You cannot eliminate it, so you reduce the blast radius: limit which data goes near it, require the corporate account, restrict the scopes, add it to offboarding.
  • Actually block it. Reserve this for real risk — regulated data leaving your control, a vendor with no security posture to speak of, anything touching CUI. And when you block, say why. An unexplained block is read as bureaucracy and generates the next workaround.

The proportion matters. If almost everything on your list ends up in the “block” bucket, you are not running a governance process, you are running a ban — and you will get the underground version next quarter.

Close the gap that created it

Discovery without a faster path forward is a treadmill. If getting a tool approved takes three weeks and a form, people will keep going around you, and they will be right to.

Two things fix most of it:

A request path measured in days. Somebody asks, somebody with authority answers quickly, and the default posture is “yes, through a supported route” rather than “no, unless you can prove necessity.” The speed is the control — it is what makes the sanctioned path competitive with just signing up.

A sanctioned AI option, specifically. This is the single highest-leverage thing most small organizations can do right now. Given a company AI account with an admin console and a data-handling posture you have actually read, the 67% personal-account number drops on its own — not because you forbade anything, but because the easy path finally exists. People are not attached to using their personal account. They are attached to having the tool.

Pair it with a short written policy that says what may and may not go into an AI tool, in plain language, with examples. “Use judgment” is not a policy. “Never paste customer data, contract language, source code, or anything marked CUI” is.

The federal and contractor angle

For contractors, shadow IT stops being a governance preference and becomes a spillage question.

  • CUI in an unsanctioned tool is a spillage event, regardless of intent, and regardless of whether the tool is reputable. The obligation follows the data, not the platform.
  • Your system security plan has to describe the system that exists. An SSP describing an environment that does not include the tools people actually use is inaccurate, and inaccuracy is the finding — arguably a worse one than the shadow tool itself.
  • Approved vendors are in scope too. That 48%-of-breaches figure includes suppliers, and flow-down obligations mean your vendor’s posture is partly your problem. If you are asking staff not to use unvetted tools, the same standard has to apply to the ones procurement signed.
  • Source code as the top leaked data type should worry anyone doing software work under contract. That is deliverable material and frequently contractually controlled.
  • Awareness training is an assessed requirement and most of it predates this. If your material does not mention AI tools by name, it is describing a world that no longer exists. Cheap to fix, visible to an assessor. The same argument applies to what AI changed on the attacker’s side — the training needs updating in both directions.

Where this usually goes wrong

  • Banning first. It does not remove the tool, it removes your visibility of the tool.
  • Finding it and stopping there. A discovery report nobody acts on is an audit finding you generated against yourself.
  • Ignoring the approved stack. Nearly half of breaches involve a third party you already said yes to.
  • Never reviewing OAuth grants. A standing consent to read mail outlives the password that granted it.
  • Treating shadow AI as an app problem. Two-thirds of it runs on accounts you do not own and cannot revoke.
  • Replacing a tool with something worse. The replacement has to be easier, not merely approved.
  • A three-week approval process. That is the thing generating the shadow IT. It is a cause, not a victim.
  • An AI policy that says “use good judgment.” Name the data types. People will follow a rule they can apply.

Start with a week of DNS

Pick a week. Export the outbound DNS queries. Sort by unique destination and go down the list asking one question: do I know what this is?

Then pull twelve months of card transactions and do the same with recurring software charges. Then open the OAuth grants screen in your tenant.

That is an afternoon, it costs nothing, and it will produce a list that is longer than you expect and more reasonable than you fear — because most of what you find will be someone solving a real problem the only way available to them.

The organizations that handle this well are not the ones with the strictest policy. They are the ones who can answer “what is actually running here, and who approved it?” — and who then ask that same question about the vendors they approved years ago and have not thought about since.

Veteran Forge Strategies is an SBA-Certified Service-Disabled Veteran-Owned Small Business providing IT infrastructure, operations, and cybersecurity support to small businesses and federal clients from Northern Virginia. If nobody at your organization can list the SaaS tools holding company data — sanctioned or otherwise — that is the engagement — get in touch. You can also read about how a fractional IT engagement works, or browse the rest of the Deck Log.

Similar Posts