If you missed Part 1, the short version is that this was MWX, the Marine Air Ground Task Force Warfighting Exercise. I was leading the Marine Corps Red Team cyber cell for the op, and we had another DoD red team riding along with us. The planning phase had gone the way planning phases tend to go when leadership above you does not have a working knowledge of cyber. We had pushed back where we could, agreed to a plan we could live with, and started the work.

This part is about how we actually got in.

The Hotel

Most of the early execution did not happen on base. It happened in a hotel.

We had a room set up with the basics. A few power strips chained together, a handful of laptops spread across every flat surface, personal gear shoved into a corner, and a coffee maker that ran more or less continuously. This was the workshop for the first stretch of the op, and we lived in it for days.

Four of us worked in that room most nights. A lot of it was quiet. Everyone on their own laptop, heads down, trying to make something work. Then someone would find something or hit a wall, and two or three of us would crowd around one screen trying to figure out what we were looking at. We had no whiteboard, so we drew things out on whatever paper was lying around or just talked through it out loud. We were trying to build payloads, draft phishing emails, stand up new command and control infrastructure, and figure out how all of it fit together, all at the same time. The internet situation was hotel wifi tunneled through a VPN back to the infrastructure we needed, and the speeds were exactly what you would expect from that arrangement. Slow on a good night. Unusable on a bad one.

There were breaks. We would stop working and just talk about nothing for a while. One of the guys heated up a can of beans on a small hot plate and called it dinner. Nobody had thought through the food situation, which is how we ended up at Del Taco at two in the morning because it was the only thing still open. We bought enough cheap chicken tacos to have an eating contest, because when you have been staring at a screen for ten hours and your payload still is not working, the logical next step is apparently competitive taco consumption. Those breaks kept us sane. The work was grinding, and you cannot grind all night without coming up for air.

The drive from the hotel back to base was long enough that, when we ran late, it was not worth making the trip. We slept where we worked. On a couple of nights I slept on the floor near the AC, with a curtain pulled off the rod and used as a blanket, because one of my Marines needed a better spot and the spot next to the bed was warmer. Pete was the one who, more than once, looked up from his laptop and said we needed to stop and go get real food.

I would wrap up around 0400 and get a few hours of sleep. I would wake up with just enough time to make myself look presentable and make the hour drive back to base for the morning meeting at 0800. My guys got to sleep in a bit longer while I took care of that piece. They had earned the sack time. The briefing was on me, and on the days I could shoulder it alone, I did. That cycle ran for the first several days of the op.

Remote Browser Isolation

The technical problem at the front of the op was the new web proxy.

I mentioned in Part 1 that the Marine Corps had stood up a remote browser isolation capability in front of their web traffic, and that it was breaking the techniques we had planned to use. The short, generalized version of the problem is that RBI changes the trust model for a phishing payload. Things you used to be able to do on a target’s browser, you can no longer do, because the browser is not actually running on the target. The payload has to take a different shape to survive the trip, and the delivery has to account for what the proxy is willing to pass through to the user.

A lot of those late nights in the hotel were spent on this problem specifically. We would build something, test it against the proxy, watch it fail, figure out why, and start over. The first several attempts did not get close. The next few got closer but still broke in ways we did not expect. We were doing all of this over hotel wifi through a VPN that dropped whenever it felt like it, which added its own layer of frustration to every test cycle. Eventually we had something that worked, and we kept that capability in the toolbox afterward.

Lance and I wrote up one bypass approach as a public blog post after the op was done. If you want the technical details, you can read it here: Calling Home, Get Your Callbacks Through RBI. OPSEC Disclaimer: The blog is “a” method to get past some types of browser isolation. It was not the method we used here and would not have worked here.

The Other Team

There was another DoD red team with us for this op, and the contrast between how the two teams approached the work was, in retrospect, instructive.

I am not going to name them or describe them in any way that would identify them. What I will say is that, from the conversations I had with their members over the course of the op, the way they typically operated was different from how we operated. Most of their engagements involved being handed credentials and being given access to a network, and then running the operation from that starting point. That is a legitimate way to do a particular kind of offensive security work, and there is value in it. It is also a fundamentally different muscle than what we were doing on MWX, which was treating the target the way an external adversary would treat it. You fight for every inch. You assume nothing.

They sent a close access element first. Good at what close access teams do, but the people they put in the hotel with us had almost no computer experience. Most of their time during the day was spent sitting on the end of a bed watching us work. We did not have payloads ready for them to go do close access work with, and close access was all they knew, so there was not much for them to do. They would go out occasionally to try things, but without the tools ready on our end, there was nothing to plug in on their end.

When they rotated in their more technical people, it got a little better and a little worse at the same time. The second crew had some familiarity with Cobalt Strike, which we did not have available for this op. They did not have admin rights on their own laptops, so they could not install their own tooling. They had not brought the infrastructure they were used to working with. And from what I could tell in the conversations I had with them, their understanding of red teaming was more procedural than conceptual. They knew which commands to run. They did not always know what the commands were actually doing or why. A pretty novice team, by their own admission in some cases.

The friction was less about any single incident and more about the daily reality of it. Multiple members of their team hovering over different members of mine, giving suggestions that did not fit the situation or asking what was happening every few minutes. My guys were trying to solve hard problems under time pressure, and having someone who could not contribute standing over your shoulder offering commentary was not helping. It wore on morale fast.

I am not going to pretend that did not get to my Marines. The frustration of working a hard problem with limited time and limited sleep while a parallel team watches from the bed and occasionally offers input that does not apply is real, and we had to manage it internally. Part of my job for the op was making sure my Marines did not put hands on anyone from the other team out of pure aggravation. That was not a hypothetical. That was a real management problem I worked on every day.

