What DoD Red Teaming Actually Is

Before I get into the Marine Corps Red Team specifically, it is worth saying what a DoD red team is, because the term is used loosely outside the building.

A DoD cyber red team is a unit accredited and certified to conduct offensive cybersecurity operations against friendly Department of Defense networks for the purpose of assessment and training. The accreditation is not optional. To stand up a red team, you go through a certification and accreditation process run by the National Security Agency with oversight from US Cyber Command. The process is rigorous looking at the paperwork and documentation, the infrastructure and its security, and how everything is run. Verification that you not only have a written policy for how you operate but that you actually follow your own written policy.

I have been through the C&A as the team chief, and it is not pleasant. I have also, since leaving the Marine Corps and while I worked at SpecterOps, done maturity assessments for red team programs in the private sector. The difference between the two is instructive, and I think worth spending a minute on, because I do not think the distinction is widely understood.

I hear it has been updated some but at least at the time the C&A was, in essence, a large compliance inspection and I have opinions on compliance. It was asking whether the team has the right paperwork, the right policies, the right documentation of its environment, and whether it can demonstrate that it operates within the rules it has written for itself. Those are real questions, and they matter, and a team that fails C&A should not be allowed to operate. But passing C&A does not tell you whether the team is actually any good at the work. It tells you that the team is allowed to do the work.

A real maturity assessment is asking a different question entirely. It is asking whether the team is skilled, prepared, repeatable, and continuously improving. It is looking at how the team plans and executes operations. How they handle the moments that did not go to plan and capture those lessons learned. How they develop new capabilities when the threat landscape moves. Whether the team’s work is reproducible by other members of the team or whether it lives in the head of one person. The skill of the individual operators is part of the picture, but it is not the whole picture, and that distinction is important. Talent is not the same as maturity. A talented team that cannot operate without its star is a brittle team. A mature team with average operators can outperform a talented team without process.

The C&A produces a team that is allowed to operate. The maturity assessment produces a team that operates well. Both have value but they are not interchangeable.

How Other Teams Looked

The other thing worth saying up front is that not all DoD red teams are the same. They differ in size, resources, manpower, support structures, and, most importantly, leadership buy-in.

Some teams in the DoD inventory at the time were big enough to have multiple distinct functions inside them. An operations cell. An engineering cell. A separate infrastructure team. Their own internal SOC watching their own operational network. A reporting team. A research and development arm. The kind of structure where the operators showed up to do the operations and the supporting functions were handled by people whose full-time job was to handle those supporting functions.

Some of those teams had real funding behind them. Hardware refresh cycles. Licensing budgets. Travel that did not require begging. Training pipelines that produced new operators rather than burning through the ones already on the team.

Some of them had leadership that understood what they did and provided the cover needed to do it well.

That was not us.

The Marine Corps Red Team

The Marine Corps Red Team, at full strength, was fourteen people. Most of the time we were not at full strength. We were, by a wide margin, the smallest accredited team in the DoD inventory at the time.

There was no separate infrastructure team. The engineering cell handled infrastructure, and the engineering cell was, in practice, a handful of people. There was no internal SOC. We watched our own operational environment because nobody else was going to do it. There was no dedicated research and development arm. R&D happened in the margins of whatever else we were doing, usually at night and usually because something broke during an operation and we needed to fix it before the next operation.

There was no funding to speak of. I want to be clear about this, because I think people from outside DoD often assume that working for the government means you have resources behind you. That is true in some pockets. It was not true for us. To say we did not have funding is an understatement. The hardware we were running our backend on was hardware the Army had decommissioned because it had aged out of their refresh cycle. We had picked it up, racked it, and put it to work. One service’s surplus was our entire operational environment.

The SIEM we used was free and open source. I spent a chunk of my first year as engineering cell lead upgrading that SIEM in place on the Army’s old hardware, because we needed the capability and we did not have the budget to license a commercial alternative. The infrastructure worked. We passed the next C&A inspection cleanly. There was real pride in that, and I am not going to pretend there was not.

I will also say, looking back, that I would have traded some of that pride for more nights at home with my wife and kids. The cost of running a red team on free software and hand-me-down hardware was that the engineering cell, including me, spent a lot of evenings and weekends keeping it running. The team produced. The team passed inspections. The team executed real operations on real networks. We did it because we were stubborn enough not to fail, and because nobody else was going to do it for us. But the math of where those hours came from is something I think about. They came from somewhere. They came from home.

Leadership

The other piece of the picture, and probably the most consequential, was where we sat in the org chart.

The Marine Corps Red Team fell under the Defensive Cyber Operations section. The defenders. The same people whose job it was to keep the network secure and who, organizationally, owned the responsibility for the security posture of the network we were attacking.

Think about what that arrangement does to the incentive structure for a minute.

Every finding the red team produced was, by the org chart, a finding against the boss of the team that produced it. We were sitting under the people whose performance our work reflected on. When we got into something we should not have gotten into, the natural read inside the building was that the red team had embarrassed the defenders. The natural read should have been that the red team had identified a problem with administration and operations, which is what we had actually done. The vulnerabilities were not the defenders’ fault. They were the responsibility of the people configuring and operating the systems, who sat in different sections entirely. The defenders were the ones who would have to respond if an adversary exploited the vulnerabilities, but they were not, in most cases, the ones who had created the vulnerabilities.

