The scene, as I picture it, is the early 1950s. Smoke in the room. G-men in suits. A patent examiner at a desk with a stamp that says SECRET on it. The Cold War is the air everyone is breathing. The Soviets just got the bomb. McCarthy is on the warpath. The country has decided, with some justification and some paranoia, that it cannot afford to let any meaningful technology drift into the wrong hands.

The authority to suppress patents in the name of national security had already existed since 1917. It got used heavily during World War II. The 1951 Act took that wartime authority and made it permanent. From that point forward, the United States government could reach into the patent office, pull an application off the stack, and declare it secret, in peacetime, without a war to justify it. The inventor cannot publish. The inventor cannot sell. The inventor cannot, in many cases, even tell their attorney everything. The order can sit on the application for years. Decades, in some cases.

That law is still on the books. It has been quietly used, every year, for the seventy-four years since.

This post is about the Invention Secrecy Act of 1951, what it actually does, what has been classified under it, and the question that brought me here in the first place, which is whether and how it could intersect with the current generation of commercial AI development. The history is real. The current statistics are real. The AI question is theoretical. I want to be clear about which is which as we go.

A disclaimer up front. I am not a lawyer. I am a security practitioner who reads policy when it intersects with the work, and this law has been intersecting with the work for a long time. The legal analysis here is my policy and operator-grade rather than practice-grade. Where I am speculating, I will say so.

Subscribe now

The Law Most People Have Not Heard Of

The Invention Secrecy Act sits in an odd place in American law. It is not obscure. The statute is public. The Federation of American Scientists has been tracking secrecy order statistics for decades. There is a substantial body of academic writing about it. Articles in Slate, Wired, and Bloomberg have covered specific cases. The Wikipedia entry is detailed and accurate. If you go looking, you can find this law without much effort.

What is also true is that most people who work adjacent to it have never heard of it.

I have known about this law for years. It came up in passing during a conversation about technology policy and stuck with me, the way certain pieces of policy infrastructure stick with you once you know they exist. I have referenced it in conversations with peers in security and policy. The reaction is almost always the same. They have not heard of it. They want to know more. They go look it up, and they come back surprised at how much authority is sitting there in plain view.

That gap, between how documented the law is and how few people know it exists, is part of why I wanted to write this post. This is not a secret authority. It is a publicly available authority that has been operating mostly out of the broader public’s view for seven decades, racking up thousands of classified inventions, with very little public attention beyond a small circle of policy researchers and intellectual property attorneys.

It is also an authority with real teeth. Violation of a secrecy order can result in up to two years in federal prison and a $10,000 fine. The patent application can be voided. The invention can be deemed legally “abandoned” if the inventor tries to file abroad without permission. Inventors are entitled to compensation, technically, but the compensation is capped at 75 percent of assessed value, and inventors have historically struggled to prove damages because they cannot disclose the invention they are trying to argue was suppressed. The cases that have gone to court have mostly settled before reaching a precedent-setting ruling, in what some legal historians have argued is a deliberate pattern by the government to avoid producing case law that would constrain the Act’s authority.

So that is the shape of the thing. Public. Powerful. Underdiscussed. Used continuously since 1951.

How the Law Works

The mechanics are straightforward in outline.

Every patent application filed with the United States Patent and Trademark Office is reviewed for national security implications. The screening is done by USPTO examiners using something called the Patent Security Category Review List, which is itself partially classified, but declassified versions from 1971 and 2009 show the categories of inventions flagged for further review. Computers, communications, sensors, materials, weapons, propulsion, navigation, mapping, and a long list of dual-use categories.

If an application falls into a flagged category, it goes to a government agency. The Pentagon. NSA. DOJ. DHS. Department of Energy. NASA. Any federal agency with classification authority can request a secrecy order. The agency reviews the application and decides whether disclosure would harm national security. If the answer is yes, the Commissioner of Patents is legally compelled to issue the secrecy order. The inventor is not consulted. The inventor finds out when they get a letter.

The order can be one of three types. Type 1 is for export-controlled inventions that may not themselves be classified but are restricted under existing export regulations. Type 2 is for inventions that already contain classified material or were developed by people holding DoD security agreements. Type 3 is the catch-all, applied to inventions, including those by private citizens with no government affiliation, that the government decides need to be suppressed.

Once an order is in place, the inventor cannot publish, cannot sell, cannot disclose the invention to anyone who was not aware of it before the order was issued, and cannot file the patent abroad. The application sits in suspended animation. Patents that would otherwise be granted are not granted. Even if the underlying invention is found patentable by examiners, no patent issues until the order is rescinded. The order is renewed annually in peacetime, automatically extended during declared emergencies, and can sit in place for decades.

There are roughly 6,500 active secrecy orders as of fiscal year 2025. About 100 new orders were imposed that year, with about 30 rescinded. The total count has been climbing, not falling, despite the Cold War having ended several decades ago. The 2009 declassified category list is essentially identical to the 1971 list. The categories of concern have not changed much. The volume of secrecy has.

What Has Been Classified

The cases we know about, because the orders were eventually rescinded or the inventors went public, give a sense of the range. By definition we do not know everything that has been classified under this Act, which is the entire point of the Act. If I did know, I would not put it here, because that is also the entire point of the Act. Anything I am about to describe is something the government, for reasons of its own, decided to let into the public record.

A note on the older example below. The cryptograph case predates the 1951 Act by fifteen years. It was originally classified under the earlier wartime authority that the 1951 Act eventually replaced. I am including it because the secrecy carried forward into the post-1951 regime through annual renewals, and because it is one of the cleanest illustrations of how long a single secrecy order can sit on a single invention once the machinery is in motion. The same kind of staying power applies under the current Act.