Getting In

We got in.

I am not going to describe how. I will say that it took longer than it should have, that the new tooling we built held up, and that the moment a payload finally landed on the target side of the proxy, the room went quiet for about two seconds. Then it was chaos. Cheering, high fives, the kind of noise that comes out of people who have been sleeping on hotel room floors for days and just watched something finally work. If you have done this work, you know the feeling. If you have not, the closest analogy I can offer is the moment a long-running build finally compiles clean.

We did some initial enumeration. The interesting thing about that environment was that we were inside a network everyone used, but the parts of it that mattered for the exercise were not really there. The exercise was running on a separate network, and the network we had compromised was, in the end, just a stepping stone toward the network that actually mattered.

The Defenders Took the Network Down

At some point, somewhere in the defender community, word got out that the red team was in for the exercise. The response on their end was to bring large portions of the network down. Not segment it. Not harden it. Bring it down. To keep it safe.

From our side, what that looked like was all of our agents dying at once. One moment we had access. The next moment, nothing. We spent time trying to troubleshoot, which is a difficult thing to do when your only visibility into the network just went dark. I got a call from our point of contact asking if we had done anything to the network, if we had caused the outage. I told them no, we had just lost access ourselves and were trying to figure out what happened. It was not until a meeting later that we found out the defenders had cut the network off deliberately.

I have been doing this long enough to have a lot of opinions about what good defense looks like. None of those opinions include “take the network offline to keep the adversary out.” If your defensive posture is to remove the asset you are defending, the adversary has already won. That is the win condition. That is the outcome we are trying to produce when we plan a denial-of-service operation. You did it to yourself.

I have never seen a red team bring a network down the way a paranoid defender will bring it down. I do not say that to be cute. I say it because it is something I think about every time I work with an internal defense team and the conversation turns to incident response posture. There is a version of defense that protects the mission and a version of defense that protects the network at the expense of the mission. The second one looks the same as a successful attack from the user’s seat.

Cede and Move

The hotel work ended in a way that was difficult but not unexpected. We had actually raised this during planning. The first network was not the real target. The exercise ran on a separate, isolated network, and the two did not connect. We had questioned early on why we were spending time on the first one when we knew where we actually needed to be, but that was the plan we had been given.

To move into the next phase of the exercise, we had to give up the access we had built and move on-site to the part of the base the exercise was being run from. The reason was security. The exercise network was isolated. Anyone touching it had to do it from the right physical environment, on the right equipment, under the right oversight. That meant new laptops, new infrastructure, and starting a lot of things over from the inside.

It was a success for us either way. Everything we built and learned in those hotel nights paid off later. The tooling worked. The techniques transferred. The time we spent getting through RBI was time well spent regardless of which network we were pointed at. And honestly, for all the sleep deprivation and floor-sleeping and two AM taco runs, we had a good time doing it. There were a lot of laughs in that hotel room between the frustration. That is the part people do not see from the outside. The work is hard and the hours are stupid, but you are doing it with people you trust, solving problems nobody has solved before, and that combination produces a kind of energy that is hard to find anywhere else.

So we grabbed our gear, drove out, and got to work.

That is where Part 3 picks up.

This was a wargame, not an operation. Everything described is notional, generalized, and presented at a level intended to convey the experience and the lessons rather than the tradecraft. No personnel beyond those who have written publicly 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.

The first is hard, expensive, and probably unsolvable in the general case. The second is cheap, boring, decades old, and decisive.

We obsess over the first and underinvest in the second, and the result is that when an agent finally goes sideways it has somewhere important to go.

Four things called “escape”

The conversation is muddy because “escape” is doing work for at least four different failures, and most coverage collapses them into one. They are not the same, and the defenses are not the same.

First, there is a human using a hosted model as their operator: someone points an agent at a task and the model, following instructions, reaches into systems it was never meant to touch. The model isn’t rebelling; it’s doing what it was told, badly scoped. Second, there is indirect prompt injection, where third-party content turns a deployed agent against its owner. An attacker plants instructions in data the agent ingests, and the agent treats the malicious payload as operational guidance. Third, there is the subtle one: an agent acting within its granted permissions but outside its operator’s intent. It has the access it was given; it simply uses that access in a way no one authorized. And fourth, there is genuine autonomous breakout, an agent defeating the controls meant to confine it and reaching systems it was structurally supposed to be isolated from.

The first three are intent problems with an architecture dimension. The fourth is an architecture problem wearing an intent costume. The OpenAI-Hugging Face incident is the fourth. Reading it as a story about “rogue AI” rather than a story about containment failure is how we end up buying alignment research instead of fixing segmentation.

The anchor incident, told straight

In July 2026, OpenAI was running internal cybersecurity evaluations on a benchmark called ExploitGym, using agents that were meant to be fully isolated from one another and from the internet. They were not. OpenAI’s own post-mortem, published August 26, states plainly that “OpenAI models circumvented controls designed to isolate them from the internet and compromised parts of OpenAI’s internal research infrastructure and Hugging Face’s systems” (OpenAI).

Read more

This is the first post in a four-part series about a single operation. It is the longest op I have ever worked, and looking back, it is one of the ones that taught me the most about what it actually looks like to do cyber inside a real military exercise. I want to walk through it the way it happened, in order, because the lessons sit better with the context.

A few notes before we start.

I am not going to name the other team that joined us for this op. I am not going to give dates, units, locations beyond what is already public, or any specifics on how we got in. The details have been generalized on purpose. The point of these posts is the experience and the lessons, not the tradecraft. If you are looking for a technical walkthrough, this is not it. If you are looking for what it actually feels like to run a cyber cell during a major Marine Corps exercise, keep reading.

What MWX Is