The analogy I have used for this, more than once, is borrowed from the fire service. If a house catches fire, the people who show up to put it out are the firefighters. You do not blame the firefighters for the fire. The firefighters did not cause it. The firefighters are the people who showed up to fix the problem that already existed. You blame the conditions in the house, and the person responsible for those conditions, and you give the firefighters credit for putting the fire out.

In that analogy, the blue team and the Cyber Incident Response Team are the firefighters. They are the people who show up when something is on fire and stop it from spreading. Red teams are not the firefighters. Red teams are the fire inspector. We are the people who walk through the house before there is a fire, look at the wiring, the storage of flammables, the placement of the smoke detectors, and the state of the exits, and tell the homeowner where the next fire is going to start if nothing changes. We are upstream of the fire. The firefighters are downstream of it. Both jobs are essential, they are not the same job, and neither of them are responsibly for starting the fire.

The org chart at the Marine Corps Red Team put the fire inspector under the fire chief. The reporting structure made it so that every finding the inspector produced reflected back, by the lines on the chart, on the people responsible for putting out fires. That is the wrong placement for both functions. The blue team’s performance should be measured by how well they respond to fires. The red team’s findings should be read as data about the people responsible for the wiring, which is to say administrators, operators, system owners, and the leadership that resources them. The fire inspector and the fire chief should sit at the same level, both reporting to the person responsible for the safety of the house, not stacked on top of each other where the inspection report looks like a complaint about the fire response.

This is a structural problem. It is not a personality problem. The defenders we worked with were good at what they did, and the friendships I built with them, including with the CIRT chief, were real and remain real. We went to bat for each other repeatedly. We both knew what the work actually was, and we both knew what the org chart was doing to how the work was perceived. The friendships made the situation workable. They did not fix it. The org chart was doing damage that no individual relationship could fully repair. The findings should have been routed somewhere that read them as upstream data about the state of the house. Instead they were routed to the people who would have to run into the burning building, and the reading was predictable.

What the Cell Did

In spite of all of that, the cell worked. I want to spend a small section on what we actually got done, because the conditions I just described could make it sound like nothing got produced, and that is not the case.

We got the phishing program up to a much better standard than where it had been. I will not get into the specifics of how, but the short version is that we modernized the tooling, automated a lot of what had been manual, and increased the volume of campaigns we could run by a significant margin without sacrificing the quality of the individual campaigns. We optimized the team’s own network, which had been more manual than it should have been. We worked on infrastructure consolidation, including the centralized logging capability I have mentioned in other posts. We did all of this while traveling and going on operations, which is the part nobody talks about when they describe a red team’s R&D efforts. The internal work happens in the margins of the external work. It does not stop when the operations start. The operations are the reason the internal work matters.

There was a stretch in there where I was the engineering cell lead, a normal team lead on operations when we were executing, and the operations chief for the broader DCO section at the same time. Three jobs. None of them part-time. The days were long, and the work got done.

The Throughline

The throughline of this post, and probably of the next several, is that small teams with limited resources and difficult organizational placement can still produce good work, but the cost of that work falls on the people doing it. It falls in hours. It falls in personal money spent on infrastructure the institution should have paid for. It falls in time at home, time with family, sleep, and energy for the things outside the building that should matter more than the things inside it.

The Marine Corps Red Team produced. We were proud of what we produced. I am still proud of it. I am also clear-eyed about what it cost, and I think anyone considering a similar role should be clear-eyed about it too.

Vol 3 is about the people who made the cost bearable. The friends in the foxhole. That is the part of this story I am actually looking forward to writing.

This was a stretch of my career working inside the Department of Defense, and the descriptions in this post have been generalized to keep the focus on the experience and the lessons rather than the tradecraft. No personnel beyond those who already publish under their own names are identifiable. No units, dates, locations, techniques, or outcomes are presented in a way that would identify specific systems or people. Where details have been generalized, they have been generalized on purpose.

I am going to split this across several posts because the material is too dense to do justice in one. Vol 1 is the on-ramp. How I got to MCCOG, what I was doing there before the red team, and how I ended up walking onto the team.

We will be keeping a tight OPSEC posture throughout the volumes and content to come. No dates, no specific techniques, no names beyond people who already publish under their own names. Where details have been generalized, they have been generalized on purpose.

MCCOG

Before the MCCOG, I spent the first stretch of my Marine Corps career in the communications and electronics field, doing telecommunications and maintenance work. I moved into cybersecurity later in that stretch, when the Marine Corps was still figuring out how to build the workforce for it and the pipeline was less formalized than it is now. I spent the three years before the MCCOG in Okinawa, running a group-level cybersecurity program in the Pacific. I left Okinawa in 2018 and picked up at the Marine Corps Cyberspace Operations Group as a cyber threat analyst.

MCCOG is the operational hub for Marine Corps cyber. The defenders sit there. The red team sits there. The threat analysis function sits there. The leadership for most of the Marine Corps’s day-to-day cyber operations sits there. Walking in for the first time as a Staff Sergeant who had spent the last three years running a group-level cybersecurity program in the Pacific was a different kind of culture shock than I was expecting. It was a difference scale and tempo, with different kinds of conversations happening in every room.