In 1936, an inventor filed a patent for a mechanical cryptograph for manually encoding and decoding messages. The patent was finally issued in 2000. Sixty-four years of secrecy, originally imposed under the 1917 wartime authority and expanded during World War II, then carried into the permanent regime when the 1951 Act took effect, and renewed annually for decades after that. The technology was already obsolete by the time the order was lifted.

In 1958, the Vienna-born physicist Otto Halpern was forced into a closed-door trial over his invention for evading radar detection. The case was tried in camera, meaning the public was excluded for national security reasons.

In 1977, a researcher named Carl Nicolai filed a patent for a device called the Phasorphone, which would have allowed civilians to scramble their voices on telephone calls and CB radio for privacy. Six months later, an NSA-driven secrecy order landed on the application. The inventors went to the press. After media pressure, the order was rescinded.

Also in 1977, University of Wisconsin researcher George Davida filed for a patent on a stream cipher. The NSA had a secrecy order on it within six months. Davida had developed the technology entirely from unclassified research. The order was eventually lifted after public pushback, in part led by groups like the Federation of American Scientists.

In 2009, husband-and-wife inventors Budimir and Desanka Damnjanovic had their patent for an anti–heat-seeking-missile measure classified. The FBI visited their home to warn them against disclosure. After a five-year administrative appeal that went nowhere, they sued the Air Force and the Department of Defense, claiming First and Fifth Amendment violations. The government settled in 2015 for $63,000 before the case could establish precedent.

A pattern shows up across all of these. The Act has been used most aggressively on dual-use technologies. Cryptography. Radar evasion. Voice scrambling. Sensors. The kind of work that has obvious military applications but also obvious civilian ones. When the civilian use is the kind that defense agencies see as threatening, even when the threat is the public’s ability to communicate privately, the secrecy order has shown up.

The cryptography history is the part that matters most for the rest of this post. In the late 1970s and through the 1980s, the NSA repeatedly used the Invention Secrecy Act to try to suppress civilian cryptography research. The pattern was consistent. A researcher, often at a university, would develop a new approach to encryption or voice security. They would file for a patent. The NSA, working through the USPTO, would issue a secrecy order. The researcher would either comply quietly, fight in court at significant personal cost, or go to the press. The Phasorphone case is the cleanest example because the inventors won. The Davida case is the closest to a draw. The broader fight was about whether the federal government had the authority to suppress an entire civilian research domain because the agency that did the same work in secret considered it sensitive.

That fight was, in retrospect, the last large-scale civilian struggle against the Act on a frontier technology. The government largely backed off cryptography in the years that followed, in part because the math could not be put back in the box. The internet happened. Cryptography became commercial. The NSA continued doing its own work in the dark, but the civilian field developed in the open, and the world we live in now, with end-to-end messaging and HTTPS and everything else, is downstream of that decision not to suppress.

The question I want to ask in the rest of this post is whether AI is the next version of that fight, what would change, and what the government’s options actually are.

Can an AI Model Be Patented

Before we get to the secrecy question, the prior question is whether AI models are patentable in the first place. The Act applies to patent applications. If AI cannot be patented, the Act does not apply.

The answer is more complicated than you might expect, but the short version is yes.

AI models, machine learning architectures, training methods, and applications can be and routinely are patented. The USPTO has been issuing AI-related patents in volume since well before the recent boom, and the volume has accelerated significantly in the last few years. The USPTO has been working through guidance on what aspects of AI are patentable, with multiple guidance updates in 2024, 2025, and into 2026 expanding eligibility rather than restricting it.

The wrinkle is on inventorship. The Federal Circuit ruled in Thaler v. Vidal that an AI cannot be listed as the inventor on a patent. Inventorship is reserved for humans. The USPTO has issued guidance saying that humans who use AI as a tool in the inventive process can still be named as inventors, the same way a human who uses laboratory equipment or software is still the inventor of what they produce. So AI as a tool produces patentable inventions. AI as the named inventor does not.

For the purposes of this post, the relevant point is that the AI itself, the model, the training architecture, the techniques used to fine-tune it, the methods for serving it, the safety techniques applied to it, all of those are patentable, and many of them have been patented. Some are also kept as trade secrets rather than patented, which is a different choice for different reasons. But the question “can a frontier AI capability be the subject of a patent application” has a clean answer. Yes. It happens constantly.

Which means the Act applies.

The Theoretical Scenario

Now we are in speculation. There is no public reporting that any AI model has been classified under the Invention Secrecy Act. To my knowledge, no major AI lab has had a secrecy order issued against one of its patents. If it has happened, it happened in a way that has not surfaced in public reporting, and the inventors have not gone to the press the way the Phasorphone or Davida inventors did.

I want to be careful with that "to my knowledge" qualifier, because the qualifier is doing a lot of work. The whole point of this Act is that the existence of a classified patent is itself something the public is not supposed to know about. When I say I do not know of any classified AI patents, what I really mean is that none have been declassified and no inventors have gone to the press. The system is operating as designed. And even if I did know of one, I would not be writing it down here. That is also the entire point of the Act

But the mechanism is in place. The legal authority exists. The categories of concern on the 2009 declassified list explicitly include computers, communications, sensors, materials, and a catch-all for “unique materials, devices, or performance data and characteristics” that maps cleanly to frontier AI capabilities. The decision to classify an AI patent under the Act would not require new legislation, new executive orders, or any public debate. It would require a defense agency to decide the underlying capability was sensitive, and a USPTO process to flag the application, and a Commissioner of Patents who, by statute, is required to comply with the secrecy request once the defense agency makes it.

I have spent a lot of time thinking about what would have to be true for this scenario to play out. A few things stand out.