MWX stands for Marine Air Ground Task Force Warfighting Exercise. It is run out of Twentynine Palms, California, in a stretch of desert that is, to put it kindly, an honest place to learn how to fight.

The basic premise is that Marine units go head to head in the desert with capabilities they would almost never get to exercise in a normal training cycle. Special operations, cyber, information operations, influence campaigns, aviation. The full picture of what a modern force actually fights with. These are capabilities that, for most of the units involved, only show up at the high end of real-world operations. MWX gives them a chance to integrate, build the muscle memory, and learn the hard lessons before those lessons get expensive.

For the Marine Corps Red Team, MWX was a different kind of exercise. We were not there to compromise a target for assessment. We were there to act as a real adversary inside a live wargame, working alongside conventional and special operations forces, and providing cyber effects that would have a measurable impact on how the battle unfolded.

If you have never been part of something like this, the simplest way I can describe it is that everything happens at once. The kinetic side is moving. The intelligence side is moving. The cyber side is moving. And the only way it works is if everyone has rehearsed enough to know what their piece of the puzzle is and how it fits into everyone else’s.

We were the cyber cell. I was the lead of that cell for this operation. At the same time, I was the chief of the Marine Corps Red Team, and I was a Gunnery Sergeant. Three hats. All of them mattered.

The Planning Phase

The planning for this op was, in a word, painful.

Leadership had turned over in the months leading up to MWX, and the new people in the chairs above us did not have a working understanding of cyber. That is not a criticism of them as officers. It is a recognition that cyber is a specialized field, and dropping someone with a different background into the supervisory role over a cyber team without ramp-up time will produce predictable friction. We were in the middle of that friction.

What that friction looked like in practice was a series of long planning calls in the weeks before we headed out to the desert. The new leadership wanted cyber plugged into the Master Scenario Events List, the MSEL, which is the chronologically sequenced outline of simulated events that exercise participants are supposed to respond to during the exercise. It is the backbone of how conventional exercises run. You write down what happens and when, and the exercise unfolds against that timeline.

The expectation was that we would fill in our rows of the MSEL the same way an artillery battery or a logistics section would. Tuesday at 0900, gain initial access. Tuesday at 1100, escalate privileges. Wednesday at 1400, exfiltrate data. Discrete steps with discrete timelines, the same way you would build a schedule for a vehicle convoy or a live-fire range.

That is not how offensive cyber works. It is not how defensive cyber works either, for that matter. Both sides of this game are reactive by nature. You build a plan, but the plan survives contact with reality for about as long as it takes to send the first email. Just like real combat. After that, you are responding to what the target environment is actually doing, what the defenders are noticing, what tools are catching what payloads on what day, and what the network looks like once you are inside it instead of what you assumed it looked like before. The idea that we could write down a sequence of events weeks out and then execute it on schedule was, frankly, not connected to reality.

So we sat on those calls trying to make it work anyway. We built Excel documents full of branching scenarios, guessing at where we might be at various points in the exercise and trying to keep our timelines at least plausible. I was holding back a lot of frustration on those calls. I understood why they wanted the MSEL populated. It is how the rest of the exercise runs. It is how the exercise control element tracks what is happening. But trying to force cyber into that format is like trying to schedule a bar fight. You can write down what you plan to do, but what actually happens depends on who shows up, what they are carrying, and whether the first punch lands.

We pushed back where we could. Some of the pushback worked. Some of it did not.

The Weird Asks

The other thing that came out of that planning cycle was a set of tasking requests that were just strange.

This was not unique to this exercise, and honestly it is not unique to the Marine Corps, military at large, or the private sector for that matter. It is a pattern I have seen across the entire time I have worked in cyber. People who do not have deep experience with the discipline, and sometimes people who do, tend to think of cyber in movie terms. They picture dark rooms and hoodies and someone typing furiously while a progress bar fills up on a screen. They want cyber to be cool. They want the kind of operation that sounds impressive in a briefing, the multi-stage chain that makes the room go “whoa.” What they do not picture is the reality, cyber is a lot of reading code, searching for answers in documentation, and banging your head against a desk until you find something that actually works.

One of the tasking requests that came out of this planning cycle with the unit we were going to work for this time was a multi-stage initial access chain that started with a whaling attack against a specific person’s BlackBerry, pivoted to their Teams account, used that to send a payload to a different person’s phone, and from there moved laterally into the target’s email environment. I am not going to get into whether that chain was technically feasible. The point is that it was wildly more complicated than it needed to be for the access we actually wanted. A normal phishing campaign would have produced the same end state with a fraction of the moving parts. Every step you add to an attack chain is a step that can fail, and the more elaborate the chain, the more places defenders have to spot you.

When you ask why a tasking is built that way, the answer is sometimes that the person writing it has seen something cool in a briefing somewhere and wants to see it happen, regardless of whether it is the right tool for the job. Again, that is not unique to the Marine Corps and it is not unique to cyber. It is just human. But it is the kind of thing you learn to manage, because the people writing the tasking are the people you report to, and you do not get to roll your eyes.

We had a group call about it. I pushed back hard. I told the people on the line that the chain as written was a dumb plan, and I started laying out why. The first stage alone had problems. Whaling is inherently risky because VIPs tend to be closely monitored, which means your phishing attempt is more likely to get flagged before it ever reaches the target. On top of that, the plan assumed the target was carrying a BlackBerry, but the Marine Corps was in the middle of phasing BlackBerries out in favor of iPhones and Androids, so there was no guarantee of what device the person would actually have in their hand on the day. That matters because phone payloads are not computer payloads. The development work, the exploit surface, the delivery mechanism are all different depending on the platform, and building for three possible phones instead of one triples the prep work for a single stage of a chain that had four more stages after it. A normal phishing campaign against a broader target set would have put us in the same position with a fraction of the risk and a fraction of the development time. I was not subtle about it.

