I have watched a security team find the same unsanctioned SaaS tool on a stack of expense reports and write it up as an incident. One product. Four teams. Four corporate cards. The report named a remediation owner and recommended we shut it off.
It was not a violation. It was a purchase order the business filed without asking me. Four teams, independently, found a budget line, evaluated a tool against their own work, and paid for it out of pocket. That is not a control gap. That is a market, and it had already voted.
Here is the reframe the whole essay rests on. Shadow IT is unmet demand with a corporate card attached. The sanctioned path was too slow or too narrow, so the demand routed around it and priced itself on the open market. You can make that tool disappear with a memo, or you can read the demand it revealed and buy it back with a better paved road. Only one of those makes the demand go away. The other just makes the receipt go away.
Where I sit changes what I notice first. I run security and DevOps, not the whole IT P&L, so I meet shadow SaaS first as a risk surface: an unfamiliar vendor, a machine credential I did not issue, customer data moving to a place with no data-processing agreement behind it. Some of that never becomes negotiable, and I will get to the part that doesn't. But most of what I find is not an attacker. It is a demand signal I nearly destroyed before I bothered to read it.
The corporate card is a priced ballot, not a policy breach
Every build-versus-buy decision turns on a number that is almost impossible to get honestly: what is this capability actually worth to the people who would use it? Ask them in a survey and you get cheap talk, because everyone wants everything when it is free and hypothetical. Willingness-to-pay separates a real need from a nice-to-have, and it is the one number a survey cannot produce.
Shadow spend produces it for free. When a team puts a tool on a corporate card, they have done the thing a survey can never make them do: they moved money. Economists call this revealed preference, and an expense report is revealed preference with a dollar figure attached. It tells you the job was worth paying for, who it was worth it to, and roughly how much. That is a market-priced backlog, delivered to your inbox, and most IT functions file it under "risk" and never read the price.
So before the tool gets shut off, I want the receipt read as what it is. Not "who broke policy" but "what did the business just tell us it will pay to get done, that we are not doing." The first question is a manhunt. The second is product discovery you did not have to fund.
Read the job, not the tool
The mistake that follows is reading the vendor instead of the need. Six teams on the same category is not six purchases to shut down. It is one unmet job, hired six times. The specific tool each team picked is a proxy (the closest thing they could buy in an afternoon), and if you fixate on the vendor you will win the argument about that vendor and completely miss the job.
The jobs-to-be-done lens is the right corrective: people do not want a tool, they want to make progress on a task, and they hire whatever gets them there fastest. So cluster shadow spend by the job, not by the logo. Three different note-takers, two data-prep tools, and a scheduling app might be five vendors and one job, a team trying to get a repetitive task off a human's plate. Buy back the job and all five receipts disappear at once. Chase the five vendors and you play whack-a-mole against your own colleagues.
You cannot cluster what you cannot see, which makes this an instrumentation problem before it is a policy one. The finance data is the richest signal: expense reports and AP files carry the vendor, the buyer, and the price. The identity layer is next. New SaaS integrations authenticate machine-to-machine with an OAuth client_credentials grant, which quietly mints a non-human identity you did not issue, and those are visible if you are watching your identity provider and your egress instead of only your ticket queue. None of this requires a surveillance program. It requires treating the signals you already collect as demand data, not only as audit trail.
Triage: sanction, absorb, or curb
Once shadow spend is clustered by job, every cluster resolves into one of three decisions. The discipline is choosing which, deliberately, instead of defaulting all three to "block."
- Sanction. The tool the team found is genuinely better than anything you would build, and the job is not core enough to own. Do not compete with it. Adopt it as the paved road: put it under your identity model, your logging, and a real data-processing agreement, negotiate the contract the four separate cards were never going to, and bless it. You bought back the governance without building a thing.
- Absorb. The job is core, recurring, and touches data or workflows you need to control. This is the one you build into the platform, and building it means beating the shadow tool on the thing that made the team choose it, usually speed, while including the governance they were never going to add themselves. This is what "buy it back" actually means: make the sanctioned path the better purchase, then do the migration so switching is cheaper than staying.
- Curb. A genuine risk with no safe version, such as regulated customer data in an unsanctioned SaaS with no agreement behind it. That is a hard line and it does not move. You block it. But a curb with no substitute is not a solution; it is a deferral. The job is still unmet, and you have just taught the team that surfacing a need gets it taken away.
Most clusters are sanction or absorb. Curb is the small pile, and it is the only one where the security reflex is the right first move. The failure mode is treating every cluster like the curb pile: meeting a market with a memo.
The memo removes the tool, not the demand
Here is why the enforcement-only response fails, and it is a systems argument rather than a values one. A memo is a subtraction. It removes a tool. Demand is not a thing you can subtract. It is a standing pressure, and pressure that loses one outlet finds another. Shut the tool off and the job it was hired for is still there next quarter, still unmet, and it re-emerges as a different tool. Now it is bought more quietly, because the team learned exactly one lesson from the first round: visibility gets you shut down.
That is the part that should worry a security leader most. Enforcement without a substitute converts visible shadow IT into invisible shadow IT. You had a vendor you could see, a card you could audit, a credential you could find, and you traded it for the same data flowing through a personal account you will not discover until it is a breach. You did not close the risk. You blinded yourself to it, and you trained the business to keep you blind. The memo destroys the one instrument that was working.
Absorption is not rationalization
It would be easy to hear all of this as another call to hunt down SaaS sprawl and cut it, and it is the opposite. Rationalization asks what to cut; absorption asks what to build. An underused pile of seats bought for a headcount that never arrived is waste, and you should cut it. A job six teams are actively paying out of pocket to get done is demand, and you should serve it. The expensive mistake is running every piece of shadow spend through the FinOps reflex that only knows how to eliminate. You save a little money and you lose the signal that would have told you what to build next.
The reason to fold governance into the product rather than the memo is that it is the only version that survives contact with a team that has somewhere else to go. We built AgentOS, our internal agent platform, on that premise. The guardrails are the point, but they ride in on a paved road that is genuinely faster than wiring it up yourself, so the governance arrives as part of a better product instead of a tax bolted onto a worse one. You cannot mandate your way to that. You have to win the purchase.
Buy the demand back
If you own a platform, or you approve the budget for one, the shift is small to describe and hard to practice.
- Read the receipt before the manhunt. Every unsanctioned tool is a priced answer to a question you should have been asking. Find the question.
- Cluster by job, not by vendor. Six logos are often one unmet need. Buy the need back and the logos take care of themselves.
- Triage on purpose: sanction, absorb, or curb. Default to serving the demand; reserve the block for the genuine hard lines, and know they are the small pile.
- Never subtract a tool without absorbing its job. A memo makes the receipt disappear, not the demand. Give the demand a better home or it will find a worse one.
I changed my mind on this the hard way, by shutting things off, watching the demand resurface somewhere I could no longer see it, and realizing I had made my own environment less safe in the name of control. Telling the absorb pile from the curb pile is still the judgment call I get wrong most often, and it is the only part of this worth practicing.