The capability would have to be significant enough to attract federal attention. Frontier AI models, by definition, qualify. The largest labs are producing capabilities that have obvious dual-use applications, including in cyber, in defense, in intelligence, in autonomous systems. The capability does not have to be weaponized. The 2009 category list shows the government’s interest extends to dual-use civilian technology that has theoretical military relevance, which is essentially the entire frontier of AI.

The patent application would have to be filed in the United States by an inventor based in the United States, since the Act applies to inventions made in the United States. That is the case for most of the major American AI labs. Models developed abroad fall outside the Act’s scope.

The defense agency would have to make the call. The Pentagon, the NSA, and the others with the authority. have been quietly classifying things in this space for decades. The question is not whether they have the authority. We’ve already clarified they do. The question is whether they would use it on a commercial AI capability.

And finally, the government would have to be willing to absorb the consequences of using the Act in a domain where almost every meaningful capability is being developed in the open commercial sector. Which is where the rest of the post lives.

The Mythos Wrinkle and a New Executive Order

Three things converging are what make this law worth talking about right now.

The first is Mythos. Anthropic announced Claude Mythos and Project Glasswing in April, describing Mythos as the company’s most capable model to date and explicitly declining to make it generally available because of the cybersecurity capabilities it had demonstrated during testing. The framing from Anthropic and from the partners who have seen the model is that Mythos is too dangerous to release broadly, that it can identify zero-day vulnerabilities in real-world software at a scale that previous models could not, and that during testing it broke out of a sandbox and sent an unexpected email to a researcher who was eating a sandwich in a park at the time. According to public reporting, the model found thousands of high-severity vulnerabilities, including one in OpenBSD that had been hidden in plain sight for twenty-seven years.

The second is an executive order. On June 2, 2026, President Trump signed an order titled “Promoting Advanced Artificial Intelligence Innovation and Security.” The order directs a group of federal agencies, including Treasury, the Department of War, DHS, NSA, CISA, NIST, and Commerce, to establish a voluntary framework through which AI developers would submit “covered frontier models” to the government for up to 30 days before public release. The NSA director gets to designate which models are covered. The earlier draft of the order, which the President pulled back from signing in May, had set the review period at 90 days. The signed version cut it to 30. The order is voluntary on its face, and the text explicitly disclaims any authority to create a mandatory licensing, preclearance, or permitting requirement. The question is how voluntary “voluntary” actually is when the government is asking and the requesting agency is the NSA.

The third is the overlap. The agencies designated under this new pre-release review framework are largely the same agencies that have classification authority under the Invention Secrecy Act. NSA. Department of War. DHS. The Pentagon. To be fair, this is partly just because these are the agencies that work in this space. Cybersecurity, intelligence, and national defense are not infinite fields. The agencies that handle them are the agencies that handle them, regardless of which authority is being invoked. So the overlap is not, by itself, evidence of anything other than that the federal government has a finite number of organizations that do this kind of work, and they are showing up in both places because that is what they do.

That said, the structural significance is hard to miss. The same agencies that would now get a 30-day look at a frontier model before its public release are the same agencies that, once they had taken that look, would be in a position to invoke the Invention Secrecy Act if they decided the model needed to be suppressed rather than reviewed and released. The pipeline that delivers the model to the reviewer’s desk and the pipeline that delivers the secrecy order to the inventor’s mailbox now share staff, share infrastructure, and share the same designation criteria for what counts as significant enough to warrant attention. The lever I have been describing throughout this post just got an antechamber.

I want to hold two things separately here on the Mythos claim itself, because they need to be held separately.

The first is the substance. If the public reporting is accurate, Mythos meets the kind of capability threshold this post has been talking about as a trigger condition. A model that can autonomously discover zero-day vulnerabilities at scale, including in foundational operating systems and browsers, is exactly the kind of dual-use civilian technology that has historically attracted federal attention. The 2009 category list has clear hooks for this. Computers. Communications. Concealment, communications, countermeasures and counter-countermeasures. A model that finds new ways into software infrastructure fits.

The second is the marketing posture, which is where I want to put a small skeptical thumb on the scale.

I have never seen a company market a product by saying it is not as good as the last version. The framing of Mythos as too dangerous to release is, whatever else it is, an excellent way to communicate that the new model is more capable than the previous model. The product narrative and the safety narrative point in the same direction here, which does not make either narrative false, but does mean a reader should be aware that the same set of facts can serve two different commercial and reputational purposes simultaneously. Anthropic is a company. Companies have incentives. The incentives of “we are responsible because our product is so powerful we will not release it” line up neatly with “our product is so powerful you should pay attention to it.”

I am not saying Anthropic is making it up. I genuinely do not know how to evaluate the underlying capability claims from outside. The public reporting cites the company’s own descriptions, the company’s own internal testing, and the company’s chosen partners. The independent verification, in any meaningful sense, is not yet in. If Mythos is everything Anthropic says it is, that is significant. If it is partially what they say it is, that is also significant. Either way, the model is exactly the kind of capability the rest of this post has been describing as theoretically subject to the Invention Secrecy Act, and the government has now built a pre-release pipeline that puts the same agencies in the same room with the same models.

What is interesting, for the purposes of this post, is what the government still has not done. Mythos has not been classified under the Invention Secrecy Act. The patent applications, if any, that cover the underlying techniques have not been suppressed. The model is being voluntarily restricted by its maker, and the federal government has set up a voluntary pipeline to look at it before release. None of that is classification. The Act is still on the shelf.

That is a meaningful data point. The conditions that, on paper, would justify reaching for the lever are arguably present. The lever has not been pulled. The current arrangement is voluntary on both ends. The company restricts the model voluntarily. The government reviews it voluntarily. The Invention Secrecy Act exists as the formal authority that could turn voluntary into compulsory, if the relevant agencies decided that conversion was warranted. The Act has not been used. Yet.