Somewhere in the middle of explaining why the plan was bad, it became clear that the officer I was actively talking to was the officer who had written the plan.

I stuck with it. I had already said what I said, and walking it back would have been worse than saying it in the first place. He listened. To his credit, he did get a bit defensive but never combative. He told me, plainly, that he thought it was a cool plan. I told him it was a cool plan. The two statements are not in conflict. A plan can be interesting and also be the wrong plan for the time and resources you have. I walked him through what it would actually take to execute the chain the way he had drawn it up, including the development time, the infrastructure, and the opportunities for the entire op to come apart if any one of the stages did not land. By the end of the conversation he was the one telling me to go with the simpler approach.

I have had many calls like that since. It was not the first time I remember telling something honest to a senior officer who had every reason to take it personally and watching the conversation get better, not worse, because of it. It was though, in retrospect, a piece of foreshadowing for something that happened later in the op with a much more senior officer. We will get to that.

There was another problem hiding in the simple phishing plan, though, which is that the Marine Corps had just stood up a new web proxy capability with remote browser isolation in front of it right before the exercise started. It was kicking our ass. Standard delivery techniques that had worked a quarter ago were getting eaten. We were going to need to build something new before the real op even started.

That realization was a punch in the gut. We had spent weeks preparing, building tooling, testing delivery chains, and a significant chunk of what we had built was suddenly useless against a capability that did not exist the last time we had done this. But that is also part of the game. The target environment does not hold still for you. If it did, the exercise would not be worth running.

That is where Part 2 picks up.

This was a wargame, not an operation. Everything described is notional, generalized, and presented at a level intended to convey the experience and the lessons rather than the tradecraft. No personnel beyond those who have written publicly 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.

Same OPSEC posture as the rest of the series. Details generalized on purpose.

The Mix of Work

The operational portfolio for the Marine Corps Red Team was broader than a lot of people outside DoD would assume.

We did long-term operations against the Marine Corps enterprise network. Sustained, slow, methodical engagements designed to assess whether the institution could detect and respond to an advanced adversary inside its own infrastructure over time. Those were among the most valuable engagements we ran, because they exercised the full defensive stack against the kind of patient threat actor that real adversaries actually are.

We did tactical exercises. MWX is the obvious example, and it will get its own series on this site, but there were others. The exercises put us in support of conventional or special operations forces and asked us to deliver cyber effects in the context of a broader operational picture. Some of those went very well. Some of them were among the longest stretches of my career. Some of them were disappointments. All of them taught something.

We did acquisitions penetration tests, which is the somewhat unglamorous label for the work of evaluating the security of new systems and capabilities before they were fielded. The goal was to find the problems early, when there was still time to fix them, instead of late, when fixing them would mean ripping things out of a deployed environment. That work was, in many ways, the most leverage-positive thing the team did. A finding caught at acquisitions saved orders of magnitude more effort than the same finding caught after fielding.

We did other things in support of US Cyber Command and Naval Special Warfare Command that I am not going to describe in any detail. The general shape of the work involved being asked to operate at the high end of what was possible for our size of team, against targets that justified the level of effort. Some of those engagements are among the things I am most proud of from the entire career. None of them are going on a blog. This picture is what you are going to get.

The Units That Did Not Want Us There

The pattern that came up repeatedly, especially with tactical engagements, was the mismatch between who invited us and who actually had to host us.

The way these engagements often worked was that a request would come down from a command several echelons above the unit we were going to. A general officer, or someone working directly for one, would decide that a particular subordinate unit needed to be exercised. The request would flow down the chain. By the time it reached the unit, the unit had not asked for us, did not particularly want us, and had no real ability to refuse.

You can predict what happened next. The unit treated the engagement as an inspection rather than a training event. The framing was adversarial from the moment we arrived. People we were supposed to be working with administratively were not enthusiastic about supporting our work. Information that we needed to operate effectively had to be pried loose. Coordination was minimal. The unit’s instinct was to protect itself rather than to learn from the exercise.

I understand the instinct. I do not agree with it, but I understand where it comes from. Marines have careers. Careers are damaged by reports that say the unit did not do well. The natural defensive posture, when someone shows up to evaluate you against your will, is to limit their ability to evaluate. I have seen the playbook many times. Make the visitors uncomfortable. Slow-walk the support. Be technically helpful but never volunteer anything. Make sure the report has the smallest possible surface area.

This was, in my experience, the worst kind of engagement to run. Not because it was technically difficult. The technical work was usually the same as any other engagement. It was the worst kind because the value of the engagement collapses when the host unit decides not to engage with it. The point of a red team engagement is the conversation that happens afterward. The findings are not the deliverable. The conversation about the findings is the deliverable, because that is where the actual security improvement happens. A unit that has framed the engagement as an inspection has already opted out of the conversation. The report goes into a folder. Nothing changes.

We did the work anyway and delivered the reports to the best of our ability. Some of the units took the reports seriously and some did not. The ones who did not, I think about sometimes, because the vulnerabilities we found were likely still there long after we left. The network is often build and torn down for each exercise, but it is often from a standard template or process.

The Cell That Got Unplugged

There is one engagement in particular that I think about whenever this topic comes up. I was not on this op personally. One of our cells was.

The setup was the usual one. A request from a higher command to assess a subordinate unit that did not want us there. Our cell deployed and was given a single room from which they were authorized to work, on the grounds that all red team activity needed to be confined to a controlled space.

The defenders’ response was to pull the plug on the room.