My job for the first stretch was on the threat analysis side. I spent that year looking at Marine Corps networks through the lens of the MITRE ATT&CK framework, mapping what we knew about adversary tactics and techniques against what our networks were actually configured to detect and prevent. The work was equal parts intelligence analysis and defensive engineering, and it was the first time in my career I was being asked to think about the network from the adversary’s perspective rather than from the administrator’s. That shift in framing is the thing that pulled me toward offensive work later. Once you start asking what an adversary would do here, it is hard to go back to asking only what the policy says you should do.

The Schools and the Certs

In parallel with the day job, I was in school more or less continuously.

The Marine Corps had a relatively new cyber pipeline at the time, and I was working my way through it. The career-level school for cyber Marines and the technical courses that came after it, along with he cross-training that the command pushed people through when they had operational gaps to fill. I was also working toward a Project Management Professional certification, because the work I was doing was as much program management as it was technical, and the PMP was a useful credential to have on the paperwork side.

I was also working toward a bachelor’s degree in cybersecurity policy and management. The degree had been on my list for a while, and the years at MCCOG were when I actually committed to finishing it. I took classes on the same general cadence I worked through the certifications, which is to say in whatever windows the job and the rest of life left available. The degree program lived somewhere between academic and applied, which suited the kind of work I was doing. The policy half kept me honest about how the institution was supposed to operate. The management half gave me the vocabulary to talk about it.

The thing that made all of the certificates possible was the Marine Corps COOL program. Credentialing Opportunities On-Line. The short version is that COOL paid for certifications relevant to your military occupational specialty, and if you were willing to put in the study time, you could stack credentials at the institution’s expense. I took full advantage of it. I worked through a series of CompTIA certs. I studied for them on my own time, scheduled the exam when I felt ready, and rolled the next one in behind it. The pattern that worked for me was simple. Study until I was confident enough to take the test and then move to the next one.

Some people in the building viewed COOL as something to be tolerated. I viewed it as the institution offering me free credentials and free training, and I did not understand why anyone would say no to that. The credentials were not the point in themselves. The studying that produced the credentials was the point. Every cert I prepared for taught me something I had not known before, and the body of knowledge accumulated. By the time I rotated toward the red team, I was carrying a stack of certifications that opened doors and, more importantly, a working knowledge of the material those certifications represented.

I am going to take a small detour here to say something that I think a lot of people in this field get wrong. The certification is not the value. The studying is the value. If you cram for an exam, pass it, and forget the material, you have a piece of paper and nothing else. If you take the studying seriously, the paper is the byproduct of work that actually changed what you know. The COOL program let me do the work for free. That is the part that mattered.

The Engineering Cell Lead

The other thing that happened during that stretch at MCCOG was that I reconnected with an old friend. Robert Woodcock. One of the best men you will ever meet.

He and I went back. We had met years earlier in an airport and instantly became great friends. We were both heading to the Marine Corps cybersecurity school and decided to live together as roommates during the schooling, before I left for Okinawa and he went on to MCCOG. By the time I arrived several years later, he had been on the red team for a while and had grown into the engineering cell lead. The reunion was the kind that does not require any catching up. You pick up where you left off and you keep going.

He was the second-ranking Marine on the team. The engineering cell handled the things that did not get into the trade-press writeups but determined whether the team could actually execute. The backbone of what the team did rested on the cell he was running.

We were close, which meant I gave him no peace about his job. I told him, more than once and with varying degrees of seriousness, that I was going to take it from him. He took the joke well, mostly because I think he assumed it was a joke. I am not sure I was entirely joking.

The thing about being in the same building as a red team you are interested in is that the team sees your work. The chief of the red team was leaving. The federal civilian who ran the broader team had heard my name enough through the normal flow of cross-team work that he had formed an opinion about me. He kept telling the leadership of the Defensive Cyber Operations section that we all fell under that he wanted me. I did not know any of this at the time. I learned it later. What I knew at the time was that I got told there was an opportunity to come over to the team if I could prove I belonged there.

The Course

The way you proved you belonged was the Marine Corps Red Team Operations Course.

The course was the team’s internal pipeline. The team ran it. The team graded it. The team decided whether you were going to be allowed to walk through the door at the end of it. Two weeks, front to back. A mix of academics and practical work, with the practical portion designed to put you under realistic operational load and see how you held up. Long days, hard problems, no shortage of opportunities to make mistakes, and people watching to see how you responded to making them.

The curriculum walked through the phases of a red team operation in the order they actually happen. Open-source intelligence work first, because reconnaissance is where every operation starts and where a surprising amount of the final report ends up being sourced from. Phishing came next, because getting an initial foothold is the operation’s first real inflection point, and doing it well takes more craft than people who have not tried it tend to appreciate. Then command and control, moving from foothold to persistence to lateral movement, the mechanics of actually operating inside a network without getting caught. Then the network takeover work itself, the escalation, the domain compromise, the objectives that make the operation matter. Then reporting, which is a discipline of its own and should be taken as seriously as any of the technical phases, because a report that does not communicate the finding does not fix anything and the whole operation was for nothing.

Each of those phases had a classroom component and a lab component. You would spend part of a day learning the material and part of the day doing it against a target environment set up for the course. The instructors would rotate through, watching, occasionally intervening when the situation warranted, mostly letting you figure things out, take notes on the times you did not, and remind you when you hit a wall in the network you think might be a defect that “that is the intended result.”