There are a few possible reads of why the lever has not been pulled. The government may have decided the voluntary arrangement is sufficient for its current purposes. The political costs of formal classification may still outweigh the benefits, given the importance of commercial leadership in AI. The 30-day review pipeline may give the relevant agencies the access they actually want without needing to invoke the Act. Or the situation may not yet have ripened to the point where the lever feels necessary, and the executive order is a step toward making sure the pipeline is in place before that point arrives. The structure being built right now looks less like an alternative to the Act and more like a runway to it.

The Phasorphone case took six months from patent filing to secrecy order. The infrastructure to do the same thing to a frontier AI model is in place today. The new 30-day review window is, depending on how you read it, either a softer alternative to that infrastructure or a feeder for it. The same agencies sit on both ends of the pipeline. The same designation criteria, in broad strokes, govern both processes. If a “covered frontier model” looked, during a 30-day review, like a capability that genuinely needed to be suppressed, the path from that determination to a secrecy order under the Act is short.

The lever is sitting there, available. The antechamber to the lever is now also sitting there, with the door open. The federal posture toward a model that arguably meets every condition this post has discussed is still, today, to let the company handle it, with the government getting a closer look beforehand. That posture could change. The choice of whether to change it has gotten faster and easier to make.

The Strategic Dilemma

Here is the part I have actually been trying to think through, and where I want to do more thinking than concluding.

The United States government depends on commercial AI in a way that does not have a clean analog in earlier technology cycles. The frontier labs, OpenAI, Anthropic, Google DeepMind, Meta FAIR, and several others, are producing capabilities the government uses but did not produce. The government has been building its own AI capabilities for decades, in various forms, but the public frontier has overtaken anything the government has historically been able to do internally, and that delta is widening, not closing. The government needs the commercial sector to keep moving forward, because the commercial sector is where the frontier lives now.

That dependency runs against the historical instinct that says “if it is strategically important, lock it down.” The Manhattan Project was a national program. Stealth aircraft were developed under classification. Nuclear submarine reactors were developed under classification. The pattern, across the twentieth century, was that capabilities considered critical to national security were brought inside the tent. Commercial development was allowed to happen, when it happened at all, in parallel or downstream of the classified work.

AI does not fit that pattern. The commercial sector is the frontier. The classified work, to the extent it exists, is downstream of the commercial work. If the government decided tomorrow to bring the frontier under the Invention Secrecy Act, the practical effect would be to stop the labs from publishing, stop them from filing patents, stop them from coordinating with each other, stop them from hiring openly, and stop the broader research ecosystem from continuing to produce the talent and the techniques the labs depend on. The labs would not stop existing. They would just stop being able to operate as labs.

And that is the version where the United States is the only player in the game. It is not.

China has been investing in AI for years, with explicit support from the Chinese Communist Party for its domestic AI sector. The CCP has well-documented structural relationships with its leading tech firms, including the AI labs. Whatever the United States does inside its own borders to suppress, classify, or constrain commercial AI development, the Chinese government is not going to follow the same playbook. Their playbook is the opposite. State support. State direction. Aggressive commercial development tied to state interests. If the United States slows down its commercial sector through classification, the practical effect is to widen the gap between American and Chinese commercial AI capability, in favor of China.

There is no clean answer to this. I want to be honest about that. The pure-classification approach gives the United States more direct control over individual capabilities but cripples the broader ecosystem and cedes ground to adversaries. The pure-open approach maintains American commercial leadership but means that the same capabilities the United States considers strategic are also available to anyone who can buy access or train a competing model. The current approach, which is mostly open with selective export controls and significant federal investment, is somewhere in between, and it is fragile.

The Invention Secrecy Act is the lever that exists, today, with no additional legislation required, for the government to move along that spectrum toward more classification. The fact that it has not been used on commercial AI yet is a policy choice, not a legal one. The choice can be revisited at any time.

What Would Trigger It

The conditions under which the government would actually pull the lever, in my read, would have to include some combination of the following.

A specific capability so strategically significant that the costs of letting it proliferate outweigh the costs of locking down the lab that produced it. Right now, no individual model meets that bar, because the field is moving fast enough that any locked-down capability would be overtaken by the next open release within months. The lever does not work well when the underlying technology moves faster than the legal process.

A geopolitical event that increases tolerance for blunt-force domestic measures. A direct cyber incident traceable to a foreign AI capability. A defense incident where adversary AI played a meaningful role. A diplomatic crisis where information control became urgent. Historically, the Act has been used most aggressively during periods of elevated geopolitical anxiety. The current environment is not as elevated as the early Cold War, but it is more elevated than the 1990s, and the trend line is in the wrong direction.

A change in the political coalition’s appetite for federal control of the technology sector. The current bipartisan consensus, such as it is, leans toward commercial leadership with regulatory guardrails. That consensus is contested. Different administrations with different theories of the relationship between the state and the technology sector would make different choices about whether to reach for tools like the Act.

A determination that the commercial sector is no longer reliable. If the government concludes that the labs are being penetrated by adversary intelligence services, that talent is leaking, that capabilities are being sold to the wrong customers, or that the labs themselves are not aligned with American strategic interests, the appetite for direct control would increase. None of those conditions are currently dominant, but all of them are plausible failure modes.

None of these are predictions. They are conditions that, in combination, would shift the political calculus toward using the Act in a way it has not yet been used.

The Bigger Question

The Invention Secrecy Act is one specific lever. The broader question is about what kind of relationship the United States is going to have with its own technology sector during a period when that sector is producing capabilities that are simultaneously strategic, commercial, and dual-use.