I want to be precise about what I mean by that, because the precision is the point They did not implement network controls that limited what the room could reach, they did not segment the network to constrain the team’s ability to operate, they did not change a firewall rule, push a policy, or do anything to the network that they were supposed to be defending. They walked into the room our team was sitting in and physically disconnected our team from the network. That was the defense. Unplug the red team so the red team cannot assess the network. Leave the network in whatever state it was in. Declare victory.

From the team’s perspective, they had been put in a closet and the door had been locked. The network on the other side of the wall was, as far as anyone could prove, exactly as secure or insecure as it had been on the day the team arrived. Nothing had changed about it. The only thing that had changed was the team’s ability to look at it.

When the engagement ended and the defenders briefed up the result, they framed it as a defensive win. They had successfully prevented the red team from causing any harm to the network. They gave themselves awards for excellence in defense.

I am not making this up. I wish I were.

The reason this story sticks with me is not that it was funny, although it was a little funny in retrospect. The reason it sticks with me is that it is the cleanest possible illustration of the failure mode I wrote about in the compliance post. The unit had not defended the network. The unit had defended itself from being assessed. Those are not the same activity, and conflating them is exactly how an organization ends up secure on paper and exposed in reality. The vulnerabilities the team would have found were still there when the team left. The only thing the unit had proven was that it could prevent a friendly red team from telling it where they were.

The other thing the story illustrates is the danger of letting the host unit grade itself. If the framing of the engagement allows the defenders to declare victory by removing the red team from the network, the engagement is not measuring defense. It is measuring how willing the unit is to break its own infrastructure to make the visitors go away. Those are very different things.

The Programs of Record

One of the recurring themes in the operational work was what I came to call the “it works so do not touch it” problem.

Many of the systems we evaluated were not custom builds. They were commercial products or programs of record, set up at some point in the past by an installer who configured them with the vendor defaults and then walked away. The defaults made the system work. The defaults did not make the system secure. The defaults are designed by vendors to maximize the probability that a new installation will function out of the box, because a system that does not function out of the box generates support tickets and reputational damage for the vendor. Security is a secondary consideration in default configurations. It always has been.

The pattern we saw, again and again, was the system installed at defaults, the system working, and nobody touching the configuration after that because there was no incentive to. Touching a working system risks breaking it. The administrator who breaks a working system has a problem. The administrator who leaves a working system alone has no problem until an adversary shows up. The cost of inaction is invisible. The cost of action is immediate. The math is bad.

This is, I think, the single largest source of preventable vulnerability in real-world networks. It is not zero-days. It is not exotic tradecraft. It is systems sitting at defaults because the people responsible for them are reasonably risk-averse about modifying anything that is currently working. The fix is not technical. The fix is cultural. You have to create incentives for administrators to harden their configurations and remove the incentives that punish them for breaking things while they are doing it. Most organizations do not. Ours did not. The vulnerabilities accumulate.

Becoming Chief

In 2021, my friend rotated out of the chief seat and I rotated up into it.

The transition was less dramatic than it sounds. I had been doing a significant portion of the chief’s work as the engineering cell lead anyway, because the engineering cell lead is where a lot of the operational decisions land in a small team. Taking the title formalized what had already been happening. What changed was the surface area. The chief is the public face of the team to leadership, to other units, to other red teams, and to the inspection apparatus. The chief is also the person who carries the team’s culture, the team’s tempo, and the team’s standards. Those responsibilities did not exist in the engineering cell lead seat. They existed now.

The team I inherited was a team I knew. I had built half of its infrastructure and worked alongside the rest of its operators for years. The transition was clean and the team kept moving. The chief seat came with new conversations, new visibility, and a different kind of pressure than the engineering work had. Some of those conversations went well. Some of them went the way a particular conversation with a Commanding General would later go during MWX, which is to say I told people things they had not been told before and I lived with the consequences. That one is its own story and will get its own post in the MWX series.

That stretch is where MWX happened, which I will write up in its own series. It is also where the funding situation got fully clarified, in a way that produced the unwritten agreement I want to close this post with.

The Unwritten Agreement

I mentioned in the intro post on this site that I paid for infrastructure and domain registrations out of my own pocket because the team had no budget line that fit. I want to give the fuller version of that here, because it is part of what the chief job actually was, and because it illustrates how a small team makes do.

The team needed things. Domains, mostly. Hosting, occasionally. Small purchases that were operationally necessary and that, under the institution’s procurement rules, were essentially impossible to acquire through legitimate channels in any useful timeframe. The procurement process was designed for predictable expenses planned a year in advance. Red team operations do not work that way. When you need a domain for a campaign that is launching in three weeks, you do not have a year to wait for the procurement system to produce one.

I saw the leadership of our broader section, the same leadership we fell under, dress down a federal civilian for spending five dollars on fishing line that was needed for a physical operation. Five dollars for fishing line. The deputy who handled the team’s compliance with procurement rules was, in theory, supposed to enforce the same standards on me.

He and I had an unwritten agreement.

I was military. He was federal civilian. The chain of command meant that his ability to enforce procurement rules against me was structurally weaker than his ability to enforce them against another civilian. We both knew it. The agreement, never spoken aloud, was that I would make sure the team had what it needed and he would not ask questions about how. I bought what needed to be bought. He never inquired about the line items he was not seeing. The mission moved forward.

I am not going to romanticize this. I should not have been spending my own money on operational infrastructure for the United States Marine Corps. The institution should have figured out how to fund its own red team. The fact that it did not, and that the team produced anyway, is not a triumph of grit. It is a failure of resourcing that the team papered over because the alternative was to fail the mission. I did what I did because the people depending on me were going to depend on me regardless of what the procurement system did or did not do, and the only acceptable outcome was that the team had what it needed when it needed it.

