The fallacy of sunk costs in AI security

The FedRAMP–Microsoft Story Is Not a Government Problem. It Is Your Problem.

The Most Expensive Four Words in Enterprise Technology: "We're Already Too Deep"

In late 2024, a team of federal cybersecurity experts completed a five-year review of Microsoft's GCC High — the cloud platform protecting some of the United States government's most sensitive data. Justice Department files. Energy Department systems. Defense contractor networks.

After 480 hours of assessment and 18 technical deep-dive sessions, one reviewer's verdict was unambiguous. Three words, no hedging:

"A pile of sht."*

(That is a direct quote from an internal government report, not editorial commentary. Though it does double as excellent editorial commentary.)

The formal summary was more bureaucratic, noting a "lack of confidence in assessing the system's overall security posture" — but the conclusion was the same. And here is where the story turns from alarming into something else entirely: the Federal Risk and Authorization Management Program — FedRAMP, the U.S. government's official cybersecurity seal of approval for cloud products — authorized GCC High anyway, on December 26, 2024.

This was not a close call that went the wrong way. It was a decision made with eyes wide open.

Read the full ProPublica investigation here: Federal Cyber Experts Called Microsoft's Cloud 'A Pile of Sh*t.' They Approved It Anyway.

The Full Story — Because You Need to Know How Bad It Got

Microsoft is the largest technology vendor to the United States government. Its cloud products are embedded in agencies across every corner of the federal government. That fact is not incidental to this story — it is the entire explanation for how this story ends the way it does.

The security concerns about GCC High were not new. They surfaced in 2020. In the same three-year window, two catastrophic cyberattacks exploited Microsoft infrastructure: Russian state-sponsored hackers breached federal agencies including the National Nuclear Security Administration, and Chinese hackers infiltrated the email accounts of a Cabinet member and the U.S. Ambassador to China. FedRAMP kept reviewing. Microsoft kept not providing the documentation its reviewers requested.

Here is the detail that makes it a story, not just a policy dispute: the third-party firms hired to assess Microsoft's security were hired and paid by Microsoft itself. Two of them — Coalfire and Kratos — privately told FedRAMP they could not get the full picture of the product they were evaluating. That feedback never appeared in their official reports. The conflict of interest was structural, deliberate, and known.

Microsoft also went to work on the politics. Its government liaison — a former Army official — reached out to Justice Department leadership and pushed them to, in the words of a Justice official, "throw around our weight" to accelerate authorization. The review that was supposed to be independent was being lobbied from the outside.

And then there is DOGE. The US goverment's cost-cutting initiative gutted FedRAMP's staff and budget. The program that was supposed to be America's cloud security gatekeeper now operates on $10 million a year — its lowest funding in a decade — with roughly two dozen employees whose primary directive is delivering authorizations at speed. Deep technical review, by multiple former employees' accounts, is now a relic. FedRAMP has become what every security function eventually becomes when the budget gets cut and the headcount disappears: a rubber stamp with good branding.

On December 26, 2024, GCC High was authorized. The summary document noted that "not issuing an authorization would impact multiple agencies that are already using GCC-H."

That sentence is the whole story. That sentence is the trap.

You Didn't Fall Into This Trap. You Walked In.

No organization plans to find itself defending an insecure system. The logic at every step is reasonable — even sensible.

You adopt a platform because it is the best available option at the time, or because the vendor's pitch was compelling, or because the rest of your industry was moving that direction. You build on top of it. You train people on it. You integrate it with a dozen other systems. You negotiate multi-year contracts. You make it load-bearing.

Then the security gaps emerge. A vulnerability report. An audit finding. A breach at a peer organization using the same stack. And now you face a question that was never supposed to require a meeting: do we fix this, or do we keep going?

The honest answer, in most large organizations, is: we keep going. Because the cost of stopping — migrating systems, retraining teams, unwinding vendor contracts, rebuilding integrations — feels catastrophic compared to the cost of managing the risk in place. So you manage the risk. You add monitoring. You write policies. You call it "risk acceptance" in the documentation. You hope nothing happens before the next review cycle.

This is exactly what FedRAMP did with Microsoft — at the scale of the United States government. It is what your organization may be doing right now — at the scale of your enterprise.

The trap is not that you were careless. The trap is that you were too invested to be honest.