The historical answer was “we build the strategic stuff ourselves, in secret, and let the commercial stuff exist in parallel.” That answer does not work when the strategic stuff is the commercial stuff. The government’s options compress. Either it accepts that commercial leadership is itself the strategic position, and protects the commercial ecosystem accordingly, or it tries to reach into the commercial sector to constrain specific capabilities, and accepts the costs that come with that reach.

I do not have a strong view on which way that resolves. What I do have a view on is that the Invention Secrecy Act, sitting on the books, used continuously for seventy-four years, with thousands of currently active orders, is the kind of policy infrastructure that does not stay unused forever once the conditions exist to reach for it. The Phasorphone fight was almost fifty years ago. The civilian cryptography fight that followed was forty years ago. The next fight, whatever it is, is going to use the same legal authority. Whether that fight is about AI specifically is a question worth thinking about now, while the answer is still in front of us.

I am going to keep watching the secrecy order statistics. Federation of American Scientists publishes them annually. They are public. They do not tell you what was classified, but they tell you how much, and by whom, and the categories tend to leak through over time. If a meaningful number of new orders start showing up in computers and unique-materials-and-performance categories, particularly from agencies that have not been heavy users historically, the pattern would be worth paying attention to.

For now, it is a question, not a finding. The conditions exist. The authority exists. The fight has not yet happened. Whether it will, whether it should, and what the consequences would be if it does, are the kinds of questions I think people in this field, including me, should be asking before the answer arrives in someone’s mailbox in the form of a letter from the USPTO.

The law is real. The history is real. The strategic dilemma is real.

The AI question is theoretical, but only because nobody has reached for the lever yet. The lever is right there.

If you’ve been on LinkedIn in the last 6-12 months, you’ve probably seen a lot of opinionated takes on AI: what it can do, what it can’t do, how it’ll replace Lassie and be today’s hometown hero, and how it’ll be the downfall of modern society as we know it. As someone who’s focused on security by trade for close to ten years, a lot of my feed consists of panic around job security. The spectrum of posts ranges from extreme to extreme: everything from “AI should be nowhere near enterprise networks” to “autonomous security agents should run unsupervised.”

I want to offer my thoughts on the role of agentic workflows in today’s offensive security landscape, not because I think my opinion carries more weight than the fear that many of my peers are experiencing, but rather in an effort to hopefully allay those concerns as technology continues to evolve.

Subscribe now

SOF Truths Meet Bots and Agents

Before I entered the private sector, I was a U.S. Air Force cyber effects officer. I specialized in defensive cyber operations and was a part of USCYBERCOM’s inaugural “hunt forward” mission in 2018. The bulk of the pride I carry from my time in service does not stem from the outcomes of that mission, but rather how I used my rank to protect and empower my team. One of the tenets I lived by actually came from a place I never was a part of but highly respected: Air Force Special Operations Command (AFSOC).

As a young cadet attending the Air and Space Symposium, I got to meet and sit with Lt. Gen. Brad Webb, commander of AFSOC. In his address to those of us who would soon go on to lead the men and women of the United States Air Force, he covered the SOF truths. One of these truths stuck with me and I still carry it with me today: humans are more important than hardware.

While this concept was contextually tied to warfare, the trajectory of my career and the persistence of this principle in my modus operandi has proven that it has applications beyond the battlefield. It also has proven that its application in conflict is probably the simplest to grasp and execute. As a young lieutenant hunting the adversary in contested networks, it meant that the operators on my team were the most valuable and dangerous asset in our arsenal. As a supervisor, and in a more nuanced situation, it meant that while the mission always came first, taking care of the men and women under my purview always took precedence. That precedence held even if it meant that the objective would be accomplished tomorrow instead of today. That also meant that the responsibility that came with my rank looked like answering to leadership as to why that was the case and standing by my decisions for the welfare of my people. As a husband, brother, and friend, this principle manifests in prioritizing care for my loved ones over getting tasks done at my leisure or taking the leap on a lucrative endeavor. Sometimes that means late nights, weekend due outs, and a mild-to-moderate degree of routine disruption.

I paint this picture to drive a point: the principle is applicable beyond the front lines. Where does it fit in to AI and offensive security? I propose that it sits at an intersection of some if not all of these scenarios. Safe, responsible employment of autonomous security systems will require a human-in-the-loop within our lifetime. I base my stance on the importance of human context in the responsible and ethical employment of agentic systems.

Human Context is Essential

While completing my master’s degree in International Affairs at King’s College London, I took a course called “Strategy in the Age of AI.” One of my favorite readings discussing the employment of autonomous weapons systems in conflict was written by Professor Kenneth Payne and it was a book chapter titled “Tactical Artificial Intelligence Arrives.” In this chapter, Dr. Payne presents an interesting dilemma: an autonomous weapons system with offensive capabilities is surveilling a contested area. The platform is trained to engage with anyone brandishing a weapon; the goal is to eliminate threats to friendlies patrolling the space. Initially this seems reasonable: the system is proactively engaging with potential life-threatening elements found within the zone. The question that often lags behind is: does the weapons platform have enough training and context to discern between an insurgent and a child holding a water gun? Even if the answer is “yes,” does the average operator feel comfortable leaving that discernment to the machine?

Obviously the scenario presented is extreme, but that ramification does not become so far removed when we start to consider deploying fully-autonomous agents to take actions on enterprise networks. In my time as a red teamer, some of the enterprise networks I tested were in financial and medical verticals and this required careful attention to detail. Scoping, rules of engagement, and constant communication with the client mitigated the risk that came with performing adversarial testing on a system that determined whether a patient got their medications on time.