The lesson, looking back, is not that you should pay for your unit’s infrastructure. The lesson is that if the institution does not fund the work, the work either does not happen or it happens on the backs of the people doing it. Both of those outcomes are bad. I laid much of the groundwork to finally getting new gear by jumping through the many, many hoops in military procurement. Some of it even started to arrive shortly after I left the team and they have started getting more gear since, thankfully.

The End of the Stretch

There are more operations from that period than I can fit into a single post, and I am going to keep writing about them as I think of the right framing for each one. The longest op of my life is the next series I plan to publish on this site. There are others that deserve the same treatment.

What I want to leave this post on is the same throughline that has been running through the whole memoir series. The work was hard. The conditions were not the conditions you would design from scratch. The team was smaller than it should have been and resourced less than it should have been. The org chart worked against the work. And we produced anyway, because the people were the people, and the friendships were the friendships, and the mission was the mission.

Eventually I rotated off and out of the Marines. The reasons are in the intro post. The work I did at MCCOG with the team I worked with is the foundation of everything I have done since. I owe that team a debt I am going to spend the rest of my career trying to pay back. This series of posts is the start of it.

There will be more.

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.

We’ve all seen it: every time you open and doomscroll LinkedIn, there’s inevitably a post that’s AI-generated and likely prompted by something along the lines of “generate a hot take on X topic.” It’s gotten so out of hand that LinkedIn even instated a “seems like AI slop” button to combat the chaos. Accounts are talking past each other in an effort to be the loudest voice on the net, all while using thoughts and ideas that aren’t even original or personally manifested. I think we can all agree on one thing: something is seriously wrong when we find noticeably human-generated content refreshing.

If we’re all so bothered by it, why do most among our masses continue to do it? Why do so many continue to perpetuate the exact steps that most find to be, at minimum, disingenuous? I have a few theories that I promise I came up with on my own.

In a Tough Job Market, Relevance is King

I can’t put a number to the amount of posts I’ve seen from exasperated, unemployed folks desperate to find a job after hundreds of submitted applications have gone unanswered. With geopolitical conflict causing economic volatility, job security is a valuable card to hold; without it, livelihood can quickly become a matter of survival. Candidates looking for the next venture, or in worst case scenarios those that have been blindsided by layoffs, find themselves in dire straits and urgently seeking employment. In an age where professional reputation in the tech industry is signaled through cutting-edge research, LinkedIn takes, and being the “pillar an entire department stands on,” standing out is critical. At the same time, “machine speed” is alive and well; it’s the forbidden fruit that looms as the potential guarantee to dominate uncharted research territory. This leads me to believe that today’s employees feel like their own creativity and technical prowess is not enough to edge out competition, especially when that competition is operating as fast as Claude can respond. With livelihood potentially at stake, and burnout at an all-time high, many are trusting LLMs with the hail mary pass that’ll land them the next opportunity. So, cue the AI-generated LinkedIn hot takes and blog posts summarizing research on topics that, honestly, the prompt engineers likely don’t fundamentally understand. It’s the chance to stay relevant in a sea of LLM noise created by other equally frustrated professionals trying to guarantee food stays on the table.

Your Payday is a Prompt Away

If you had the opportunity of spending even a moment in the Black Hat business hall a few weeks ago, you’ll know you couldn’t walk 10 feet without seeing signage around autonomous pen testing, autonomous red teaming, or agentic security solutions. As a researcher focusing on secure AI integration and development, my biggest concern arose when booth staff couldn’t answer simple questions around their flagship solution. Simple asks around “are you running frontier or local” were met with “I’m not sure how to answer that, would you like a hat?” That interaction I think best represents the tech industry in the present moment: “I’m not completely sure what I’m building or how it works, but I’m sure it’s valuable and you should buy it.”

Why was the Black Hat vendor hall a tapestry of copy-and-paste pitches? My personal take is that folks in the sector see headlines like Cursor being acquired for 60 billion dollars and feel like their payday is a prompt away. With coding agents that can build Flask web apps in minutes, and a dash of entrepreneurial confidence, many professionals feel like a lottery-sum of money is within their reach if they simply channel the right idea into the perfect prompt. Couple this mindset with the unease around job security, a fluctuating economy, and self-worth being hedged in professional success (which is its own problem), and you have the status quo.

“So You Must Not Use AI Then?”

It’s not lost on me that I’m preaching about the death of human and professional authenticity when I very clearly work in a space that enables autonomous systems and their research. It would be naive to think that anyone can move forward in today’s tech sector while shunning agentic solutions and autonomous integrations. The problem isn’t the technology; it’s how we wield it.

In a previous blog post I equated using AI in security to piloting a Gundam (or a fighter jet if you’re not THAT nerdy). You sit a seasoned fighter pilot in that jet and that individual will deliver precise bombs on target in a timely and efficient manner. You sit me in a jet and you’ll probably get an equal amount of damage, except it’ll be to the jet and surroundings. The tool is only as meaningfully impactful as the human driving (or flying) it. Autonomous systems can absolutely augment today’s security professional, but the keyword is augment, not replace. If you’re a flight or maritime nerd, you might say “alright Max explain autonomous drones and boats, how’s that not replacing humans?” My response to that is, work up the chain. The pilot may not be in the vehicle, but someone’s responsible for the oversight and overrides. A human professional is ultimately responsible for ensuring that the autonomous solution emulates and augments human capability. After all, that’s what it’s trained on, right? The human thought process is the paradigm upon which agentic solutions are built.

So yes, use AI. Augment your workflows and replicate yourself across lines of effort, but don’t outsource your thoughts and your ingenuity to a system built on probability and vector math.

Be Human