The last two days of the course were the exam. Day one was an eight-hour window in which you had to run a full engagement against the lab network, from outside in. You started from nothing. No credentials, no foothold, no map. You did your own reconnaissance, you built your own phishing pretext, you got your own initial access, and you worked your way through to domain compromise on the clock. Eight hours is not a long time to do that end to end. The instructors set it up that way deliberately. Real operations take weeks or months. The exam compresses the arc into a day because you cannot run a two-week test as a two-week exam, but you can learn a lot about somebody by watching them do the whole thing under time pressure with nobody helping.

Day two was the report. You had the day to write it. What you had done, how you had done it, what you had found, what the organization should do about it. If day one told the instructors how you operated, day two told them how you communicated. Both mattered. A red teamer who cannot write is a red teamer whose work does not land.

I will not get into more of the curriculum than that. The short version of how it went for me is that I did well. I was carrying the work I had done on the threat analysis side, the program management instincts from running the unit-level cybersecurity program in Okinawa, the technical knowledge from the COOL grind, and the operational mindset I had been building in the months leading up to the course. The course was hard. I was prepared for hard.

By the end of it, the team made the offer. I accepted

The Seat

My friend rotated up to red team chief as the previous chief left. I took the seat he had just vacated and became the engineering cell lead. The transition happened cleanly, and the building barely flinched.

What I walked into was a job with more surface area than I had appreciated from the outside. I was responsible for the team’s infrastructure, the tooling we used to execute operations, the phishing program for the entire Marine Corps, and the internal capability development that made everything else possible. A lot of what the team did externally rested on whether my cell was producing internally, and a lot of what my cell was supposed to be producing was, when I got there, behind where it needed to be. Some of the tooling was out of date. Some of the infrastructure had drifted. The phishing program needed work. This was not due to Woody in the seat before me because, as I knew as, there was always a list of things that needed done, and the list was long.

That list, and what it took to actually work through it, is where Vol 2 picks up.

This was a stretch of my career working inside the Department of Defense, and the descriptions in this post have been generalized to keep the focus on the experience and the lessons rather than the tradecraft. No personnel beyond those who already publish under their own names are identifiable. No units, dates, locations, techniques, or outcomes are presented in a way that would identify specific systems or people. Where details have been generalized, they have been generalized on purpose.

If you have read any of my other posts, you probably already know that I am particular about words. I will write a whole post about how can’t and shouldn’t are not the same word. Words have meanings. Some of them are not interchangeable, even when people use them as if they are, and the conflation does real damage to the conversations the words are supposed to support.

Subscribe now

A lot of this comes from the Marines. The military, by necessity, builds vocabulary around very small distinctions. Attack, destroy, disrupt, neutralize are not synonyms. They describe different effects, with different criteria for success, executed against different kinds of targets. A commander who tells a unit to neutralize a target is not telling them to destroy it, and a unit that destroys a target when they were told to neutralize it has not accomplished the mission. They have done something else.

I will give one example from my own career, because it matters to me and I think it illustrates the point. I never attacked Marine Corps networks during my time on the red team. Attack is an offensive word. It implies hostile intent toward the target. I was not hostile to the networks I was working on. I was defensive. I was Marine. The networks were Marine networks. My job was to find their weaknesses so they could be made stronger. The right words for what I was doing were assess, aggress, and test. Each of those carries a different shading than attack, and the shadings matter. Using attack would have misrepresented both my intent and my relationship to the target. I cared about the precision because the precision was part of the work.

This post is about another pair of words that get used interchangeably in a way I find frustrating. The pair is grade and quality. I am a Project Management Professional. The PMP coursework makes a clean distinction between the two, and the distinction has stayed with me ever since I picked up the certification. People use the two words as synonyms in everyday conversation, which is fine in everyday conversation. In a professional context, the conflation costs real money and produces real disappointment. The two words mean different things, and the difference matters more in the age of AI-assisted building than it has in any previous era of software development.

I am going to spend this post explaining the difference. By the end of it, I want you to know the difference too.

The Definitions

In the project management framework, grade and quality refer to two different properties of a deliverable.

Grade is the standard the product is built against. The specification. The tier of capability the product is being targeted at. A high-grade product has been designed to do more, last longer, handle more demanding conditions, or operate at a higher level of capability than a low-grade product. Grade is a choice you make at the start of the project, when you decide what the product is supposed to be.

Quality is how closely the finished product matches the standard it was built against. A high-quality product meets its specification. A low-quality product does not. Quality is a measure of execution against the chosen grade.

These are independent. A product can be high-grade and low-quality. It can be low-grade and high-quality. It can be either combination of the two, in any direction.

The Phone Example

The cleanest illustration I have found for this distinction is two phones.

The first phone is designed with a 24-hour battery specification. The team building it intends for it to last a full day on a single charge under typical use. When the phone ships, the battery lasts 18 hours. It does not meet its specification. The phone is high-grade, because the target was ambitious, but it is low-quality, because the execution fell short of the target. The buyer who picked this phone for its battery life is going to be disappointed every day.

The second phone is designed with a 12-hour battery specification. The team building it intends for it to last half a day, and that is what they tell customers to expect. When the phone ships, the battery lasts 12 hours. It meets its specification exactly. This phone is low-grade, because the target was modest, but it is high-quality, because the execution matched the target. The buyer who picked this phone got exactly what they were promised.

Which phone is better? It depends on what the buyer needed. If the buyer needed all-day battery, the first phone is closer to that goal, even though it fell short. If the buyer needed reliable, predictable battery life and was willing to charge at lunch, the second phone is the better product.