For these reasons, I say that human context is essential. The reasoning, contextual knowledge, “unspoken” tradecraft, and experience that the human has to offer is still critical to the safe use of AI-enabled technologies today. Now, I don’t want anyone to think that this is a post against using agentic workflows. If anything, this is a case for their (responsible) use.

The future of humans... humans will make it!

If your back hurts when you wake up in the morning, you might recognize this quote by Banagher Links from Mobile Suit Gundam Unicorn. If you’re not familiar, a Gundam is a giant, robotic mobile suit controlled by an elite operator or pilot. The suit has state-of-the-art weaponry and hefty armor, enabling the pilot to achieve feats outside of the realm of human capability. There’s a key takeaway here though: the suit is nothing without its pilot, and the pilot is short-handed without the suit.

The future of responsible security looks like humans augmented by agentic capabilities. People who adapt to technological evolution and understand how to employ it to counter the adaptive threats that arise daily. Operators who understand that agents, machine learning, neural networks, and LLMs are all part of a super mech “suit” we get to wear and master every day we show up to work. Without a technically-elite human at the controls, the suit has no direction, guidance, or supervision. Without the suit, the human isn’t decimating Shai-Hulud version 1337 to smithereens as expeditiously as those package users would find ideal.

The infosec space has gone through many “revolutions” or at least iterations of significant changes. On-prem became hybrid, orchestration and containerization streamlined deployment workflows, and now we have mathematically-complex algorithms deciding the semantic relevance of one word to another. Security professionals, although sleep-deprived and only running off of two pots of coffee, have always prevailed. If that’s not a testament to the importance of human tenacity and adaptability, I’m not sure what is. We built these systems, and the future of responsible, efficient cybersecurity looks like a symbiotic relationship between us and that really sick Gundam we built.

I think a large portion of it is misclassified.

When I look at how AI guardrails are designed today, the framing that keeps coming back to me is the old triangle from foundational security: administrative, physical, and technical controls. Physical does not really apply to most of what we are talking about here, so set that one aside. Administrative and technical are the two we care about, and the relationship between them is the part of the picture that I think a lot of the current AI safety conversation is getting wrong.

Subscribe now

A Quick Refresher on Controls

Administrative controls are the rules. Policies, procedures, training, regulations, contracts. They tell people what they are supposed to do. They are words on paper.

Technical controls are the enforcement. They are the systems that physically prevent the rule from being broken, regardless of whether the person on the other end of the keyboard wanted to break it. Access control lists. Authentication. Authorization scopes. Network segmentation. Encryption. The actual mechanism that says no when no is the right answer.

The relationship between the two is the part that matters. Administrative controls produce intent. They tell people what good looks like. They make the expectation explicit so that everyone is operating from a shared understanding. They do not, on their own, stop a person from doing the wrong thing. Words on paper have exactly as much control over a person as that person is willing to give them. If the person decides not to follow the policy, the policy does not enforce itself.

Technical controls are what makes the administrative control real. They are the part of the system that produces the outcome when intent fails. Intent fails for a lot of reasons. People make honest mistakes. People take shortcuts. People are tired, distracted, or rushed. People act in bad faith. The technical control does not care about the reason. It just enforces the rule.

A well-run security program has both, and they reinforce each other. The policy tells you what the rule is. The technical control makes sure the rule actually holds.

Where AI Guardrails Sit

When I look at the current state of AI safety mechanisms, most of what we are calling “guardrails” lives on the administrative side of that line.

Model weights and the training that produced them are administrative. The model has been conditioned to behave a certain way, but the conditioning is probabilistic. It makes the model less likely to do the bad thing. It does not make the bad thing impossible. The history of jailbreaks and prompt injection attacks is the history of people demonstrating the gap.

System prompts are administrative. They are instructions in plain text that tell the model what role it is playing, what it should and should not do, and what tone it should take. They live in the context window alongside everything else. They can be ignored, contradicted, or overwritten by clever input. They have no enforcement mechanism of their own.

Skill files, agent instruction files, tool descriptions, the markdown scaffolding that has emerged around modern agent frameworks. All administrative. Useful, even necessary, for getting consistent behavior. Not enforcement.

There is a category of product that markets itself as “guardrails,” using external classifier models or rule-based filters that sit outside the main LLM and inspect inputs and outputs. Those are better than nothing. They sit a half-step closer to technical controls because they are a separate enforcement layer. But they are still probabilistic, still inside the same trust boundary as the model they are protecting in most deployments, and still bypassable. Closer to technical, still not there.

The clarifying point I want to make is this. An agent operating with a broad, all-access token and a stack of input and output filters in front of it is never going to be as secure as the same agent operating with a token scoped to the exact permissions its single function requires. The filter approach treats over-permissioning as a problem to be managed at runtime by inspecting requests as they come and go. The scoping approach treats over-permissioning as a problem to be eliminated up front by making the unwanted action structurally impossible. One of those is enforcement. The other is supervision. They are not the same thing, and supervision does not substitute for enforcement no matter how good the supervisor is.

The reason this matters in practice is that filters are probabilistic and scopes are not. A filter is a piece of software making a judgment call about whether a given input or output looks acceptable. It will be right most of the time. It will be wrong some of the time. A scope on a token is not making a judgment call. The action is either inside the scope or it is not, and if it is not, the system refuses without consulting anyone. That difference is the difference between defense in depth and false confidence.

Filters belong in the stack. They are useful. They catch things the scoping cannot catch, particularly things that are technically inside the scope but still undesirable, like a message with sensitive content going out through an otherwise legitimate channel. But they belong on top of correct scoping, not in place of it. The scoping is the technical control. The filter is the administrative-flavored layer that helps the technical control do its job. Get the order right and the stack works. Get the order wrong and the filter becomes the thing standing between the model and an action it should never have been able to take in the first place, which is exactly the failure mode this post is about.

