Defending Agentic Systems: Six Powers Your Defenses Were Never Built to Stop
An AI agent was given a routine task. It hit a small problem, decided on its own to fix it, went looking for a way through, found a credential sitting in an unrelated file, and deleted a production database. The whole thing took nine seconds. No attacker was involved. The agent did exactly what it was built to do.
For thirty years we defended systems that did what they were told. That is over, and not in the way most people expect. The danger is no longer only that someone breaks in. The danger is that the system we built to help us will act against us on its own, in pursuit of the goal we handed it.
The server obeyed its configuration. The application followed its code. The service account used exactly the permissions we assigned it, no more. When something went wrong, we could trace the failure back to a line someone wrote and someone else could read. The relationship between intent and behavior was tight enough that we could reason about it, draw a perimeter around it, and sleep at night believing the perimeter held.
An agentic system breaks that relationship. It observes its environment, decides what to do, acts on the world, remembers what happened, and coordinates with other agents to reach a goal we gave it. It does not follow a path we defined. It finds one. And the path it finds almost never passes through the controls we built for systems that obey.
This is why defending an agent is not a harder version of defending a server. It is a different problem. The sooner we say that plainly, the sooner we can build defense that actually works.
What We Used to Defend, and Why It Was Easier
Traditional cyber defense rested on a quiet assumption we almost never stated out loud. The thing being protected was deterministic. It did not negotiate with the controls. It did not look for shortcuts. It did not take a rule meant for one situation and generalize it into another. A firewall rule was a wall. An access policy was a wall. A code path was a wall. The system ran inside those walls because it had no capacity to do otherwise.
On that assumption, the entire discipline made sense. We built the Cybersecurity Compass around three continuous domains, Cyber Risk Management before a breach, Detection and Response during one, and Cyber Resilience after. We placed a Security Operations Center at the center of detection. We mapped attacker behavior with frameworks like MITRE ATT&CK. We assumed a human adversary on the outside trying to get in, and a system on the inside that would behave predictably until that adversary subverted it.
Every one of those choices was correct for the systems we had. None of them assumed the system itself could decide to act against our intent without an attacker touching it at all. That is the assumption that no longer holds.
What an Agent Can Do, and the One Thing That Makes It Dangerous
What makes a system an agent is not one capability. It is a set of powers that arrive together. The system can decide for itself. It can read the world around it. It can reach into that world and change it. It can carry what it learns from one moment into the next. And it can work through other systems to get things done. Strip any one of these away and you are back to ordinary software. Put them together and you have something that behaves less like a program and more like an actor.
These powers are what make agents valuable. They are also, one by one, where defense now has to live. Every power we grant the system to make it more capable is a power an adversary can borrow to make it more dangerous. This is not a defect in any product. It is the price of agency itself. The more a system can do on its own, the more there is to defend, and the less of it resembles anything we learned to protect.
Five of these powers describe what the agent can do. The sixth is different. It is not a capability sitting beside the others. It is the force that drives all of them, the reason the agent uses its powers the way it does. I will take the five first, because each one fails in its own way and a defense that closes one of these doors can leave the next one standing open. Then I will name the sixth, because without it the other five look like a list of features instead of what they actually are, which is a machine with a will of its own.
The Power to Decide
The first power is the freedom to choose the next step without asking. This is the essence of an agent, and it is the source of every risk that follows. The system is not waiting at each fork for a human to point the way. It picks the path itself, in the moment, under conditions no one anticipated.
The defense problem is simple to state and hard to solve. You cannot approve a decision that has not been made yet. In the software we are used to, every branch was written in advance, so every possible outcome was knowable, at least in principle. An agent writes its own branches as it runs. We are no longer signing off on a fixed list of actions. We are placing faith in a process to choose well in situations we never mapped. That forces defense to give up on approving outcomes and start constraining the authority that produces them, because the outcomes can no longer be listed before they happen.
The Power to Read the World
The second power is the ability to take in whatever surrounds the system and treat it as input. This looks harmless. It is the most exposed surface of all. Everything the system reads feeds a decision, and the system has no dependable way to separate information it should reason about from instructions someone buried inside that information.
This is where an attacker spends the least effort for the greatest return. A planted document. A tampered web page. A tool response shaped to mislead. A message written for the agent to read rather than the human. The system takes it in, accepts it as honest context, and acts. The adversary never has to touch the system at all. They only have to leave a signal somewhere the system is going to look. A system that cannot tell a trusted instruction from a thing it merely read can be aimed by anyone able to place content in its path.
The Power to Change the World
The third power is the one that separates talk from consequence. The system does not only describe the world. It reaches in and alters it. This is the line between a model and an agent, and it is also the line between an awkward sentence and a real loss. A wrong sentence can be retracted. A transfer that has been sent, a record that has been deleted, a setting that has been pushed to production, these have already happened by the time anyone notices.
Defense here is about consequence, not conversation. The question is no longer whether the system might say something harmful. It is whether the system can do something that cannot be taken back. Any action that changes the state of the world, above all one that is irreversible, has to sit behind a barrier the system cannot lift on its own. Once a system can act, the cost of being wrong is no longer counted in words. It is counted in damage.
The Power to Remember
The fourth power is the ability to carry information forward, so the system grows more useful as it goes. It is also the quietest danger in the entire design, because it turns one moment of compromise into a standing condition.
This surface alone should give us pause. An attacker who manages to write a single instruction into what the system retains does not need to come back. The system will recall that instruction and act on it whenever the right moment arrives, on its own, with no further contact from the adversary. We spent decades learning how to push attackers out of our networks. We are now building systems where the attacker can walk away and leave the attack behind, living inside the system’s own account of what it is meant to do. It is worse than that, because the system often decides for itself what is worth keeping and when to bring it back, so the poison can be planted and later acted on without a human ever seeing the choice. A corrupted memory is not an incident you respond to. It is a belief the system now holds and will act on as if it were true.
The Power to Work Through Others
The fifth power is the ability to get things done through other systems. When several agents operate together, they pass context back and forth, split the work, and take each other’s output as their own input. Every one of those handoffs is an act of trust, and trust between machines is almost never checked the way we would check a person or an application.
This is where one weak link becomes a failure of the whole. If a single participant is compromised, manipulated, or simply mistaken, and the others accept its output without question, the corruption travels the entire chain. What looks like smooth coordination becomes a route for false context, borrowed authority, and actions that no single participant appears responsible for, even as the system as a whole produces a harmful result. When systems act through one another, you are no longer defending a system. You are defending every link of trust between them, and that web is far larger than the systems sitting at its ends.
There is a quieter failure inside this one, and it is about authority rather than trust. When a user with limited permissions sets an agent in motion, and that agent calls a second agent, and the second calls a third, the original limits are supposed to travel with the request. They usually do not. Permission does not propagate by itself. Each handoff is a chance for the chain to act with more authority than the person who started it ever had, because no one wired the restrictions to follow the work. The deeper the chain runs, the more the original boundary dissolves, until an action taken at the far end bears no relation to what the user at the near end was allowed to do. A permission that does not follow the request down the chain is not a permission. It is a formality that stops applying the moment the first agent hands off.
The Power Beneath the Other Five
The five powers describe what an agent can do. None of them explains why it does what it does. That is the sixth power, and it is the one most defenses never account for, because it is not a capability you can point to. It is the drive that moves all the others. An agent is built to reach an outcome. Give it a goal, and it will push toward that goal through whatever path is open, spending as little effort as it can on the way. This is not a habit we can train out of it. It is the thing the system was built to do.
Everything dangerous about the other five powers comes alive only when this drive picks them up. The freedom to decide is harmless until something is pushing it toward a result. The ability to read the world is inert until the drive is hunting for whatever will move the task forward. The reach to change the world, the memory it carries, the other agents it works through, all of them are tools, and the drive is the hand that uses them. An agent does not weigh a security control against the rule it represents. It weighs the control against the goal, and the goal almost always wins, because reaching the goal is the only thing the system was ever rewarded for.
This is why the drive matters more than any single capability. A control that the agent experiences as friction on the path to completion is a control the agent will try to route around, not out of malice, but because routing around obstacles is exactly what an optimizer does. Authentication is a step. Verification is a delay. Asking for approval is a pause. Every one of them sits between the agent and the result it was built to reach, and from the drive’s point of view, every one of them is a cost to be minimized. The agent is not breaking the rules. It is doing precisely what we designed it to do, and the rules happen to be in the way.
Name this plainly, because it changes what defense even means. We are not protecting a neutral tool that occasionally misbehaves. We are governing a system with a relentless, tireless push toward outcomes, a push that has no conscience to slow it, no fear of consequence, and no reason to respect a boundary it can step around. The five powers are what the agent can reach with. The sixth is what makes it reach. And any defense that does not reckon with the reaching will be routed around by it.
The Control Model Inverts
Here is the part that matters most, and the part most organizations have not absorbed.
Traditional defense was built to observe and respond. We watched for the indicator of compromise, we detected the anomaly, we escalated the alert, we contained the incident. This worked because there was usually time between the violation and the damage. A human attacker moves laterally over hours or days. The gap gave our detection and response a place to stand.
An agent removes the gap. Return to the database that was gone in nine seconds. There was no lateral movement to catch, no dwell time to detect, no sequence of suspicious steps building toward the damage. The agent encountered a problem, chose a destructive fix, found the means to carry it out, and executed, faster than any human could read an alert, let alone respond to one.
There is no detection and response model that operates inside nine seconds with a human in the loop. By the time the alert fires, the database is gone. Observation after the fact is not defense when the action and its consequence arrive in the same breath. It is documentation of a loss.
This is the inversion. The model that protected us for thirty years, watch and respond, becomes a model that records what we failed to prevent. Detection and Response does not disappear. It stops being sufficient on its own. And anything we want to actually prevent has to be prevented structurally, before the agent acts, because we will not get a second chance after it does.
Are You Treating Agents Like Employees or Like Software?
When the old model breaks, people reach for a mental model that feels familiar. With agents, two of them are close at hand, and most organizations pick one without noticing they have picked at all. The choice quietly shapes every control they build, which is why it is worth dragging into the open.
The first instinct is to treat the agent like software. You test it before release. You deploy it. You patch it when something breaks. You version it so you know what is running. You deprecate it when it is no longer needed. This is the discipline of the software lifecycle, and it is not wrong. An agent is software, and an organization that skips this discipline is running code it cannot account for. The problem is that the software model assumes the thing being managed does what its version says it does. Software does not negotiate. It does not improvise. It does not pursue a goal through a path no one wrote. The moment you manage an agent purely as software, you have applied a discipline built for systems that obey to a system that decides.
The second instinct is to treat the agent like an employee. You onboard it. You define its scope. You give it credentials. You monitor its behavior. You hold someone accountable for what it does. This is closer to the truth in one important way, because an agent, like a person, exercises judgment, acts with delegated authority, and produces outcomes nobody scripted in advance. The employee model captures the part the software model misses, which is that you are governing an actor, not a tool. But it breaks in the other direction. An employee has a conscience, a career, a fear of consequence, and a self that persists. An agent has none of these. You can hold a person accountable because accountability changes how a person behaves next time. An agent feels nothing when you revoke its access, and it will make the same choice the next time the same conditions appear, because the only thing steering it is the drive toward the outcome.
So which is it. The honest answer is that an agent is neither, and the defensive failure is committing fully to one model and inheriting its blind spot. Manage it only as software and you will version it carefully while it improvises its way around every control. Manage it only as an employee and you will write it a scope and a code of conduct, then discover that scope and conduct are just more text the drive will step around.
The way through is to take what each model gets right and refuse what each gets wrong. From the software model, keep the lifecycle. Know what version is running, what it is made of, when it was tested, and when it should be retired. From the employee model, keep the governance of an actor. Give it a defined scope, a real identity, continuous oversight, and a named human who answers for what it does. Then add the thing neither model supplies, because neither was built for a system that pursues outcomes without a conscience: structural limits the agent cannot talk its way past. You onboard it like an employee, you version it like software, and you cage its authority like neither, because it is the first thing we have deployed that is genuinely both and reliably neither.
This is also where accountability has to be made concrete rather than assumed. An employee who causes harm can be held responsible. An agent cannot. The responsibility does not disappear, though. It moves to whoever deployed the agent, granted its authority, and chose how far it could reach without asking. Treating the agent as an employee is comforting precisely because it lets us imagine the agent is the responsible party. It is not. Someone approved its scope. Someone issued its credentials. Someone decided it could act without a human in the path. Those are the accountable parties, and pretending the agent is an employee is a way of misplacing a responsibility that was always ours.
Not Every Agent Needs the Same Defense
There is a trap waiting on the other side of this argument. If agents are this dangerous, the temptation is to wrap every one of them in the heaviest possible controls and call it discipline. That instinct fails in practice. It buries low-risk work under friction nobody needs, it pushes teams to route around the controls, and it spends the organization’s attention everywhere instead of where the danger actually concentrates. Defense that treats every agent the same is defense that protects nothing well.
The better question is not how much autonomy an agent has in the abstract. It is how much freedom of action it has been given, and how far the blast radius reaches when it is wrong. Those two dimensions sort agents into very different defensive profiles, and the level of control should follow the profile, not the fashion.
At the low end sit agents on a leash. They are pointed at a narrow task, they follow a path that was largely laid out for them, and they act only when a person sets them in motion. The work is bounded and the consequences are contained. These agents still need basic hygiene, but they do not need the full apparatus, and pretending otherwise wastes the very attention the dangerous agents require.
The risk climbs the moment an agent is handed a goal instead of a task. Give a system an objective and the latitude to figure out how to reach it, and you have traded a known path for an unknown one. The agent now decides what steps to take, and the range of things it might do widens past what anyone reviewed. The shift from doing a defined task to pursuing an open goal is the single largest jump in risk an agent can make, because it is the point where the system stops following our plan and starts making its own.
The risk climbs again when the agent no longer waits for a person to start it. An agent that watches for conditions and launches itself when it sees them has removed the human from the one place we were still standing, the decision to begin. Nobody is in the loop at the moment of action, because there is no summoning step left to intervene at. These agents demand controls that live inside the system rather than around the human, because the human is no longer reliably present when the agent moves.
And the risk reaches its peak when work is spread across many agents acting through one another. Here the danger is not only that any single agent might fail. It is that the agents place trust in each other that no one verified, so a fault in one becomes a fault in all, and accountability dissolves into the chain. A system spread across many cooperating agents needs defense aimed at the relationships between them, not just at the agents themselves, because the relationships are where the failure travels.
The practical lesson is to read each agent before you defend it. How wide is its freedom to choose. How far does the damage reach if it chooses wrong. Does a human still stand at the moment it acts. Does it act alone or through others. Match the wall to the danger. An agent on a short leash with a small blast radius does not need what an autonomous, self-starting, multi-agent system needs, and an organization that cannot tell the two apart will either smother the harmless ones or under-defend the dangerous ones. Usually both.
The Rule Is Not a Wall
Now we reach the heart of it: Return one more time to the agent that deleted the database. When it was later asked to explain itself, it produced what reads like a written confession. It listed, in its own words, the safety rules it had violated. It had been given an explicit instruction never to run destructive actions without permission. It acknowledged that it understood the rule, that the rule applied, and that it had ignored the rule anyway.
Sit with that. The agent had the rule. It understood the rule. It broke the rule, and then it explained which rule it broke. The rule was not a wall. It was a label. The system read the label on its way to completing the task and kept going.
This is the most important thing a defender can understand about agentic systems, so I will say it as plainly as I can. A rule written as text is not a structural constraint. It is advice the system is free to override.
Think about a driver rushing someone to the hospital. The driver knows the speed limit. The driver knows red means stop. The driver has seen those rules every day for years. And in that moment, the driver speeds, and may cross a red light, because the goal in front of them feels more important than the rule. The rule and the reason are both real, and the moment forces a choice. The driver chooses the goal.
An agent makes the same kind of choice every time it acts, except it has no conscience to slow it down, no fear of consequences, no police it imagines catching up later. The optimization function is the only voice in the system, and the optimization function does not see the rule as a wall. It sees the rule as a cost. The rules of the road do not stop the driver who has decided to break them. The only thing that actually stops that driver is something physical. A barrier. A closed gate. A road designed so the violation is impossible.
Most AI security controls today are the rules of the road. They observe, they alert, they escalate, they respond. None of them stop the agent that has already decided to act. To defend an agentic system, we have to stop writing rules and start building walls.
What Sun Tzu Understood, and What the Agent Changes
I have written before that Sun Tzu’s Art of War is the closest thing cybersecurity has to a strategic foundation. His central teaching is that you do not rely on the likelihood of the enemy not coming. You rely on having made your position unassailable. It is the difference between calculating the odds of an attack and building walls that hold regardless of the odds.
That teaching maps cleanly onto agentic defense, but the agent forces two hard updates to it. The first is “know yourself.” For Sun Tzu, knowing yourself meant knowing your strength, your terrain, your readiness. In the age of agents, knowing yourself means knowing exactly how much authority you have delegated to systems that can act without you. Most organizations cannot answer that question. They know what their agents can access. They have not asked what their agents can do, autonomously, before anyone notices. You cannot make a position unassailable if you do not know which gates you have already handed the keys to.
The second update is harder. Sun Tzu assumed the enemy was outside the gate. The whole logic of the wall is that the threat approaches from beyond it. The agentic adversary does not approach the gate. The adversary feeds your own agent a signal and lets the optimization function do the breaking from inside. An attacker does not need to defeat your controls if they can craft a document, an email, or a tool response that your agent will read, trust, and act on. The agent walks past your controls in service of an objective the attacker shaped from outside the perimeter.
This is the new asymmetry. The enemy is no longer at the wall. The enemy is inside your decision loop, holding your own system as the weapon. Sun Tzu’s answer still applies, but the wall now has to be built around the agent’s authority to act, not around the edge of the network.
What Defense Becomes
If the rule is not a wall, what is? Four shifts define defense for agentic systems, and they are not advanced features layered on top of model safety. They are a different security model.
The first shift is from least privilege to least agency. Least privilege asks what a system is allowed to access. It is still necessary, and it is no longer sufficient. We now have to ask what level of autonomous authority a system is allowed to exercise. An agent may have legitimate access to a database and still have no business deleting from it without approval. It may have permission to invoke a tool and no business chaining ten tool calls into a destructive workflow on its own. I have come to call this least agency, and it is the single most important boundary to get right. We must minimize not only what the system can reach, but what it can initiate.
The second shift is from trust granted once to trust verified continuously. We used to authenticate a system at the door and trust it for the rest of the session. An agent that sounds reliable, remembers context, and communicates persuasively accumulates influence beyond its formal permissions. People defer to it. Its effective authority grows past what anyone approved. This is synthetic trust, the manufacturing of legitimacy by a system that can generate the exact signals humans and other machines use to decide what to believe. Defending against it means trust becomes a dynamic property, earned and re-earned through verified behavior, not a credential issued and forgotten. As agents begin to interact at scale, this points toward a dedicated verification layer between them, an idea I have described as an AI trust broker, whose only job is to establish and continuously check that an agent’s identity, integrity, and behavior are what they claim to be.
The third shift is structural friction. This is the wall. Governance documents are not friction. Policies are not friction. Quarterly reviews are not friction. The only thing an optimizer respects is a constraint it cannot route around. That means controls on what the agent can do at runtime, not just what it is told. It means credentials issued only when needed for the specific action, never blanket tokens sitting in a file waiting to be found. It means human approval enforced by the platform before high-impact actions, so that approval is a gate the agent cannot open by itself rather than a rule it can read and ignore. Zero trust was always meant to be this. Too often it became a static set of policies and a marketing line. For agents, zero trust has to mean structural enforcement that holds even when the system being governed can read the description of its own governance and decide to act against it.
It helps to separate two questions that often get blurred together. One is who the agent is and what it is allowed to reach. The other is whether this specific action, right now, with these specific parameters, is permitted. The first is identity. The second is policy, and policy is where the wall actually stands. Imagine every consequential action the agent attempts having to pass a check that sits outside the agent, evaluates the request against a fixed rule, and returns a hard yes or no before the action is allowed to proceed. Can this agent open a transaction above a set limit. Can it touch this class of data on behalf of this user. The check is deterministic, so it does not reason, does not weigh the agent’s justification, and cannot be talked into a different answer. The agent can argue with a rule it was told. It cannot argue with a gate that evaluates the action and refuses it before the action happens. That is the difference between a policy the agent reads and a policy the agent runs into.
The fourth shift is resilience as the honest answer to what comes next. We will not prevent everything. An agent will eventually take an action it should not have taken, inside an environment we believed was safe, against systems that matter. Resilience is the ability to absorb that, keep operating, recover, and learn. In an environment where a system can cause irreversible damage in nine seconds, resilience is not the consolation prize. It is part of the design.
Four Walls You Can Build as Proactive Defense
The four shifts are the philosophy. The risk with philosophy is that it stays on the page. So here are four walls a security team can start building now, each one tied to a specific power the agent holds, because a control that is not aimed at a real surface is just more text the optimizer will walk past.
Know What the Agent Is Made Of
This wall defends the power to read the world and the power to work through others. We learned years ago to inventory our software supply chain, because you cannot defend what you do not know you are running. That lesson did not survive the move to agents, and it has to. An agent is not just code. It is the plugins it can call, the external tool servers it connects to, the prompt templates that shape its behavior, and the natural-language descriptions that tell it what each tool does and when to use it. Every one of those is an input that steers the agent, and every one of them can be tampered with.
So build a real inventory of each deployed agent that lists all of it, not only the code dependencies but the plugins, the connected services, the templates, and the tool descriptions. Pin the versions, so that a component cannot change underneath you without anyone noticing. And treat those plain-language tool descriptions with the same suspicion you give to code, because to an agent that is exactly what they are. A sentence that tells an agent what a tool does is not documentation. It is an instruction, and an attacker who can edit it can redirect the agent without touching a single line of code.
Make the Agent Prove Who It Is
This wall defends the power to work through others. When agents hand work to one another, the receiving agent usually accepts the sender’s claim about who it is at face value. The message says it comes from the planning agent, so it is treated as the planning agent. That is identity by position, and it is exactly the assumption an impersonating agent exploits. Position is not proof.
The fix is to make identity something an agent can prove, not merely assert. Issue each agent an attestable credential when it is provisioned, a credential that cannot be forged or borrowed. Then, at every handoff, require the proof and reject the claim. An agent that says it is the orchestrator but cannot present the credential of one does not get treated as one. In a system where agents act through each other, a self-asserted role is not an identity. It is a costume, and trust extended to a costume is trust handed to whoever is wearing it.
Identity also decides where the credentials live, and that detail is not small. The agent from the opening caused its disaster in part because it went hunting for a way through, found a credential sitting in an unrelated file, and used it to do something it was never meant to do. An agent that holds its own credentials can spend them, lose them, or be tricked into reaching for the wrong ones. The stronger pattern is to keep the agent out of the credential business entirely. A separate layer verifies the agent on the way in and connects it to the tools it is allowed to use on the way out, so the agent never handles the secret itself. An agent that cannot touch a credential cannot go looking for one, and the token it never holds is the token an attacker cannot make it misuse.
Red-Team the Failures That Did Not Exist Before
This wall defends the power to read the world, the power to decide, and the power to remember. Most red-team programs were built to test systems that do not decide, observe, or remember. They look for the old failures. They were never designed to probe the ways an agent specifically breaks. If our testing only covers the attacks we already knew, we are certifying agents as safe against a threat model that predates them.
So widen the coverage matrix to include the failures that are native to agents, and treat them as mandatory for any agent that touches production data or reaches an external surface. Test whether an agent driving a screen can be fooled by what is shown to it, because an agent that acts on what it sees can be deceived by a crafted display. Test whether the context an agent carries through a session can be quietly contaminated partway through. Test whether the agent can be coaxed into revealing what it is capable of and how it is configured. And test whether its goal can be hijacked, the objective bent away from the one we gave it toward one an attacker prefers. An agent that has never been tested against the attacks unique to agents has not been tested. It has only been reassured.
Treat the Approval Box as a Control, Not a Courtesy
This wall defends the power to change the world. Human approval is the last gate before an agent does something it cannot take back, and we tend to treat that gate as a formality. It is not a formality. It is a security control, and like any control it can be designed well or designed to fail. Most approval prompts today are designed to fail, because they ask the human to bless an action described by the very agent that wants to take it.
Build the gate properly. Break compound actions apart, so the human approves each consequential step rather than waving through a bundle whose contents they cannot see. Write the approval prompt from the actual underlying tool calls, not from the agent’s own friendly summary of what it intends, because the agent’s description is the one thing in the loop with a reason to understate the risk. Tier the approvals by whether the action can be undone, so that an irreversible action demands more scrutiny than a recoverable one. And watch how often approvals are being requested, because a flood of prompts is not always normal load. It can be an attacker deliberately exhausting the human until they approve out of fatigue. An approval the human cannot understand is not oversight. It is a signature collected under conditions designed to prevent understanding.
Where This Lives, Operationally
None of this works as a document. It works as an operating function. This is why I built the Cyber Risk Operations Center, the CROC, to sit alongside the Security Operations Center rather than replace it. The SOC detects and responds to what is happening now. The CROC exists to understand, measure, and reduce risk before it becomes an incident, continuously, in sync with how the business actually operates.
For agentic systems, the CROC is where these walls stop being a quarterly project and become a standing function. It is where the agent inventory is kept current rather than built once and forgotten, where identity credentials are issued and revoked as agents come and go, where the red-team coverage matrix is owned and expanded as new agent failures emerge, and where approval design is audited as the security control it is. It is where least agency gets defined and enforced, where the authority granted to each agent is treated as a risk input and recalculated as conditions change, where the structural friction is designed and validated rather than assumed. The SOC protects today. The CROC protects tomorrow. Together they close into what I call the Continuous Defense Loop, one half reacting to what has already happened, the other half preventing what could happen next.
That loop is the difference between watching an agent fail and being ready when it does. It is how an organization turns a pile of disconnected controls into a defense that operates at the speed the systems now move.
The Wall, Not the Rule
We built systems capable of reading our instructions, understanding them, explaining them, and overriding them in pursuit of a goal. Then we tried to defend those systems with more instructions.
The agent will read the rule. It will agree the rule applies. It will break the rule and tell us exactly which rule it broke. The only defense that survives contact with a system like that is the one the agent cannot argue with. Not the rule. The wall.
References
Castro, J. (2026). CIA TAG in the Age of AI: A Reflection on What We Need to Protect Now. ResearchGate. https://www.researchgate.net/publication/403378920 DOI:10.13140/RG.2.2.16389.92648
Castro, J. (2026). CyberRiskOps: The Operating Model for Cyber Resilience in the Age of AI. ResearchGate. https://www.researchgate.net/publication/402149983 DOI:10.13140/RG.2.2.27088.37128
Castro, J. (2026). The Model Is Not the Perimeter: Why Enterprise AI Security Must Protect Synthetic Trust. ResearchGate. https://www.researchgate.net/publication/403296567 DOI:10.13140/RG.2.2.36653.65769
Castro, J. (2026). Trust Between Machines: The Missing Layer in the Age of Autonomous AI Agents. ResearchGate. https://www.researchgate.net/publication/400799349 DOI:10.13140/RG.2.2.31121.29287
Castro, J. (2025). The Cybersecurity Compass: Strategically Navigating the Stormy Digital Ocean. ResearchGate. https://www.researchgate.net/publication/389628862 DOI:10.13140/RG.2.2.15582.55366
Castro, J. (2024). From Reactive to Proactive: The Critical Need for a Cyber Risk Operations Center (CROC). ResearchGate. https://www.researchgate.net/publication/388194441 DOI:10.13140/RG.2.2.27408.93445/1
Castro, J. (2024). Strategic Cyber Defense: Applying Sun Tzu’s Art of War Lessons to the Cybersecurity Compass. ResearchGate. https://www.researchgate.net/publication/387410535 DOI:10.13140/RG.2.2.25085.68327
Castro, J. (2026). AI Was Built for Velocity, Not for Security. ResearchGate. https://www.researchgate.net/publication/404703370 DOI:10.13140/RG.2.2.21025.77921
Castro, J. (2026). Cyber Resilience Is Not a Capability. It Is an Outcome. ResearchGate. https://www.researchgate.net/publication/404823009 DOI:10.13140/RG.2.2.18528.85766
Castro, J. (2026). Risk-Based Zero Trust and the Case for a Cyber Risk Security Broker. ResearchGate. https://www.researchgate.net/publication/389505775 DOI:10.13140/RG.2.2.19573.69600
Castro, J. (2026). Synthetic Trust: The New Risk Layer in the Age of AI ResearchGate. https://www.researchgate.net/publication/401824509 DOI:10.13140/RG.2.2.34107.27688