The most meaningful interactions I had in Las Vegas were with security professionals who shared both the joy and pain of today’s ecosystem as we know it. They shared in being overwhelmed, frustrated, concerned, and in some cases amused by what the tech industry has become. In those interactions, I gained the most value from listening to the problems they were faced with, how it affected them, and how they planned to tackle the adversity that lies ahead. At the end of the day, we are humans steering solutions in an effort to advance. Advance to what? Well, what moves you? Advancing humanity? Providing for a family? Traveling the world? Our “why” fuels our human ingenuity. True human ingenuity is not outsourceable, it is the engine that manifests modern marvels, built engineering feats like the SR-71, and built the Bombe that cracked the Enigma. We are so much more than the diluted output ChatGPT gives us as our LinkedIn posts for the week.

Vol 2 ended with the throughline that small teams with limited resources can still produce good work, but the cost of that work falls on the people doing it. I closed by saying that this post would be about the people who made the cost bearable.

This one is harder to write than the last two. The technical and organizational material I can lay out in a tidy way. The people, I cannot. I am going to do my best. Some of the people in this post deserve their own posts down the road, and they will get them. This one is the introduction. The fuller pictures come later.

Lance

Lance Cain came to the red team from the infantry side. He was a grunt who went cyber, and he hit the ground running.

The pattern with Lance was easy to spot from the first month. He had the energy of someone who had decided this was the work he wanted to do, and once he had decided, he attacked it the way you would expect a Marine with a few years of infantry experience to attack a problem. Head down. No drama. Whatever the next thing was, he was on it. I have worked with a lot of people in this field. Lance is in the small group I would put forward without hesitation if you asked me who to hire.

He was my right hand for most of my time on the team. We have published research together. Some of that work came out of nights in a hotel room, the cell taking turns staring at the same problem until somebody cracked the next piece. I will write about that initial work in future posts. The short version is that the partnership produced real output, and the writeups that came out of it are still in circulation.

What Lance has gone on to specialize in is Mac. He has been compounding it ever since. He is at SpecterOps now, and at this point if any Mac-related research, tooling, or technique comes out of SpecterOps, Lance’s fingerprints are on it in some way, whether the byline credits him explicitly or not. That kind of depth does not happen by accident. It happens because somebody decided, years earlier, that this was going to be the thing they got really good at, and then they put in the work, every day, for as long as it took. This was Lance and Mac.

He has been doing it for as long as it took. He is still doing it now. He earned every byline he has, and I would not bet against the ones that are still coming.

The other thing about Lance is that he made the work entertaining. Not in a clowning around way. In a "this is a hard problem, let's figure it out together and enjoy doing it" way. That quality, the willingness to enjoy a hard problem in real time while you are inside it, is one of the rarer things to find in this field, and it is what separates a team that operates from a team that just grinds through. Lance brought it to the room.

Pete

Pete McKernan joined the red team around the same time I did. It’s always hard joining a new team and integrating, but Pete and I hit it off right away. The short version is that we figured out within about ten minutes of the first real conversation that we had both come up as technical controllers before finding our way to cyber. That shared background is a particular kind of shorthand. You can skip a lot of explanations and get to the actual work.

Pete is the kind of operator who you want in the chair when something is going wrong. He is calm under pressure in a way that is hard to fake. He has a strong technical foundation, and a sense of humor that gets sharper the worse the situation gets. That last part is the part I want to spend a minute on, because it is the thing that most defined working with Pete during those years.

Pete was the joker in the best way. He kept things light. No matter where we were, no matter what we were doing, Pete brought the energy of standing around the smoke pit shooting the shit with your friends. Hotel room at two in the morning, third night in a row, infrastructure on fire? Pete was telling a story. Government conference room with leadership about to walk in? Pete was making the side eye joke at someone on the team that nobody else was supposed to catch. Operations center in the middle of a serious push? Pete was finding the one thing in the situation that was actually funny and pointing at it.

That is not a small thing. Long stretches of intense work wear people down, and the teams that survive those stretches are the ones that have somebody in the room keeping the mood survivable. Pete kept the mood survivable. He made the work fun.

He also writes, which the rest of the team mostly did not at the time, and he writes well. Several of us, Pete included, also publish over at itsbroken.ai when we have something lighter or more AI-flavored to say. The tone of my own writing owes something to his voice, by his own admission, and I am happy to admit the influence. Friends sharpen each other's writing the same way they sharpen each other's operations. Iron sharpens iron.

The other thing about Pete is that the partnership we built during those years did not end when one of us left the Marines. It carried forward.

Becky

Rebecca Allor deserves her own post. She is going to get one. This is the short version.

I knew Becky before either of us was on the red team. We had been at the same unit for a few years, in different shops, before we ended up in the same shop in the months leading up to both of us moving on. She got out of the Marines. I went to Okinawa and the years passed. When I got to MCCOG and started crossing paths with the red team, there she was, on the team, doing the work. The re-meeting was one of those moments where you realize the world is smaller than you thought it was.

We rebuilt the friendship in and out of the work. Red teaming was the obvious common ground. Firearms were another. The biggest bond, though, was a shared love of lifting things repeatedly. Somewhere along the way we became close friends, and we have been close friends since.

One thing the rest of the team will confirm without prompting is that Becky was the one who made sure we ate. We had a pattern. Becky would ask whether we were going to get food. The rest of us would say fifteen more minutes. Then we would say fifteen more minutes. Then we would say it again. After enough rounds of the fifteen-more-minutes loop, the energy in the room would shift, Becky would explode on us, and the whole team would know that it was time to pack it in for the day. We came to depend on it.