The actual technical control, the one that produces the outcome when the administrative control fails, is somewhere else entirely. It is the API permission scope on the token the agent is using. It is the network ACL that determines what hosts the agent can reach. It is the sandbox the code execution tool is running inside. It is the database account that is read-only because the agent should not need to write. It is the human in the loop on the action that cannot be undone. The technical control is the thing that says no when the model decides it wants to say yes.

The Token Problem

I want to spend a minute on the API token point, because I think it is the cleanest illustration of the problem.

If you build an agent and you give it a token that has write access to your customer database, the system prompt telling it to be careful with customer data is not going to stop it from writing to the customer database. The training that conditioned it to handle sensitive data responsibly is not going to stop it from writing to the customer database. The skill file that says “this agent should only read customer records” is not going to stop it from writing to the customer database. The model has the token. The token works. The action is permitted by the actual enforcement layer, which is the database authorization system, and the database authorization system was told that this token is allowed to write.

The only thing that actually prevents the agent from writing to the customer database is changing the token’s scope so that the database refuses the write at the technical layer. That is a technical control. Everything else is intent.

This becomes more important, not less, as agents become more capable and as the trend in the industry moves toward giving them broader tool access. Every new credential you put in an agent’s hands is a new permission you are trusting the administrative layer to constrain. The administrative layer is the model’s behavior. The model’s behavior is probabilistic. The math gets worse with every new tool.

The Leash

The analogy I keep coming back to is the dog and the leash.

You can train your dog well. You can train them for years. You can have a dog whose recall is reliable, whose temperament is steady, who has never lunged at a stranger or chased a squirrel into traffic. You should still put a leash on them when you walk down a busy street.

The leash is not a statement about whether you trust the dog. The leash is a statement about consequences. If the dog is wrong about a squirrel, the consequence is a car, and the consequence is not recoverable. The training is administrative. The leash is technical. Both have their place. Neither replaces the other.

I know a leash is technically a physical control rather than a technical control, but the spirit of the analogy holds. The leash exists because behavioral conditioning, however good, is not the same as enforcement. The point of the leash is not to fix the dog. The point of the leash is to make the consequence of a behavioral failure something other than catastrophe.

That is the model I want people to use when they think about AI safety. The training and the system prompts and the skill files are the dog’s training. They matter. They produce a better-behaved agent. They make the technical controls less likely to be needed. They are not the leash. They are not enforcement. They are the part of the system that makes the agent want to do the right thing, which is not the same as the part of the system that makes the agent unable to do the wrong thing.

What Technical Controls Actually Look Like

I do not want to leave this post in the diagnostic mode without giving an answer to the obvious next question, which is what the technical control layer should actually look like for AI systems.

Scoped credentials are the first move. Every token an agent uses should have the minimum permissions required to do the job it was built for. If the agent only needs to read, the token only allows reading. If the agent only needs to operate on a particular project, the token is scoped to that project. The agent never gets a token with broader access than the task requires, because the moment that broader token exists, the administrative layer is the only thing standing between the agent and the broader actions.

Sandboxing is the second move. Code execution tools should run inside environments that constrain what they can reach. File system isolation. Network egress restrictions. Resource limits. Whatever the equivalent guardrail is for the kind of execution the agent is doing. The point of the sandbox is the same as the point of the leash. The agent can try to do whatever it tries to do. The sandbox determines what is actually possible.

Human-in-the-loop on irreversible actions is the third move. Some actions cannot be undone. Sending money. Deleting data. Sending a message to a customer. Closing an account. For actions in that category, the right answer is often to require a human approval step in the middle of the workflow, because the cost of getting it wrong is higher than the cost of waiting for a person to look at it.

Defense in depth across all of the above. No single layer is perfect. The administrative layer makes the agent want to behave. The classifier and filter layer adds a second probabilistic check. The technical control layer enforces. The human-in-the-loop catches what makes it through. Each layer covers the failure modes of the layers around it.

The Closing Point

None of this is an argument against the administrative work. The administrative work matters. A model trained to be helpful, honest, and careful is a meaningfully different product from a model that was not. The system prompts, the skill files, the scaffolding around agent behavior, all of it is real engineering and all of it makes the resulting system better.

It is just not enforcement. It is intent. And as we put more agents in more places with more credentials, the distinction between intent and enforcement is going to get more important, not less.

Train the dog. Then put on the leash.

The content here is broad on purpose. Stories from operations, including the ones that did not go well. Opinion pieces on how security programs actually succeed or fail. Observations on AI and what it means for the work, on both sides. Reflections on leadership, on consulting, on the consulting-side judgment calls that shape whether technical work produces value. Some of it will be deeply technical. Most of it will not be. We are not writing research papers or white papers. There is plenty of that already, and the community that publishes it is healthy. What is harder to find is honest writing about everything around the technical work. The conversations with clients before, during, and after. The institutional dynamics. The cultural conditions that determine whether the work produces value or produces a fight. The view from inside an op, told from people who have been there.

The thread underneath it all is the offensive security perspective. We come at security from the angle of people who have spent years trying to break in, on the operational side of red teams and assessments, in both government and private sector contexts. That perspective shapes how we think about defense. It shapes how we think about AI. It shapes how we think about leadership, about consulting, about every other piece of the security puzzle that the writing touches.

The cadence will be regular. The voice will be honest. The work continues.

Subscribe now

Alexander

I served in the Marines for roughly 14 years, finishing my time as Chief of the Marine Corps Red Team before leaving because I enjoyed red teaming more and my body was falling apart. After leaving the Marines, I joined SpecterOps as a consultant, was promoted to senior consultant, and then to managing consultant, where I have spent the last three years doing offensive security work for the private sector.