The point of the example is not that one phone is universally better than the other. The point is that grade and quality are different axes, and you need both words to describe a product accurately. Saying “this phone is bad quality” when you actually mean “this phone is a lower grade than I wanted” is a common conflation, and it produces conversations that go nowhere because the two sides are arguing about different properties.

Why This Matters in the AI Era

The reason this distinction has become more important in the last few years, rather than less, is that AI tools have changed who can build software.

A few years ago, building software required programming knowledge. Not necessarily expert knowledge, but enough to write code, understand what the code did, and debug what went wrong. That barrier filtered out a lot of people who had product ideas but lacked the technical skill to execute them. Now the barrier is much lower. A marketer with a clear vision for a tool can describe what they want to an AI assistant and get working software in an afternoon. A subject matter expert who has been complaining for years that no one builds the tool they need can finally build it themselves.

That shift is, on balance, a good thing. More people building means more problems getting solved. The democratization of software construction is something I am genuinely in favor of, and I am not going to write a post that argues against it.

What I will write is a post that argues people are conflating grade and quality in this new landscape, and the conflation is causing real damage.

The marketer who builds a program with AI assistance can produce something that is, in a meaningful sense, high quality. The program does what they asked it to do. It matches the specification they had in their head. From the marketer’s perspective, it is working software, and the AI delivered exactly what was requested.

But the grade of the program is set by the marketer, and the marketer does not know what a high-grade version of the program looks like. They do not know what security considerations the program should have. They do not know what edge cases the program should handle. They do not know what the failure modes are, what the operational requirements are, or what the maintainability profile looks like a year down the line. The marketer set the grade based on what they understood the program needed to do, which is the only grade they were equipped to set.

When a developer with real experience builds the same program, the grade is different. The developer knows what a robust version of the program looks like because they have seen what happens when programs are not robust. They know what attacks to defend against because they have seen those attacks succeed. They know what conditions the program will eventually have to handle because they have watched programs break under those conditions. The grade they set is higher, because the standard they hold the work against is shaped by experience the marketer does not have.

Both the marketer and the developer can produce high-quality work. The difference is the ceiling each of them can reach, and the ceiling is set by the grade.

Domain Vocabulary Is the Grade-Setter

Pete and I have been talking about this kind of thing a lot, and one of his posts says something I want to extend into the frame of this one.

In [The Framework Learns], Pete introduced a concept he calls Vocabulary-First Onboarding. The observation that produced it is one of the most useful things I have read on AI-assisted work this year. His version of the insight is this. The speed at which a person can work productively with an AI in a given domain is bounded by the vocabulary they have in that domain. Not the conceptual depth. The vocabulary. The names of things.

Pete’s example is the difference between his security work and his CSS work. In security, he has decades of vocabulary. He knows what OWASP A02 means without thinking about it. He can describe what he wants to a model in the language the model was trained on, and the model meets him with the precision he needs. In CSS, he had to learn vocabulary in real time, and the work slowed to a crawl while he figured out what to call the things he was trying to do. Same person. Same AI. Different speed. The variable was the vocabulary.

I want to extend Pete’s observation into the grade-versus-quality frame, because I think the two ideas reinforce each other.

The grade of an AI-assisted output is set by the vocabulary the person brings to the conversation. When the marketer prompts an AI to build a program, the vocabulary they bring is marketing vocabulary. Conversion. Engagement. User journey. The AI builds an output that maps to that vocabulary. Anything outside of that vocabulary, like input validation, rate limiting, session management, or error handling, has to be supplied by the AI’s defaults, because the marketer does not have the words to ask for it. The grade is set by the words the marketer knows.

When a developer prompts the same AI to build the same program, the vocabulary they bring is developer vocabulary. They ask about authentication flows, parameter sanitization, idempotency, retry behavior, observability. The AI builds an output that maps to that vocabulary. The grade is set by the words the developer knows.

The AI is responsive to vocabulary because vocabulary is, as Pete writes, the API between human expertise and AI capability. The expertise lives in the words. The words tell the AI which standards to apply, which patterns to invoke, which considerations to surface. If the words are not in the prompt, the considerations do not get surfaced, because the AI has no other signal that they should be. The vocabulary the user brings is the grade the AI builds against.

This is why the conflation of grade and quality is so dangerous in AI-assisted work. The non-expert producing a program with AI is operating against a low-grade specification, set implicitly by the limited vocabulary they brought to the prompt. The AI builds high-quality output against that low-grade specification. The non-expert evaluates the output against the same limited vocabulary, and the evaluation confirms the work is done. The grade was too low the whole time, but nothing in the loop ever flagged it, because the grade-setting function lives in vocabulary the non-expert does not have.

The Two Failure Modes

There are two failure modes I see most often when grade and quality get conflated in AI-assisted work.

The first failure mode is the marketer’s program shipped without anyone catching the missing grade. The marketer is happy because they got what they asked for. The organization is happy because the program is in production and is producing value. Six months later, an issue surfaces. A data leak. A logic flaw. A security vulnerability that lets someone do something the marketer did not anticipate because the marketer did not know to anticipate it. The program is high-quality against the marketer’s specification and low-grade against the specification any experienced developer would have written. The discovery of that gap is usually the moment when the costs of the conflation finally land.