A Compliance Certificate Is Not a Security Guarantee. Your Board Doesn't Know That.

Here is where it gets more dangerous, not less — and where the Microsoft story has a direct and uncomfortable parallel in enterprise AI.

When an organization knows it has a security problem it cannot or will not fix, it compensates with compliance activity. More audits. More certifications. More vendor assurances. More documentation. The paperwork grows in inverse proportion to the actual security work being done. And then — this is the critical part — leadership reads the compliance report and concludes that the risk is managed.

The board sees a SOC 2 attestation. They see an ISO 27001 certificate. They see "FedRAMP Authorized" on the vendor's website. They read "security." Those two things are not the same, and in a large enterprise with genuine sunk cost exposure in an insecure system, the gap between them is where the real damage happens.

Your enterprise AI vendor almost certainly has a compliance document to show you. It does not tell you whether the system is actually secure. It tells you whether the system passed an assessment — often conducted by a firm that was paid by the vendor to conduct it. That is a statement about process. Not about reality.

The FedRAMP reviewers documented the problem with GCC High clearly and specifically. The documentation existed. The authorization was issued anyway. The compliance layer did not make Microsoft's cloud more secure. It made the decision to approve it more defensible.

That is what compliance is often for. Not security. Cover.

Your AI System Is Not a Filing Cabinet. It Can Be Weaponized.

Tolerating security debt in a legacy database or an email platform is serious. In an AI system, it is a categorically different risk — and most enterprise leaders have not yet made that distinction.

AI systems are not passive infrastructure. They are active participants in your business operations. They read your documents, synthesize sensitive information, make recommendations that drive decisions, and in an increasing number of enterprise deployments, take autonomous actions on behalf of users and the organization itself. They are trained on your most sensitive data. They interact with your clients. They operate at the intersection of everything you are trying to protect.

An insecure AI system is not a system that might get breached someday. It is a system that is actively attackable right now — in ways that traditional security controls were never designed to address:

• Prompt injection attacks can manipulate what your AI decides to do, invisibly, on live inputs.
• Model inversion techniques can extract training data you never intended to expose — including client data, internal documents, and proprietary logic.
• Privilege escalation in agentic AI systems can turn a workflow assistant into an insider threat, taking actions no human authorized.

These are not theoretical vulnerabilities. They are documented attack patterns against systems that are in production in enterprises today.

And the sunk cost pressure is stronger in AI than it is in almost any other technology context — because AI adoption has been fast, visible, and politically significant inside most organizations. The business cases were hard to win. The deployment announcements were made. Nobody wants to be the person who raises their hand and says the system we celebrated six months ago is not secure. The incentive to keep going is enormous. The silence in that room is expensive.

The Window Is Open. It Won't Stay That Way.

The FedRAMP reviewers knew exactly what they were looking at. The failure was not in the assessment. It was in what happened after. The institution looked at a clear-eyed security finding and chose operational continuity over accountability — because by the time the finding was clear, the cost of reversing course had become politically impossible.

Your organization is not there yet. Or if you are, you are earlier in the curve than the federal agencies that have been running GCC High for years without a full security picture.

The window for doing this right is before the lock-in. Before the integrations multiply. Before the vendor relationship becomes load-bearing. Before the AI system's outputs are embedded in enough workflows that questioning it becomes a business disruption rather than a security decision.

A focused AI Security Posture Assessment — examining your model inputs, access controls, agentic workflows, data handling practices, and audit trails — gives you a clear and documented picture of what you actually have and what the real exposure is. It is not a six-month engagement. For most enterprise AI deployments, it surfaces the material risks in days. What it gives you is the one thing the FedRAMP reviewers never had for GCC High: an honest answer, while you can still act on it.

The U.S. government held its nose and approved a system it could not fully verify. The agencies depending on that system are now living with a decision made years ago, by people who could see the problem and chose to keep going.

You have not made that decision yet. Make a different one.

Dr. Prasad Golla is the Founder of Aggi Technologies LLC and a Fractional CTO and AI Security Advisor. He specializes in AI Security Posture Assessment, adversarial ML defense, and AI governance for enterprise organizations deploying AI at scale.

aggicorp.com · prasad@aggicorp.com · LinkedIn: Dr. Prasad Golla

← Back to Insights