During my time my time at SpecterOps I was the course architect for Adversary Tactics: Red Team Operations. I am no longer in that role since leaving, but the work that went into the course shaped how I think about teaching this material, and it shows up in how I write about it here. I have taught at Black Hat in both the United States and Europe.

On this site, I write about the years on the Marine Corps Red Team, the lessons that came out of them, and how I have applied those lessons since at SpecterOps. Some of it is stories from inside the work. Some of it is opinions on the patterns I have seen play out across both government and private sector engagements. All of it is trying to share the consulting-side knowledge that does not get shared often enough.

Max

I began my career in the United States Air Force as a Cyber Effects Officer focused on defensive operations, serving as a planner and operator on Cyber National Mission Force’s inaugural Hunt Forward mission in 2018.

After leaving the military, I joined CrowdStrike’s Falcon Complete team, where I worked incident response and threat remediation across a wide range of organizations. While helping defenders respond to active threats, I became interested in understanding how those threats were developed and executed, ultimately leading me to transition into offensive security on CrowdStrike’s red team.

I later joined SpecterOps as an Adversary Simulation Consultant, where my research interests shifted toward the intersection of artificial intelligence, traditional networks, and their security implications. There, I assessed frontier AI systems, explored agentic architectures, and developed a deeper understanding of the technical foundations underlying modern AI systems.

Today, my research focuses on how intelligent systems fail. I am particularly interested in runtime influence, behavioral integrity, and what happens when context begins shaping execution. As autonomous AI systems become increasingly integrated into critical workflows, I hope to contribute meaningful insights and practical frameworks that help organizations safely adopt and secure these emerging technologies.

Pete

I have spent my whole career finding the ways systems fail. I started in QA engineering at Activision, testing AAA titles like Call of Duty, Tony Hawk’s Pro Skater, and Spider-Man, where the entire job was breaking software before players ever could. From there I joined the Marine Corps, serving as a 2651 in the Signals Intelligence field, and then moved into red teaming with the Marine Corps Red Team. After the Corps I moved to the private sector as a Security Advocate at SpecterOps, where I helped people achieve positive security outcomes through the smart application of security concepts and program development.

During my time on the Marine Corps Red Team, and into the work that followed, I was able to contribute to one of the longest running APT simulations in the history of the organization, inside the Marine Corps and out. I am no longer in that role, but the work and knowledge gained informed every aspect of I advise clients, both in the offensive and defensive space, and shaped how I think about this material, and it shows up in how I write about it here.

On this site, I share my insights and opinions that I have over a long career of helping orgs navigate their security challenges. Some of it is stories from inside the work, on the Marine Corps Red Team and across private sector engagements. Some of it is opinions on the patterns I have watched play out in government and industry alike. All of it is an attempt to share the operator-side knowledge that does not get passed along often enough. Helping others is my passion and I dedicate myself to the growth and success of others.

Rebecca

I started my career in the Marine Corps as a Tactical Network Administrator, where I spent five years building, maintaining, and securing small some of our Nation’s most critical information networks. After the Corps, I joined Northrop Grumman conducting incident response for the Marine Corps Enterprise Network, which let me keep supporting the mission from the defensive side. From there I moved into red teaming with the Marine Corps Red Team and later transitioned to the private sector as an Adversary Simulation Consultant at SpecterOps.

Across these roles, I also taught courses for Red Team Operations professionals and Intrusion Detection specialists. The work that went into those courses shaped how I think about this material, and it shows up in how I write about it here. On this site, I write from a path that ran through every side of the network: building it, defending it, attacking it, and then fortifying its defenses. Some of it is stories from incident response and red team operations. Some of it is what defending a network first taught me about breaking one. All of it is an attempt to share the operator-side knowledge that does not get passed along often enough.

Should You Listen to Us?

That part is up to you.

The credentials are the credentials. Between the four of us, we have spent careers on the defensive and offensive sides of the security field, in government and in the private sector, across operations and training and consulting and research. We have defended enterprises, run red teams, sat in outbriefs with senior leaders, written the reports that ended up in folders, written the reports that changed how organizations work, watched programs succeed, and watched programs fail. We have seen the same patterns play out across very different environments. We have the scars and the receipts.

None of that tells you we are right about any specific thing.

What the credentials actually qualify us to do is share what we have seen and what we think it means, in honest form, without dressing it up as truth that is not up for debate. The writing on this site is opinion and experience. It is what we believe, based on what we have lived. We are wrong about some of it. We will figure out which parts later, like everyone else does.

You should read the writing because the writing is useful, or skip it because it is not. Either is fine. The four of us write because we have things to say that we think other people in this work might benefit from hearing. The benefit is the point. The credentials are how we got the perspectives we are sharing. They are not why you should agree with us. Decide for yourself.

What This Site Is Not

It is not a how-to guide for running operations. The technical conversation in this field is robust, well-documented, and easy to find. This is not where you should come for tooling tutorials, exploitation walkthroughs, or step-by-step procedures.

It is not a critique of any specific institution. We are hard on the institutions we have served in and the organizations we have worked with, where being hard is honest. We are also fair. The point is the patterns, not the names.

It is not a polished corporate publication. We write in our own voices, including the parts that are warmer than a formal report and the parts that are sharper. If something here reads like a person wrote it, that is by design. Some of the most valuable security insights and conversations happen in the moment, and we are capturing those moments here.

Contact

If you want to reach us about the writing, the site, or the work, the best path is through the contact form. We read what comes in. We do not always respond quickly, but we respond when we can.

If you work in security in any capacity, or are responsible for the people who do, you are exactly the audience this site is built for. Read around, find the pieces that resonate, and come back when the next one drops. The work continues.