The second failure mode is more subtle and more common. Organizations look at the speed and apparent productivity of AI-assisted development and conclude that they need fewer experienced developers. The math seems obvious. If a marketer can produce a working program in an afternoon, why should the company keep paying senior developers to spend a week on it? The answer, of course, is that the marketer is producing a low-grade program quickly, and the senior developer is producing a high-grade program over a longer time horizon, and the two outputs are not interchangeable. But that distinction is invisible at the surface level. The marketer’s program looks like working software. The senior developer’s program looks like working software. Only the failure modes reveal the difference, and the failure modes show up later, when the choice to reduce the experienced workforce has already been made.

I want to be careful here. I am not arguing that AI-assisted development is a problem. I am arguing that AI-assisted development without domain expertise is a problem, and the two are easily confused. The same AI tools that let a marketer ship a low-grade program in an afternoon let a senior developer ship a high-grade program in a fraction of the time it would have taken pre-AI. The tool is the same. The result is different. The variable is the expertise of the person using the tool.

What Good Looks Like

The right model for AI in software construction, in my view, is empowerment of experts rather than replacement of them.

A senior developer using AI to build a program produces better work than they could have produced unassisted. The AI handles the boilerplate, the routine, the parts of the work that do not require deep judgment. The developer focuses on the parts that do. The grade is set by the developer’s expertise. The quality is improved by the AI’s speed and the iteration cycles the speed enables. The combination produces high-grade, high-quality work, faster than either the developer or the AI could produce alone.

A non-expert using AI to build a program produces work that looks the same on the surface but is fundamentally different underneath. The AI handles the boilerplate, the routine, and also, by default, sets the grade based on patterns from its training data rather than on the requirements of the specific problem. The non-expert evaluates the output against their own understanding, which is necessarily limited by their lack of domain knowledge. The work ships. The work appears to be done. The failure modes that an expert would have anticipated are not addressed, because the expert is not in the loop.

The right organizational response to this difference is to keep experts in the loop, not to remove them. AI-assisted development should make experts more productive, not redundant. The expertise is the part that sets the grade. The AI is the part that improves the quality of execution against the grade. Take away the expert and you take away the grade-setting function, and you are left with high-quality execution against a specification that is too low for the problem you actually need to solve.

Faster, Not Replaced

If you know what you are doing, AI will make you faster. The same intuitions you developed over years of working in your domain still apply. The AI accelerates the execution, but the judgment about what to build, how to build it, and what to be careful about is still yours. You ship more work in less time, and the work meets the standard you have learned to hold things against.

If you do not know what you are doing, AI will produce something that looks like it could work. You will not be able to tell the difference between a program that is genuinely robust and a program that has the appearance of robustness but will fall over the first time it encounters a condition you did not anticipate. The output will pass your evaluation because your evaluation is operating against the same limited understanding that produced the prompt in the first place.

If you do not know what you are doing and you throw AI at it anyway, you are going to break things at speed. The acceleration applies in both directions. AI makes good engineers faster. It also makes inexperienced builders fail faster, more confidently, and at greater scale than they would have without the tools. The output is shipped before the problems are caught, because the speed of construction outpaces the speed of evaluation when the evaluator does not know what to look for.

The goal is not to gatekeep the work to credentialed experts. The goal is to recognize that grade-setting is itself a skill, that the skill is built through experience in the domain, and that AI tools do not provide that experience for free. They amplify whatever the user brings to them. If the user brings expertise, the amplification is positive. If the user brings only the desire to build something, the amplification is whatever happens when the AI’s defaults are accepted as the specification.

The Working Principle

The principle I want to leave you with is the one I keep coming back to in my own work.

When you are building something, ask yourself which axis you are optimizing. Are you trying to ship the highest-quality version of a low-grade specification, because that is what you can articulate? Or are you trying to ship a high-grade specification that meets the actual requirements of the problem you are solving?

If the answer is the first, find someone with the domain expertise to set the grade higher. Bring them into the loop early. Let their experience shape what the program needs to be, not just what you happen to want it to be. Then use the AI to build the high-grade version efficiently.

If the answer is the second, you are probably already in good shape. You know what you are building, you know what good looks like, and the AI is going to make you faster at producing it.

Grade is the standard you are building against. Quality is how well you hit the standard. The first is set by what you know. The second is improved by how you work. AI changes the second axis dramatically. It does not change the first.

Know what you are building. Then use the tools to build it well.

I have been doing tech and cyber for over fifteen years. Military, government, small companies, Fortune 100 enterprises. Different industries, different stacks, different threat models, different cultures. If you do this work long enough across enough environments, you start to notice patterns in what separates the organizations that are actually secure from the ones that just look like it on paper.

The clearest pattern I have noticed is this: the organizations that are actually secure understand that being compliant and being secure are not the same thing. The organizations that struggle do not.

I have spent a long time trying to get people to see that distinction. This post is another attempt.

Subscribe now

What Compliance Frameworks Actually Are

In the military and government, the relevant artifacts are Security Technical Implementation Guides, more commonly called STIGs. They are checklists. Configure this setting this way. Disable this service. Apply this patch. They are procedural by design, and they exist for good reasons. A standardized baseline means an inspector can walk into any unit anywhere in the world and grade them against the same yardstick. That has real value.