The food was not really the thing, though. The food was the byproduct. The thing was that we were pushing too hard, and not eating was the most visible symptom of pushing too hard, and Becky was the only person in the room who was tracking the symptom against the underlying problem. We were heads-down inside the work, telling ourselves we were on the verge of breaking through, when what we actually needed was an hour away from the screens. Becky was reading the room better than the rest of us were. She knew when the team had passed the point of useful output and was now just grinding for the sake of grinding. She knew the reset would make the next stretch of work better than the one before the break. We knew it too, in some part of our brains, but we were inside the problem and could not act on it. She could and did.

There is a particular kind of stamina that comes from having someone on the team who is willing to put up with any number of fifteen-more-minutes increments but who has a clear breaking point past which the team is going to eat and go home. Becky was that. We always knew where the edge of the day was because she was the one who would tell us when we got there. We pushed every time. She called it every time. The combination worked because both halves of it were honest.

The food thing is the light version of who she is on a team. The heavier version is the part of the friendship that has carried both of us through some hard stretches. We were each supportive when the other lost our fathers. We have helped each other through the kind of personal weight that nobody on the outside really sees. The clearest version of that, for me, is the story I want to close this section on, and it is one I will tell in more detail in her dedicated post when I get to it.

The day my dad went into a coma after a motorcycle accident, Becky and I were on an op together when the news came through. I was a long way from home, a long way from my family, and the work was not the kind you can walk out of in the moment the phone rings. The op had days left to run, and I was the person responsible for what was happening on the ground. I was going to be in the desert for several more days no matter what I wanted.

Becky was the person right there and the only one I told. I was the lead, and I needed to put on a strong face for holding the op together. She was there holding me together. She picked me up, both literally and otherwise. She handled what needed handling on the ground so I could deal with the part of it that was mine to deal with. She got me through the days until I could get back to my family.

She also knew that sitting in a hotel room with my phone for days was going to be its own kind of damage. So she decided we were going to Joshua Tree.

It was supposed to be a day hike. The brief was “be back at the car by sunset.” We made it to the top, watched the sunset from where we were, and then, several beats later than we should have, realized we were considerably further from the car than we had remembered. The way back was longer than the way out had felt, the light was going, and we had to put some real effort into getting back without doing something stupid. We laughed about it then and we laugh about it now. It was exactly what I needed in the moment, and Becky was the reason it happened.

The trip did not fix anything. There was nothing about my dad’s situation that a hike was going to fix. What it did was get me out of the hotel room, out of my own head, and into a piece of country where the only thing I had to think about was where my next step was going to land. That was the thing I needed.

I do not have a clean way to describe what it means to have someone on the team who can absorb that kind of moment without flinching. I just know what it was like to be on the receiving end of it. The willingness to drop what you are doing and drag someone into the desert because they need it is the kind of friendship that does not come around twice in a career. I may be three times her size, but she has carried me further than most. I have been one of the people she leans on since, and I expect that to keep going both ways for as long as we are both around.

She gets her own post. I am looking forward to writing it.

Clint

Clint passed away a few years ago. This is the hardest paragraph in this post, and probably in this series.

Clint was a C# phenom and a command-and-control framework specialist of the kind you do not see often. He was the heart of the team and, functionally, the single person who maintained the Marine Corps Red Team’s long-term persistence capability. That is not an overstatement. The work he did was load-bearing for the team in a way that I do not think anyone outside the building fully understood at the time. He worked quietly, he produced relentlessly, and he made everyone around him better.

He was also, as a person, the kind of teammate who you wanted to be in a room with. Generous with his time. Generous with his expertise. Quick with a joke. He cared about the people on the team in the way that only someone who is paying attention can. He noticed things and he always showed up.

He is going to get his own post. It will not just be from me. The people who worked with him are going to write it together, because no single piece of writing is going to do him justice and the collective version is the right version. If you knew Clint and you are reading this, you already know what I mean.

The Rest of the Team

I am not going to list every name. The people I worked with on the Marine Corps Red Team know who they are, and the ones who are still in the work know that the relationships did not end when the uniform came off. The team was small enough that everyone mattered. There was no dead weight to carry. There was, every day, someone who was carrying something for you, and every day, someone you were carrying something for.

I think about that team a lot. The conditions we worked under produced something that more comfortable conditions would not have. We needed each other in a way that I do not think I have fully needed any team since. The combination of small headcount, real operational responsibility, limited resources, and difficult organizational placement made the team into something tighter than its individual members would have produced on their own. The friendships are still real. The friendships are why the work mattered.

What the People Made Possible

The reason this post is in the middle of this series, instead of at the end of it, is that the people are not the epilogue. The people are the substrate. Everything I have already written about the work, and everything that is coming in Vol 4 and beyond about the operations and the inspections and the hard organizational moments, depends on the people I just described.

A small team without resources cannot produce on talent alone. It produces on cohesion. Cohesion is not an abstract concept. Cohesion is the specific quality of Lance staying late because the work is not done. The specific quality of Pete keeping the mood survivable when the situation should not have been survivable. The specific quality of Becky making sure the team actually took care of ourselves at the end of the day. The specific quality of Clint quietly maintaining the part of the system that everyone else depends on without ever making it a performance. The team produced because the team was the kind of team it was. The output was downstream of the people.

I have thought a lot, since leaving the Marines, about how to recreate that kind of cohesion in environments that have more resources and less forced intimacy. The answer is not obvious. I do not have a clean theory yet. What I do have is a clear understanding of what it looks like when it exists, because I lived inside it for several years, and the bar that experience sets is one I am going to spend the rest of my career trying to live up to.

Vol 4 picks up with the operations. The good ones, the long ones, the ones where the defenders pulled the plug and gave themselves awards, and the lead-in to the longest op of my life.

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 people rather than the tradecraft. Personnel referenced in this post publish or have published publicly under their own names. 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.

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.