Running the U.S. Army's AI lab was a dream job. We built autonomous ground vehicles and next-generation command and control systems, alongside some of the best engineers I have worked with. I left anyway. The work was worth doing and the mission mattered, but I had spent years watching the same thing happen to every project I touched: the technology worked, and the paperwork buried it. I left when I did because the paperwork problem had finally become solvable. A few years earlier, it would not have been.
This post has been edited for clarity since it was first published.
The Wall
Over my career in the Army I built dozens of software products, from small internal tools to AI systems that pushed on what we thought was possible at the time. The engineering went the way engineering goes. There were hard problems, we solved most of them, and the ones we could not solve we understood well enough to route around. Then every project arrived at the same place.
The obstacle was never security. Security is the reason any of this exists, and nobody I worked with needed to be convinced of that. The obstacle was the process of demonstrating security: the documentation, the manual control mappings, assessment cycles measured in quarters, and arguments with assessors about how a control was described rather than whether it was implemented.
Projects lost momentum there. The technology had not failed and the teams were not weak. By the time a system worked its way through authorization, it was a generation behind, the budget was spent, or the mission need had moved on.
Here is what is hard to appreciate from outside government: compliance is not one hurdle among several. It is the hurdle. It outweighs the technical difficulty and the budget fight combined.
An autonomous ground vehicle that can handle complex terrain is a hard engineering problem with a known shape. So is a command and control system that fuses real-time battlefield data. Both are the kind of thing a good team finishes. Getting either one through DoW RMF authorization is a different category of problem: multi-year, expensive, dependent on specialized consultants, and fully capable of killing the program it was meant to protect.
What It Looks Like From the Inside
I have worked on programs where the compliance effort cost more than building the thing it was protecting. On others, the authorization timeline outlasted the useful life of the technology being authorized. Small companies with good products looked at the overhead and decided federal work was not worth it, a decision I understood even while it frustrated me. None of that reflects bad people. It reflects a process that grew faster than anyone's ability to absorb it.
This is not only a DoW problem. FedRAMP authorization is a long road for any cloud provider that attempts it, and CMMC has become a filter on which small defense contractors survive. The pattern repeats across frameworks. Each new one arrives carrying more controls and more required documentation than the one before it.
Why Government Cannot Fix This
After enough years inside, I stopped believing this could be fixed from within. The people I worked with cared about it, and most of them could describe the problem better than I could. The design of the system defeats them.
Government accumulates rules and has almost no mechanism for shedding them. A breach produces new requirements. An audit finding produces additional controls. Nothing in the machinery is built to take anything back out. The ratchet turns one direction.
The Incentive Structure
Consider the incentives at play:
- If you are a compliance officer who relaxes requirements and something goes wrong, you are responsible.
- If you are a compliance officer who adds requirements and something goes wrong, you followed best practices.
- If you are an agency writing policy, proposing to reduce requirements is politically risky.
- If you are an agency writing policy, adding requirements shows you are taking security seriously.
The result is predictable. Requirements accumulate and nothing removes them.
Government also will not build the tool that fixes this. Building and operating software platforms is not what the institution is good at, and any tool it did build would land inside the same procurement and authorization machinery it was meant to relieve. What government can do is write new process. It has now done exactly that, and the result is instructive.
What FedRAMP 20x Actually Did
FedRAMP 20x is the most serious attempt yet to compress federal authorization. It moves away from narrative documentation toward Key Security Indicators and leans on machine-readable artifacts instead of prose. I want to be fair to it. It does streamline, and the direction is right.
It also demonstrates the point I had been making for years. Capturing that streamlining requires substantial automation and a level of upskilling most organizations do not have, which leaves the savings theoretical for exactly the teams that need them most. Outside DoW it applies to cloud offerings, so a company with both a cloud product and an on-premise footprint runs both tracks. And it was designed as though people would go on doing the work by hand, at the moment that assumption stopped being true.
The clearest cost is the one nobody advertises. Before 20x, an organization could reasonably crosswalk a FedRAMP package into an ATO through NIST 800-53, because both sides spoke the same control language. Now the KSI path and the 800-53 path are separate efforts, and organizations that need both do both. This is what I expected would happen. It is another thing on top of the same thing.
There is a real gift buried in it, though, and it is not the one 20x was aiming for. Machine-readable artifacts are precisely the surface that agents work well against. KSIs and OSCAL are far easier to produce, check, and keep current with agents than a hand-written SSP ever was. 20x built the runway, then wrote a process that assumes humans will walk down it.
The Two Options on the Shelf
If you want to move faster on federal compliance today, there are two things available to buy. I have used both.
The first is a restrictive platform. You build inside someone else's authorized environment and inherit their controls. This genuinely works, and for some systems it is the right answer. The cost is that you accept their boilerplate and their constraints, which means the platform decides a great deal about your architecture. Inheritance is a real accelerant and also a ceiling.
The second is a GRC platform, sold as a way to streamline the process. In practice most of them are a checklist with somewhere to upload screenshots. I have used them, evaluated them, and watched teams fight them, and the failures are consistent. The tool assumes you already understand NIST 800-53 and framework mappings before it is any use to you, it costs six figures a year, and it is complex enough that configuring it becomes its own paid consulting engagement. What you have at the end is a pile of compliance artifacts, with your systems no safer and your authorization no closer.
Why Now
Here is the part that changed, and the reason I left when I did.
Agents can now do for compliance what they did for code. That comparison gets thrown around loosely, so let me be precise about what I mean by it. Writing software used to be the bottleneck in building software. It is not anymore. The work did not disappear, it moved. Engineers spend their time directing, reviewing, and deciding, and the volume of mechanical production they personally perform has collapsed. The people who adapted did not become less skilled. They became responsible for more.
Compliance fits that shift better than code did. Most of the labor is reading a requirement, determining whether a system meets it, gathering something that proves it, and writing that down in an approved shape. That is evaluation and evidence work. It is high-volume, heavily patterned, and almost entirely mechanical, and it is what compliance professionals currently spend their careers doing.
Nearly all of it can move to agents. The judgment stays with people, and so does the accountability. The production does not need to. What is left for the humans is the part that was always the actual job: a GRC engineer should be managing the process rather than living inside it.
That is a productivity change large enough to reorder the entire calculation. When evaluation and evidence collection stop being the constraint, timelines stop being governed by how many people you can put on documentation. It becomes possible to move quickly through even the most complicated frameworks, including the hardest one I know of, the DoW ATO.
None of this was available a few years ago, and that is not a small caveat. It is the entire reason I am doing this now. Had I left the Army in 2020 with this idea, I would have built another GRC platform, because that is all the technology of the time could have supported. I would have shipped a better checklist and become part of the problem. The tools to actually fix this did not exist yet. Now they do, and the frameworks are moving toward machine-readable artifacts at the same time. That window is why I left a job I loved.
This is what we are building at Pretorin. The platform, API, MCP server, and CLI are live, and the assumption underneath all of them is that an agent is a first-class user rather than a feature bolted onto a checklist.
My concern here predates the company. Military advantage runs downstream of software now, and the speed at which you can field something is itself a capability. I watched finished, working systems sit on a shelf while the documentation caught up, and I do not believe our adversaries are paying that same tax. We have the talent and we have the technology. What we have made difficult is the act of deploying it.
The lab had good people, real problems, and technology that mattered. I could have stayed in the dream job and built one more system, and that system would have hit the same wall as the one before it. Fixing the wall is worth more than building one more thing behind it.
So I left, at the first moment this was actually buildable.
If you have watched good technology die in authorization, or been priced out of federal work by compliance overhead, or spent years producing documents nobody reads to prove things you already knew were true, I would like to hear from you. You can get started with Pretorin today, and I read what comes back.
That is why Pretorin needs to exist, and why I am betting on it.
Isaac Faber
Founder, Pretorin