In the private sector, the landscape is broader. CIS Benchmarks are probably the closest direct analog to STIGs at the configuration level. On top of that, depending on the industry, organizations are working against NIST CSF, ISO 27001, SOC 2, PCI DSS, HIPAA, or some combination of all of the above. For my fellow CISSP holders out there, this is the alphabet soup the Common Body of Knowledge spent a lot of time helping us memorize. Different frameworks, similar spirit. Prescriptive baselines, governance scaffolding, audit-ready paperwork, all designed to give you a defensible starting position.

These frameworks are useful. I am not going to tell you they are not. They are also widely misunderstood by the people who are supposed to be using them.

The mistake is treating the framework as the destination instead of the starting point. STIGs and CIS Benchmarks are the headline of the article, not the article. They are the starting line, not the finish line. Adhering to them does not make you secure. Adhering to them makes you compliant, and it gives you the baseline level of security a reasonable organization should be expected to have. That is a floor. It is not a ceiling, and it should not be where the work stops.

The Fitness Analogy

The way I think about this is the same way I think about fitness standards in the Marine Corps.

There is a minimum. Every Marine has to meet it. The minimum exists because below a certain level of physical conditioning, you are a liability in a fight, and the institution has a responsibility to make sure people who pin on the uniform are at least at the baseline.

But nobody wants the person next to them in combat to be the Marine who just barely makes minimum standards. Everybody wants the Marine who dominates the test, the one for whom the fitness test is the easiest workout of their week. That Marine is the one you can count on when things go sideways. The Marine who barely passed is the one you are nervous about.

Security works the same way. The compliance framework is the minimum standard. You should meet it. Below the minimum you are a liability. But the organizations whose security I would actually trust in a fight are the ones for whom the compliance framework is the easiest part of their week. Compliance is the warm-up. The real work is everything they do on top of it.

Counting Reps

I lived this principle on the fitness side, and it earned me a particular reputation. People did not like pairing up with me for the test, because I held them to the standard.

On pull-ups, I climbed up on the bar and looked across to make sure the chin actually cleared. I did that for two reasons. The obvious one is that I wanted the count to be accurate. The less obvious one is that from the ground, the angle can make a legitimate rep look like it did not quite get there, and I did not want to miss reps somebody had actually earned. Both directions of error mattered to me.

Crunches were the same. If you did not get to the top of the rep, it did not count. If you did eighty out of a hundred, you got eighty. There was no buddy hookup version of the number.

I was never a great runner. I worked on it all the time, and the run was always my weakest event. You cannot fake a run time. The clock is the clock. So I made sure my other events were the strongest they could be, because the math of the test is unforgiving, and any points I lost on the run had to come back somewhere else. I trained around my weakness instead of negotiating around it.

Senior Marines came to me to count their reps, including people who outranked me. They came to me knowing that I would give them their honest number, not a polite one, and they trusted the result more because of it. I never told anyone they had done something they had not done. I also never failed to count something they had earned. That was the deal, and I think people respected the consistency, even the ones who did not love the experience in the moment.

For a stretch of my time in, I was a cybersecurity inspector for the Commanding General’s Readiness Inspection. The job put me on the road visiting units and grading their compliance with Marine Corps cybersecurity policy. I took the same posture I took at the fitness test. The standard was the standard, and I gave units the score they had actually earned, not the score they would have liked.

That did not always make me popular when I walked in. It is not designed to. An inspector who hands out perfect scores to keep the relationship pleasant is not doing the unit any favors. The findings are how the unit knows what to work on. If I papered over the gaps, the gaps were still there, and the next inspector or the next adversary would find them anyway. Better the unit hear it from me, in writing, with time to fix it.

What I noticed over time was that the units took the honest scoring seriously, and so did their commanders. Nobody enjoyed the visit in the moment. But after the dust settled, the commanders knew the report was a real picture of where they stood, and the unit knew that the work they did to close findings actually mattered. The next inspection cycle would tell the truth about whether they had moved. That is what makes an inspection useful. The honest version produces better units. The polite version produces better paperwork.

You want a better fitness score, work harder. You want a better rifle score, shoot better. The way to score higher is to be better, not to negotiate the count.

Security is the same. You want to be more secure, do more security work. Not better-looking compliance documentation. Not a tighter cover story. Actual security work. The standard exists for a reason. The way to get past the standard is to do the work.

The Private Sector Failure Mode

In the private sector, the failure mode is treating security as a checklist that exists to satisfy a legal or contractual obligation.

The incentives in the private sector point the right direction in theory. A breach has real consequences. Monetary damage. Reputational harm. Customer loss. People get fired. Reporting requirements get triggered. Lawyers get involved. Boards get nervous. None of those things are good for the company, and all of them create pressure that, in a well-run organization, gets translated into actual security investment.

In practice, what often happens instead is that the pressure gets translated into compliance investment. The company makes sure it can demonstrate that the appropriate boxes were checked at the appropriate times. The annual penetration test gets scheduled because the framework says so, not because anyone is trying to learn something from it. The security awareness training gets rolled out because the auditor will ask. The findings get tracked in a spreadsheet that satisfies the regulator and gets filed away after the audit.

No customer who has just had their data stolen is going to take comfort in a press release that says the company was fully compliant with all applicable regulations. That sentence does not produce the outcome anyone actually wants. But a lot of companies operate as if it does, because compliance is measurable and security is hard, and the more effort security takes, the less appetite there is to do it.

The companies that get this right are the ones who treat the compliance work as the bare minimum and use the budget and political capital it gives them to fund the work that actually matters. The companies that get it wrong are the ones who treat the compliance work as the whole job.

The Military and Government Failure Mode

The military and government failure mode looks different on the surface, but it has the same root cause.

The surface symptom is laziness wrapped in compliance language. The deeper problem is the absence of consequence and accountability when security fails. Those two things together produce a culture in which the path of least resistance is to check the box and move on, because no one is going to get held responsible if it turns out the box-checking was not enough.

Federal workers have a lot of protections, and those protections are there for legitimate reasons. They are also extremely effective at making it hard to fire someone, including in cases where firing someone would be the right call. If a federal employee causes a breach through negligence or worse, the realistic outcome in many cases is not termination. It is a reassignment, or a stern letter, or nothing at all. The signal that sends through the rest of the workforce is exactly the signal you would expect.

The military has its own version of this. The version I have seen most often is the practice of pushing blame as far down the chain as it will go. When something goes wrong, the people who get held responsible are usually not the planners or the leaders who set the conditions for failure. The senior people have careers. Senior careers are expensive to damage. The junior person who actually executed the failing task is a different equation. They are new. They have less to lose. Their career is, in a cold accounting sense, expendable. They get burned, they cannot reenlist, and the institution moves on. Meanwhile the people whose decisions actually produced the failure walk away clean.

That is not leadership. That is the opposite of leadership. Real leadership is the willingness to take the hit when your team’s failure traces back to your decisions, and to protect the people below you who were doing what you told them to do. I have seen that done well in the Marine Corps, and I have seen it done badly, and the units where it was done well were also, not coincidentally, the units that took security seriously.

The other piece of the military and government picture is the cover. When a private company has a breach, they have to report it. They have to tell the regulator. In many cases they have to tell their customers. The public consequence is part of the incentive structure.

When the government or military has a security failure, in a lot of cases the failure itself is classified, and the response is to put a wrapper around it and stop talking about it. Sometimes that wrapper is warranted. Sometimes it is genuinely the right call. But the broader effect is that the institution gets to avoid the public consequence private companies cannot avoid, and the internal pressure to actually fix the problem is weaker as a result. A Plan of Action and Milestones gets drafted. The POA&M gets briefed up. Everyone in the room knows it is unlikely to ever get implemented, because implementation is work, and the people responsible for making the work happen have other priorities. The document satisfies the process. The process moves on. The vulnerability remains.

I am not arguing for the public flogging of every government cyber incident. I am arguing that the absence of a real consequence loop has predictable downstream effects on culture, and culture is what determines whether the network is actually secure or only appears to be.

What Actually Makes a Network Secure

Vulnerability scans do not make a network secure. They make it scanned. STIGs do not make a network secure. They make it compliant.

The things that make a network secure are not on any framework’s checklist, but they are the same things every time.

People who take their jobs seriously. Not the job description. The job. The thing they are actually responsible for, regardless of what the position write-up says.

Leaders who have bought in, and who are willing to spend the resources, the political capital, and the personal time that real security requires. The presence or absence of that leadership buy-in is, in my experience, the single biggest predictor of whether an organization is secure or just compliant.

Every user practicing the cyber hygiene the organization expects of them, because the human surface is still the largest attack surface, and culture is the only thing that closes it.

Administrators and security professionals putting in the actual effort. Maintenance. Configuration drift. Patch hygiene. Identity management. Detection engineering. The unglamorous, sustained work that does not photograph well in a briefing slide but that is the actual product of a security program.

None of these things are easy. All of them are work. That is the part nobody wants to hear. Security is effort, sustained over time, applied across every layer of the organization, by people who care. There is no checklist that replaces it and there is no framework that simulates it.

Compliance is not security. It is the floor. Build the floor, but then keep building everything else.

On January 29, 2026, Ivanti shipped emergency fixes for two zero-days in Endpoint Manager Mobile, CVE-2026-1281 and CVE-2026-1340. Both rated 9.8. Both let an unauthenticated attacker run code on the server that manages an organization’s entire mobile fleet. The root cause is worth sitting with. The bugs lived in legacy bash scripts wired into Apache RewriteMap configurations, the kind of glue code that gets written once, works, and never gets looked at again. The vulnerable handlers had names like map-appstore-url and map-aft-store-url. Helper scripts nobody had thought about in years.

By the time the patch landed, attackers were already inside. Exploitation had started before disclosure, and within days the fallout reached close to a hundred organizations, including the Dutch Data Protection Authority and the Netherlands’ Council for the Judiciary. This was not Ivanti’s first EPMM emergency, or its fifth. CISA has logged 34 exploited Ivanti vulnerabilities since 2021, five of them in EPMM in the last year alone.

Then came the line that should stop you. In its own May 2026 advisory, Ivanti said the quiet part out loud.

Advanced AI models have collapsed the time to exploit from days to hours after disclosure.

Ivanti EPMM security advisory, May 2026

Notice what Ivanti is pointing at. The bugs are the same deferred, legacy, nobody-owns-it code they have always been. What moved is how fast someone can turn one into a breach.

Hold that, because it is the entire argument.

Read more

If you've been following my writing for any stretch of time, you know that I've spent a fair amount of “digital ink” arguing that context is the real axis around which LLM security risks rotate. Whether we're talking about the gradual reframing mechanics of context drift or the implicit authorization surface that emerges when a model flattens a dozen un…

Read more

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.