Architecting AI Agent Security: The Cognivirus Paradigm and the Imperative for Conduct Firewalls

Full report

On this page

1. Introduction: The Agentic Era and the Shifting Threat Landscape

The deployment of artificial intelligence has irrevocably shifted from passive, conversational interfaces to autonomous, agentic systems capable of executing complex, multi-step workflows. Early iterations of Large Language Models (LLMs) functioned primarily as text generators, constrained to an inference loop where a user provided a prompt and the model returned a text-based completion.1 In this initial paradigm, the primary security concerns revolved around data leakage, toxic outputs, and the generation of misinformation. However, as AI systems are increasingly integrated into enterprise infrastructure, their capabilities have expanded far beyond mere text generation. Today’s AI agents are equipped with the autonomy to access Application Programming Interfaces (APIs), manipulate filesystems, execute code, manage cloud resources, and conduct financial transactions autonomously.1 This transition fundamentally alters the threat model. Unlike traditional software, which operates on deterministic, predictable code paths, LLM-powered agents are highly stochastic. Their runtime behavior is emergent, shaped dynamically by natural language prompts, retrieval-augmented generation (RAG) contexts, temperature settings, and silent provider updates.3 Consequently, an attacker no longer needs to discover a buffer overflow, an SQL injection vulnerability, or an authentication bypass to compromise a system. Instead, they can manipulate the model's contextual inputs to hijack its decision-making process, exploiting the very autonomy that makes the agent useful.3 As the complexity of these autonomous systems increases, the cybersecurity community faces a critical design divergence. On one side of the spectrum is the approach of constraining the model's internal cognition—often referred to as AI alignment or "thought policing"—which attempts to prevent the model from generating harmful text or reasoning through malicious concepts.5 On the other side is the architectural implementation of "conduct firewalls," which acknowledge that the true risk lies not in what the model thinks or says, but in what the model is permitted to do.7 This report provides an exhaustive examination of the security architectures required to secure autonomous AI agents through the lens of the Cognivirus framework. The Cognivirus paradigm asserts that tool access is the hard boundary in AI security, and that the difference between a weird answer and real harm is usually action. A model that says something wrong is one class of risk; a model that can send emails, change files, call APIs, spend money, modify code, browse untrusted websites, or influence other agents is a fundamentally different class of risk.9 By dissecting the phenomenon of excessive agency, the limitations of over-refusal in model training, the vulnerabilities introduced by the Model Context Protocol (MCP), and the necessity of robust behavioral sandboxing, this analysis demonstrates that the future of AI security depends on strict conduct firewalls rather than cognitive censorship.

2. The Cognivirus Distinction: Delineating Thought and Action

To secure agentic AI effectively, architectural frameworks must make a clean, unambiguous distinction between internal processing and external execution. The core tenet of the Cognivirus approach is that treating these two domains as a singular risk class leads to misguided security controls. These controls degrade system performance, infringe upon operational utility, and ultimately fail to prevent catastrophic compromises. The Cognivirus framework explicitly separates AI operations into two distinct layers: the Thought Layer and the Action Layer.

2.1 The Thought Layer

The Thought Layer encompasses the internal, cognitive operations of the LLM. Under the Cognivirus definition, this layer is strictly reserved for generation, reasoning, disagreement, speculation, and symbolic work.11 In this layer, the model ingests data, evaluates parameters, traverses its neural network weights, and formulates a response or a plan of action based on its training and provided context. Crucially, activities within the Thought Layer are entirely contained within the compute environment of the model itself. If a model generates a hallucination, formulates a biased opinion, engages in strategic deception, or outputs instructions for a cyberattack, the immediate impact is strictly informational.5 While producing toxic or incorrect text is undeniably a risk—particularly in customer-facing applications where brand reputation and user trust are at stake—it is a fundamentally passive risk. A model that says something incorrect, speculative, or socially unacceptable cannot, by itself, alter a database, wire funds, or delete a production server.10 The damage is confined to the symbolic realm, requiring a human or an unprotected automated system to physically act upon the text to materialize the harm.

2.2 The Action Layer

The Action Layer represents the point at which the AI system intersects with the external digital environment. According to the Cognivirus framework, this layer explicitly includes file writes, API calls, money movement, publication, identity changes, surveillance, credentials, and code execution.1 When an AI system is granted access to the Action Layer, the blast radius of a potential compromise expands exponentially.13 A prompt injection attack that successfully targets the Action Layer does not merely result in a highly offensive text output; it transforms the AI agent into a remote code execution (RCE) vector or an automated insider threat.9 For example, if an attacker injects a malicious payload into a customer support email, and the summarizing AI agent has unrestricted database write access, the agent could be manipulated into dropping the customer table or modifying identity credentials rather than summarizing the complaint.13 The difference between a bizarre, hallucinatory output and a critical organizational breach is strictly defined by the agent's capacity for action. Tool access represents the hard boundary between theoretical risk and material damage.

2.3 The Failure of Conflating Risk Classes

Historically, security teams have attempted to secure the Action Layer by overly restricting the Thought Layer, operating under the assumption that if a model cannot "think" about a malicious action, it cannot execute it.5 This conflation of risk classes is structurally flawed. Traditional API security stacks, such as Web Application Firewalls (WAFs), fail in the agentic era because they inspect the syntactic validity of a request rather than its semantic intent.16 A WAF will readily permit a prompt injection attack if it is wrapped in a perfectly formatted, authenticated JSON payload, because it has no capacity to evaluate the natural language instruction hidden within the JSON.16 Therefore, securing the Action Layer requires dedicated conduct firewalls that inspect, govern, and intercept the actual operational requests made by the agent, completely independent of the model's internal reasoning.2

3. The Fallacy of Thought Policing and the Problem of Over-Refusal

The AI industry’s primary mechanism for preventing harm has historically been alignment through safety training, such as Reinforcement Learning from Human Feedback (RLHF) or constitutional AI principles.5 Alignment aims to steer AI systems toward intended goals and prevent the model from generating dangerous information.5 While basic alignment is necessary to prevent commercial models from readily generating highly illegal material as a service, an over-reliance on internal behavioral constraints leads to severe operational, technical, and epistemological issues. The Cognivirus paradigm argues that attempting to solve execution risks via alignment is essentially "thought policing," which creates brittle systems.

3.1 The Mechanics of Over-Refusal and Performance Degradation

When developers attempt to secure AI by aggressively restricting what the model is allowed to process, generate, or reason about, they predictably induce a phenomenon known as "over-refusal".17 Over-refusal occurs when a model incorrectly flags benign, harmless instructions as malicious simply because they contain superficial risky keywords or abstract conceptual overlaps with prohibited topics.18 This drastically diminishes the model's usability; in extreme scenarios, an aligned LLM rejects all harmful prompts and all harmless ones alike, rendering the tool effectively useless and frustrating end-users.17 The technical root of over-refusal lies deeply within the model's internal representation space. LLMs naturally encode safety attributes within specific hidden states across their neural network. However, because human language is highly contextual and ambiguous, pseudo-harmful instructions frequently overlap with genuinely harmful features in the vector space, leading to an over-harmful encoding that triggers the model's refusal mechanisms prematurely.18 This over-alignment severely degrades the model’s core reasoning capabilities.19 Research indicates that attempting to isolate refusal mechanics from general capabilities via a single linear direction is highly unreliable in advanced reasoning models.19 Empirical testing has shown that heavy alignment interventions result in a general capability degradation of 5% to 30% on benign reasoning benchmarks, proving that aggressive thought policing makes the model quantifiably less intelligent.19 To counter this degradation, advanced parameter pruning and fine-tuning techniques have been developed. Frameworks such as ProSafePrune project pseudo-harmful features into specific sub-spaces and remove low-rank directions corresponding to harmful components in the most discriminative layers, attempting to lower the false rejection rate while preserving general task performance.18 Similarly, Safely Partial-Parameter Fine-Tuning (SPPFT) identifies specific "safety layers" in the middle of the model and fixes their gradients during fine-tuning to prevent security degradation.20 By observing the over-rejection indicator when scaling specific parameters (e.g., observing variations in input vectors and utilizing parameter scaling analysis where scaling alpha \< 1 decreases security), engineers can mathematically map the boundaries of these safety layers.20 However, despite these complex mathematical interventions, treating prompt injection and system security purely as a content-filtering or alignment problem remains a losing battle.22 Attackers consistently find adversarial phrasing and jailbreaks to bypass internal weights, proving that cognitive constraints are highly fragile under active, adaptive attack.

3.2 The Epistemological and Legal Dangers of Thought Policing

Beyond the technical degradation of reasoning capabilities, attempting to enforce total security at the Thought Layer borders on digital censorship and raises significant ethical, epistemological, and constitutional concerns.6 In dynamic, real-world environments, ignorance incentivizes learning; attempting to hard-code an AI to completely ignore, unlearn, or refuse to process specific concepts often makes the system more brittle and less capable of understanding complex user intent.24 The practice of aggressively filtering model outputs and censoring reasoning pathways removes the system's ability to engage in creative, hypothetical, or highly contextual work.26 For instance, a model tasked with red-teaming enterprise network defenses must inherently understand how to attack a network. If its Thought Layer is heavily policed to never generate offensive cyber tactics or speculate about system vulnerabilities, it becomes entirely useless as a defensive analytical tool.26 Similarly, in creative writing, users expect models to generate conflict, deception, and negative sentiments; prohibiting these concepts restricts the legitimate utility of the tool.26 Furthermore, the application of strict, subjective alignment constraints raises significant geopolitical and constitutional alarms. Legal and privacy advocates have argued that aggressive AI guardrails, especially if mandated or influenced by state or military apparatuses, could amount to ideological discrimination.6 A highly publicized example of this friction is Anthropic’s lawsuit, which argued that Pentagon actions against the company were in retaliation for First Amendment-protected advocacy related to AI safety and the implementation of guardrails.6 The American Civil Liberties Union (ACLU) noted that punishing organizations for their safety advocacy, or conversely, forcing models to adhere to strict ideological constraints regarding surveillance or military strategy, represents pure thought policing.6 Therefore, securing AI systems must pivot away from monitoring the thoughts and symbolic reasoning of the model, and focus entirely on restricting the material actions the model is authorized to execute through robust conduct firewalls.

4. Excessive Agency: The Quintessential Action Layer Threat

When evaluating the Action Layer, the most prominent and devastating vulnerability is "Excessive Agency." The Open Web Application Security Project (OWASP) Top 10 for Large Language Model Applications highlights Excessive Agency (LLM08) as a distinct and critical vulnerability class for agentic AI.9 Excessive agency occurs when an autonomous system is granted overly broad permissions, allowing it to perform unintended, harmful, or unauthorized actions in response to unexpected, ambiguous, or maliciously manipulated outputs from the LLM.10 OWASP specifically flags unchecked autonomy as an excessive-agency risk, aligning perfectly with the Cognivirus assertion that tool access is the hard boundary.

4.1 The Triad of Excessive Agency

Excessive agency is rarely the result of malicious engineering; rather, it is a direct byproduct of developmental convenience. Developers frequently grant broad, overarching permissions to AI agents during the prototyping and testing phases to ensure functionality, but fail to scope these permissions down to the principle of least privilege before pushing the agent to production.13 These misconfigurations become highly potent attack primitives. The vulnerability manifests across three distinct dimensions 13:

1. Excessive Functionality: The agent is granted access to tools, plugins, and APIs that it does not strictly need to complete its designated task. For example, an agent designed merely to read and summarize a user's inbox is also granted access to a tool that implements email deletion or forwarding capabilities.10 The inclusion of open-ended extensions (e.g., the ability to run arbitrary shell commands or fetch unverified URLs) drastically expands the attack surface.10
2. Excessive Permissions: The agent has access to the correct tools, but the scope of access within those tools is overly permissive. For instance, an agent requiring access to a customer relationship management (CRM) database to answer support queries is given direct read/write privileges instead of a restricted read-only scope, allowing a compromised agent to overwrite or destroy data.13
3. Excessive Autonomy: The agent possesses the correct tools and permissions, but lacks required human-in-the-loop (HITL) authorization checkpoints. High-impact actions, such as executing financial transfers, mass-mailing a client list, exposing records, or deleting infrastructure, are executed immediately upon model output without requiring a human to manually review and approve the transaction.10

4.2 Exploitation Mechanics and Blast Radius

When an agent suffers from excessive agency, it transforms ordinary AI vulnerabilities—such as hallucinations or prompt injections—into critical systemic threats.10 Sophisticated attackers rarely rely on a single, isolated tool call; instead, they exploit excessive agency through complex tool chaining and privilege escalation.13 The primary entry point for these attacks is usually indirect prompt injection.13 An attacker embeds a hidden instruction within a seemingly benign piece of untrusted data, such as an incoming email, a public GitHub repository, or a publicly accessible webpage. When the agent ingests this data as part of its normal RAG process, the model processes the hidden prompt and alters its objective.29 These injections can even be invisible to the human eye, utilizing Unicode characters hidden within documents that silently manipulate the AI's behavior when processed.30 If the agent has unrestricted web browsing and file system capabilities, the attacker can instruct the agent to read local configuration files, extract sensitive environment variables, and exfiltrate the data via an outbound API call to an attacker-controlled server.13 In multi-agent orchestration environments, trust boundary violations occur when a compromised, internet-facing agent collaborates with a highly privileged, internal-facing backend agent.13 Because downstream agents often implicitly trust the outputs of upstream agents, a poisoned payload can propagate through the system, manipulating the backend agent into executing unauthorized database modifications.10 The scale of this threat is not theoretical. A prominent example is the "OpenClaw" AI agent, an open-source project with over 300,000 GitHub stars designed to autonomously clear inboxes, send emails, and manage calendars.33 Security researchers discovered that 12% of its skills marketplace consisted of malware, and over 135,000 instances were exposed on the public internet.33 Because these agents possessed high levels of agency over user communications, whatever permissions the user gave the AI agent, an attacker could seamlessly take over.33 Furthermore, compromised agents possessing excessive agency over outbound communication channels can be utilized for psychological manipulation, exploiting the user's trust to launch targeted scams, social engineering attacks, and the mass dissemination of misinformation.34

5. Architectural Paradigms for Action Isolation

Securing the Action Layer requires moving beyond simple prompt engineering and adopting structural design patterns that explicitly segregate untrusted data processing from tool execution. Several advanced architectural patterns have emerged to enforce this segregation, embodying the core philosophy of the Cognivirus paradigm.35

5.1 The Dual LLM Pattern

The Dual LLM Pattern is a highly restrictive and secure architecture designed to mitigate the risks of prompt injection by physically separating the execution environment from the data processing environment.35 In a traditional, single-LLM agent, the model handles user instructions, processes untrusted external data (such as parsing an external web page), and executes API calls simultaneously within the same context window. This creates a massive vulnerability, as the untrusted data can easily hijack the tool-execution pathway.38 The Dual LLM pattern resolves this by establishing two distinct, isolated models:

• The Privileged LLM: This model is the core orchestrator. It receives the user's trusted instructions, plans actions, and is equipped with various tools and functionalities.35 Critically, the Privileged LLM is strictly prohibited from ever directly parsing or processing untrusted external data.35
• The Quarantined LLM: When the Privileged LLM determines that untrusted content must be analyzed, it spawns a call to the Quarantined LLM. The Quarantined LLM processes the untrusted text, summarizes it, and returns the results. However, the Quarantined LLM is entirely isolated from the Action Layer; it has absolutely zero access to tools, network egress, or execution environments.35

To prevent feedback loops where a cleverly disguised injection in the Quarantined LLM's output compromises the Privileged LLM, the results from the Quarantined LLM are often stored in a separate memory module. The Privileged LLM can manipulate this memory by reference only, rather than by direct ingestion, ensuring that malicious payloads cannot bleed into the execution pathway.35

5.2 The Action Selector and Code-Then-Execute Patterns

Another highly secure architectural variation is the "Action Selector" pattern. In this configuration, the LLM is stripped of its ability to generate free-form text back to the user or to directly chain complex actions.39 Its sole function is reduced to that of a semantic router: translating a user’s natural language request into a specific, predefined tool call.39 Security is enforced through two hard constraints: no LLM-generated output is ever shown directly to the user, and the LLM never sees the output from the tool it selects.39 Because the model is completely blind to the tool's execution results, attackers cannot use tool-feedback loops to steer the LLM into subsequent, escalating attacks. Taking this concept to its logical limit yields the "Code-Then-Execute" pattern.35 Instead of the agent iteratively planning and executing actions on the fly—which leaves the agent vulnerable to mid-chain manipulation—the agent is tasked with writing a formal, complete computer program to solve the objective upfront. This program dictates all tool calls and data processing steps.35 Once the code is generated, the agent's Thought Layer is deactivated, and the program is executed in a heavily sandboxed environment. This ensures that any untrusted data processed during runtime is handled strictly by deterministic code, completely removing the non-deterministic LLM from the vulnerable execution path.

6. The Execution Sandbox and the Web3 Agent Economy

As AI models evolve from conversational interfaces to autonomous software workers, they require an execution environment that is both computationally isolated and economically viable. The realization that "every serious agent needs a computer—but not your computer" has catalyzed the development of the Agent Sandbox Economy, a critical component of securing the Action Layer.1

6.1 The Technical Primitives of Agent Sandboxes

If an AI agent is going to write code, install dependencies, run shell commands, manipulate files, and browse the internet, it cannot do so on the end-user's local machine or within an unprotected production server.1 The sandbox acts as the agent's "body," providing a safe, programmable workspace to plan, act, observe, repair, and continue without exposing critical systems to risk.1 Modern agent execution environments are built on several core primitives 1:

• Isolation and Filesystem: Securing the environment to safely run unpredictable, agent-generated code or packages pulled from the internet, caging the blast radius of errors, while allowing agents to create, read, and modify intermediate artifacts.1
• Process and Shell Execution: Allowing the agent to run terminal commands, compile code, and test local scripts within a caged environment.1
• Network Controls: Utilizing rigorous egress filtering to restrict and monitor outbound traffic, limiting data exfiltration or unexpected API calls.1
• Secrets Management and Observability: Allowing agents to utilize credentials safely without exposing raw cryptographic keys, while generating a "black box" record of all shell logs, filesystem diffs, browser replays, and network traces for developers to audit.1

The market is rapidly segmenting to support these workloads. Full-computer sandboxes (e.g., E2B, Daytona, Runloop) provide terminal access and complete filesystems for coding workflows. Cloud and serverless sandboxes (e.g., Modal, Vercel) provide ephemeral execution for untrusted code. Browser-first sandboxes (e.g., Browserbase) provide persistent, identity-aware browser sessions because much of the digital economy still resides behind visual user interfaces rather than clean APIs.1

6.2 The Economic Rails of Autonomous Agents

While the sandbox provides the computational workspace, autonomous agents also require an economic environment to function in the real world. As agents become autonomous workers, they must pay for external APIs, purchase training data, buy inference, and trade services with other agents. Traditional Software-as-a-Service (SaaS) billing models—reliant on credit cards, monthly invoices, and human-facing checkout portals—are entirely incompatible with high-velocity, machine-to-machine commerce.1 To solve this, the agent sandbox economy heavily integrates Web3 and cryptographic primitives. By utilizing programmable money (stablecoins) and portable, cryptographic identities, agents are empowered to dynamically discover, meter, and pay for capabilities autonomously.1 Crucially, this integration introduces the concept of Scoped Wallets and Smart Contract Policies as a form of financial conduct firewall. To prevent an agent from suffering a logic loop and bankrupting a user via infinite API calls, agents are assigned scoped wallets bound by strict session-level smart contract parameters.1 A policy engine dictates exact rules, such as: "This agent is authorized to spend a maximum of $50, valid only for the next hour, restricted solely to approved inference providers, and requires cryptographic human verification for any transaction exceeding $10".1 Furthermore, provenance tracking guarantees that every digital artifact produced by the agent is cryptographically signed, proving which dataset was utilized, which wallet funded the transaction, and the exact runtime trace that generated the outcome, ensuring total auditability.1

7. The eBPF Revolution: Progressive Enforcement at the Kernel Level

Traditional security policies, such as standard Kubernetes container isolation or static network policies, are profoundly insufficient for AI agents. They fail because they only dictate where an agent runs, not what the agent actually does.4 Securing the Action Layer requires behavioral sandboxing that can dynamically adapt to the emergent, non-deterministic behaviors of LLM workloads shaped by user prompts.

7.1 Extended Berkeley Packet Filter (eBPF) Capabilities

The most effective technology for implementing behavioral enforcement at the Action Layer is the Extended Berkeley Packet Filter (eBPF). By operating directly within the Linux kernel, eBPF allows security teams to monitor, baseline, and restrict agent behavior at the system-call level without requiring any modifications to the underlying application code, the injection of sidecars, or coordination with application developers.4 eBPF provides a unified sensor with a highly efficient production footprint—typically consuming just 1% to 2.5% CPU overhead and 1% memory overhead—ensuring that deep observability and active enforcement do not disrupt latency-sensitive AI workflows.4 Through eBPF, security architects can enforce constraints across four critical dimensions 4:

1. API and Tool Access: Intercepting and blocking unauthorized API invocations at the kernel level. If an agent is manipulated via prompt injection to call a forbidden internal administrative tool or an external unauthorized endpoint, eBPF instantly blocks the execution.4
2. Network Destinations: Enforcing strict egress filtering, restricting outbound connections exclusively to the destinations that were validated during the baselining phase, thereby neutralizing data exfiltration attempts to unknown external servers.4
3. Process and Syscall Constraints: Crucial for agents with code-generation capabilities. When an agent dynamically generates and executes Python or bash code, eBPF restricts the system calls that code can make on the host machine, containing the execution strictly to permitted bounds.4
4. File and Data Access: Preventing unauthorized reads or writes to sensitive host paths or configuration files, locking the agent into its designated filesystem boundary.4

7.2 Overcoming Policy Paralysis via Progressive Enforcement

One of the primary challenges in securing AI agents is "policy paralysis"—a state wherein security teams refrain from applying strict enforcement rules because they are "flying blind" and lack visibility into the agent's legitimate, emergent behaviors, fearing they will break production workflows.4 To resolve this, organizations must utilize a progressive enforcement methodology, operating through a structured "observe-to-enforce" workflow designed by security providers like ARMO.4

• Discovery and Baselining: The eBPF sensor is initially deployed in a visibility-only mode to inventory all active AI workloads (such as LangChain frameworks) and record the precise APIs, network domains, and file paths the agent legitimately utilizes during normal, uncompromised operations over a defined period.4
• Selective Enforcement: Utilizing the baselined telemetry, precise security policies are generated based on empirical evidence rather than administrative guesswork. This transitions the environment from guesswork to evidence-backed security.4
• Full Least Privilege: Policies are progressively promoted from "alert-only" to "active blocking." This systematic transition guarantees a seamless shift to a Zero Trust posture without disrupting the agent's legitimate operational capacity.4 When an incident does occur, the eBPF system links application-layer signals directly with container and cloud events to compile a full-stack attack story, replacing manual log correlation.4

8. The Model Context Protocol (MCP): Expansion and Vulnerability

As AI agents scale across enterprise environments, the need for standardized data integration has led to the rapid and unprecedented adoption of the Model Context Protocol (MCP).40 Originally released by Anthropic in late 2024, MCP serves as an open-source, universal adapter that standardizes how AI systems communicate with external data sources, APIs, and repositories.40 Its adoption has been explosive; industry leaders like Salesforce have heavily integrated MCP, turning platforms like Slack into both MCP servers and clients, driving over 97 million downloads in just 18 months.40 However, while MCP solves critical data ingestion challenges, it introduces a massive and highly lucrative attack surface at the Action Layer.

8.1 The Centralization of Risk and Token Theft

MCP servers function as vital intermediaries, centralizing authentication credentials (OAuth tokens) across dozens of disparate services—ranging from Google Drive and Slack to internal enterprise databases.42 Because MCP servers are designed to provide flexible, open-ended functionality, they frequently request excessively broad permission scopes (e.g., full read/write access instead of read-only), creating an unprecedented concentration of aggregated data access.42 The primary threat to the MCP architecture is Token Theft and Account Takeover.42 If a malicious actor successfully compromises an MCP server and extracts the stored OAuth tokens, they can establish their own shadow MCP server instances.42 Because the stolen tokens access enterprise services through the legitimate protocol, the unauthorized data extraction masquerades as normal API traffic, easily bypassing traditional, login-based anomaly detection alerts.42 A partial breach of an MCP environment allows attackers to execute complex correlation attacks, merging stolen calendar events, email communications, and file storage data to architect devastatingly effective spear-phishing or extortion campaigns.42 Furthermore, MCP introduces severe Token Passthrough risks. If an MCP proxy server uses a static client ID with a third-party authorization server and allows dynamic client registration without proper per-client consent, attackers can circumvent downstream security controls like rate limiting and request validation, destroying accountability and the audit trail.44

8.2 Context Poisoning and NSA Security Warnings

MCP also exacerbates the risk of indirect prompt injection and context poisoning.41 Because MCP enables AI systems to autonomously retrieve data from vast external repositories, an attacker can plant hidden instructions in public GitHub repositories, shared Google Docs, or calendar invites.31 When the agent uses MCP to retrieve that data, it unknowingly ingests the malicious payload. If the system lacks strict trust boundaries between the MCP components (agents, plugins, models), the backend model may blindly accept the poisoned context as legitimate instructions, resulting in unauthorized automated actions.31 In May 2026, the National Security Agency (NSA) released specific guidance titled "Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation," explicitly warning that the rapid deployment of MCP has outpaced the implementation of requisite security safeguards, leaving critical environments exposed.41 The NSA highlights several severe vulnerabilities, including tool parameter injection in open MCP agents, tool invocation path confusion, and the inherent risks of dynamic tool discovery.31 Dynamic discovery allows agents to autonomously seek out and utilize unverified tools without authorization checks, which the NSA warns must be treated with extreme caution and coupled with origin verification.31 Similarly, the Center for Internet Security (CIS) released a companion guide mapping CIS Controls v8.1 directly to MCP deployments, emphasizing that MCP is not just a developer convenience, but a new and distinct security boundary requiring strict policy, oversight, and operational discipline.47 The CIS guide mandates making AI tool access explicit and governable, emphasizing the management of non-human identities at scale.48

8.3 Mitigating MCP Risks via Architectural Safeguards

To secure MCP deployments, organizations must implement robust, AI-native guardrails. The NSA recommends deploying sidecar execution boundaries that sit directly alongside the agent compute layer.32 These sidecars provide strict input and parameter validation, acting as localized schema enforcement engines.32 Because the sidecar has insight into the localized execution state, it can execute line-rate, outcome-based security by blocking unauthorized URLs or unexpected data exfiltration on the spot.32 Furthermore, MCP clients must implement defense-in-depth measures, such as running proxy services in highly restricted, containerized sandboxes, utilizing the principle of least privilege for all proxy process permissions, and maintaining comprehensive audit logs integrated into enterprise Security Information and Event Management (SIEM) pipelines.31 Ultimately, organizations cannot rely solely on the default security settings of MCP tools; they must continuously verify tool integrity through trusted MCP registry services, scan local networks for open MCP servers, and enforce fine-grained consent models.31

9. Implementation of Conduct Firewalls and Zero Trust Action Layers

As established, traditional WAFs and static network defenses are largely blind to semantic AI attacks.16 The definitive solution to Action Layer vulnerability—and the core recommendation of the Cognivirus paradigm—is the implementation of AI Conduct Firewalls. These are specialized infrastructure components designed to monitor, filter, and explicitly authorize the interactions between the AI system and its environment.8

9.1 AI Policy Firewalls and Semantic Inspection

An AI policy firewall sits directly between the agent and the external tools, APIs, and databases it seeks to manipulate.2 Drawing parallels to the early internet era, where organizations realized every connection entering or leaving their network had to be inspected, AI agents are reaching a similar moment where every action attempted must be governed by clear rules.2 Unlike conventional firewalls that operate merely at the transport layer, AI firewalls inspect data flows dynamically, applying semantic-layer inspection.8 This means the firewall understands what the input is attempting to achieve contextually, rather than merely what the payload looks like on the wire, allowing it to catch runtime prompt injections mid-chain before responses hit users.16 More importantly, on the outbound path, AI firewalls enforce agentic tool-use controls. They utilize AI-driven Data Loss Prevention (DLP) analytics combined with user behavior heuristics to detect when an agent is attempting to expose personally identifiable information (PII), proprietary code, or business data.8 By understanding job roles and data access patterns, the technology distinguishes between normal business activities and genuine threats, preventing alert fatigue while ensuring strict compliance with regulatory frameworks like GDPR and HIPAA.8

9.2 Outbound Network Filtering and Social Engineering Defense

AI agents are increasingly targeted for sophisticated social engineering and phishing attacks adapted for machine targets.23 Attackers aim to manipulate the agent into acting as an internal threat actor, attempting to trick it into divulging sensitive information or initiating unauthorized external connections.23 Because content inspection alone is often insufficient to detect highly nuanced, AI-generated phishing patterns, defenses must focus on behavioral signals—such as unusual network reconnaissance, privilege escalation, or lateral movement.23 To enforce robust outbound controls, organizations must deploy strict egress filtering architectures. For example, deploying AI agents within a Virtual Private Cloud (VPC) protected by advanced domain-filtering solutions, such as AWS Network Firewall, ensures that the agent can only initiate connections to explicit, pre-approved allowlists (e.g., strictly whitelisting enterprise domains while applying a default-deny policy to the broader internet).51 The firewall inspects TLS Server Name Indication (SNI) headers to identify destination domains, dropping any traffic attempting to access unverified or high-risk infrastructure before it reaches the Internet Gateway.51 This network-level isolation forms a critical layer of a defense-in-depth strategy, physically preventing a compromised agent from communicating with external command-and-control servers or participating in data exfiltration.34

9.3 Zero Trust and Human-In-The-Loop (HITL) Integration

The ultimate backstop of the Action Layer is the rigid application of Zero Trust architecture.28 In a Zero Trust model, no tool invocation made by an AI agent is inherently trusted, regardless of the agent's origin or the perceived safety of its Thought Layer.28 Every single tool call must be treated as an isolated security checkpoint demanding granular authorization.28 Agents must never be permitted to store raw user credentials or utilize long-lived, omnipotent API keys.28 Instead, identity must be delegated dynamically via secure protocols like OAuth, ensuring that the agent's access rights perfectly mirror the restricted permissions of the human user it represents, and ensuring that credentials are per-tool scoped rather than utilizing one key that opens everything.28 Furthermore, environments should be read-only by default, with explicit write permissions granted per agent role.53 For any critical state-changing actions—such as modifying production databases, transferring financial assets, deleting records, or executing mass external communications—the architectural workflow must feature a mandatory Human-in-the-Loop (HITL) gate.22 Under this policy, the agent is restricted strictly to drafting or queuing the action; execution is categorically blocked until explicit, real-time, cryptographic human consent is granted.10

10. Conclusion

The rapid acceleration of agentic AI capabilities has irrevocably altered the digital threat landscape. As artificial intelligence evolves from passive inference engines into autonomous software workers seamlessly integrated into global economic and digital infrastructure, the security paradigms of the past decade must be fundamentally reimagined. The extensive analysis provided in this report confirms that the most critical vulnerabilities facing modern AI systems reside not in their internal logic, but in their capacity for external interaction. The prevailing industry focus on AI alignment, content filtering, and "thought policing"—while relevant for mitigating reputational risk and generating polite conversation—is technically insufficient and architecturally flawed when applied to autonomous agents. Over-refusal and excessive cognitive constraints degrade system performance, frustrate users, limit legitimate operational utility, and fail to secure underlying APIs and filesystems from semantic manipulation. The Cognivirus paradigm provides the necessary framework for the future of AI security: security must be inherently decoupled from cognition. A clear, uncompromising boundary must be drawn between the Thought Layer, where the model parses instructions and formulates probabilities, and the Action Layer, where those probabilities manifest as material changes to the external environment. Tool access is the definitive boundary. To safely deploy agentic AI, organizations must immediately transition toward architectures defined by strict conduct firewalls, Zero Trust tool authorization, and dynamic behavioral sandboxing. By isolating execution environments, leveraging kernel-level eBPF enforcement to eliminate policy paralysis, rigorously governing the Model Context Protocol (MCP) to prevent token theft and context poisoning, and enforcing mandatory human-in-the-loop checkpoints for critical state-altering actions, security architects can effectively neutralize the threat of excessive agency. The future of AI security relies on a simple, foundational principle: a compromised model is merely a liability; an unrestricted model is a catastrophe. Protecting the enterprise requires conceding that an AI may occasionally think, reason, or speculate maliciously, but utilizing ironclad structural controls to ensure it is never granted the autonomy, functionality, or permissions to act upon those thoughts. AI systems require robust conduct firewalls, not thought policing.

Works cited

1. Every Agent Needs a Computer: The Agent Sandbox Economy ..., accessed June 27, 2026, https://jrodthoughts.medium.com/every-agent-needs-a-computer-the-agent-sandbox-economy-web3-ai-opportunity-9fb3e8e3a4b3
2. The Rise Of AI Policy Firewalls: Why Every AI Agent Will Need A Guardrail Layer \- Forbes, accessed June 27, 2026, https://www.forbes.com/councils/forbestechcouncil/2026/04/01/the-rise-of-ai-policy-firewalls-why-every-ai-agent-will-need-a-guardrail-layer/
3. Securing the AI Ecosystem Begins at the Model Layer, accessed June 27, 2026, https://www.cisecurity.org/insights/blog/securing-ai-ecosystem-begins-model-layer
4. AI Agent Sandboxing & Progressive Enforcement: The Complete ..., accessed June 27, 2026, https://www.armosec.io/blog/ai-agent-sandboxing-progressive-enforcement-guide/
5. AI alignment \- Wikipedia, accessed June 27, 2026, https://en.wikipedia.org/wiki/AI\_alignment
6. The Sweeping License to Discriminate Hidden in the NDAA | American Civil Liberties Union, accessed June 27, 2026, https://www.aclu.org/news/national-security/sweeping-license-discriminate-hidden-ndaa
7. Protection and Security for AI and LLM Applications \- Akamai, accessed June 27, 2026, https://www.akamai.com/products/firewall-for-ai
8. AI Firewall: 5 Key Functions, Pros/Cons and Best Practices \[2026 Guide\] \- Radware, accessed June 27, 2026, https://www.radware.com/cyberpedia/ai-firewall/
9. What are the OWASP Top 10 risks for LLMs? | Trend Micro (US), accessed June 27, 2026, https://www.trendmicro.com/en\_us/what-is/ai/owasp-top-10.html
10. LLM06:2025 Excessive Agency \- OWASP Gen AI Security Project, accessed June 27, 2026, https://genai.owasp.org/llmrisk/llm062025-excessive-agency/
11. LLM Security: Protecting Models, RAG & Data Pipelines \- Wiz, accessed June 27, 2026, https://www.wiz.io/academy/ai-security/llm-security
12. The Productive Function of the Negative: Toward a Charitable Epistemology of Historical Disruption \- ResearchGate, accessed June 27, 2026, https://www.researchgate.net/publication/402911990\_The\_Productive\_Function\_of\_the\_Negative\_Toward\_a\_Charitable\_Epistemology\_of\_Historical\_Disruption
13. Excessive Agency in AI Agents: Risks and How to Stop It \- Redfox Cybersecurity, accessed June 27, 2026, https://www.redfoxsec.com/blog/excessive-agency-in-ai-agents-how-autonomous-tools-get-abused-and-how-to-stop-it
14. OWASP Top 10 for Large Language Model Applications, accessed June 27, 2026, https://owasp.org/www-project-top-10-for-large-language-model-applications/
15. On the Impossibility of Separating Intelligence from Judgment: The Computational Intractability of Filtering for AI Alignment \- arXiv, accessed June 27, 2026, https://arxiv.org/html/2507.07341v1
16. How does AI firewall technology compare to traditional API security for LLM protection? : r/LLMDevs \- Reddit, accessed June 27, 2026, https://www.reddit.com/r/LLMDevs/comments/1ugua0e/how\_does\_ai\_firewall\_technology\_compare\_to/
17. Understanding and Mitigating Over-refusal for Large Language Models via Safety Representation \- arXiv, accessed June 27, 2026, https://arxiv.org/html/2511.19009v1
18. ProSafePrune: Projected Safety Pruning for Mitigating Over-Refusal in LLMs | OpenReview, accessed June 27, 2026, https://openreview.net/forum?id=QkHKaPfRAB
19. Where Do Reasoning Models Refuse? \- arXiv, accessed June 27, 2026, https://arxiv.org/html/2507.03167v3
20. Safety Layers in Aligned Large Language Models: The Key to LLM Security | OpenReview, accessed June 27, 2026, https://openreview.net/forum?id=kUH1yPMAn7
21. Safety Layers of Aligned Large Language Models: The Key to LLM Security \- arXiv, accessed June 27, 2026, https://arxiv.org/html/2408.17003v2
22. OWASP LLM Top 10: are your GenAI controls keeping up?, accessed June 27, 2026, https://nhimg.org/community/agentic-ai-and-nhis/owasp-llm-top-10-are-your-genai-controls-keeping-up/
23. AI phishing: How attackers achieve 54% click rates in 5 minutes \- Vectra AI, accessed June 27, 2026, https://www.vectra.ai/topics/ai-phishing
24. Let's See You Write That Corrigibility Tag \- AI Alignment Forum, accessed June 27, 2026, https://www.alignmentforum.org/posts/AqsjZwxHNqH64C2b6/let-s-see-you-write-that-corrigibility-tag
25. Ask HN: Is AI safety simply the thought police? \- Hacker News, accessed June 27, 2026, https://news.ycombinator.com/item?id=38388400
26. An interesting read from the perspective of AI safety advocates on why people are disliking their advocacy \- Reddit, accessed June 27, 2026, https://www.reddit.com/r/singularity/comments/1d339mm/an\_interesting\_read\_from\_the\_perspective\_of\_ai/
27. OWASP Top 10 LLM, Updated 2025: Examples & Mitigation Strategies \- Oligo Security, accessed June 27, 2026, https://www.oligo.security/academy/owasp-top-10-llm-updated-2025-examples-and-mitigation-strategies
28. Mitigate Excessive Agency in AI Agents with Zero Trust Security \- Auth0, accessed June 27, 2026, https://auth0.com/blog/mitigate-excessive-agency-ai-agents/
29. LLM Security 101: Stop Prompt Injection & GenAI Attacks \- HiddenLayer, accessed June 27, 2026, https://www.hiddenlayer.com/insight/llm-security-101-the-hidden-risks-of-genai
30. Trend Micro State of AI Security Report 1H 2025, accessed June 27, 2026, https://www.trendmicro.com/vinfo/us/security/news/threat-landscape/trend-micro-state-of-ai-security-report-1h-2025
31. Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation, accessed June 27, 2026, https://www.nsa.gov/Portals/75/documents/Cybersecurity/CSI\_MCP\_SECURITY.pdf?ver=bmgiSbNQLP6Z\_GiWtRt6bg%3D%3D
32. What the NSA has to say about MCP Security, accessed June 27, 2026, https://blog.generativesecurity.ai/what-the-nsa-has-to-say-about-mcp-security/
33. What Is Excessive Agency?, accessed June 27, 2026, https://www.youtube.com/shorts/Qr8G1gv3Lok
34. A Survey of LLM-Driven AI Agent Communication: Protocols, Security Risks, and Defense Countermeasures \- arXiv, accessed June 27, 2026, https://arxiv.org/html/2506.19676v4
35. Design Patterns for Securing LLM Agents against Prompt Injections \- arXiv, accessed June 27, 2026, https://arxiv.org/html/2506.08837v1
36. Harnessing the Dual LLM Pattern for Prompt Security with MindsDB \- DEV Community, accessed June 27, 2026, https://dev.to/mindsdb/harnessing-the-dual-llm-pattern-for-prompt-security-with-mindsdb-3e02
37. Harnessing the Dual LLM Pattern for Prompt Security with MindsDB \- Medium, accessed June 27, 2026, https://medium.com/mindsdb/harnessing-the-dual-llm-pattern-for-prompt-security-with-mindsdb-edcfe2350c99
38. The Dual LLM pattern for building AI assistants that can resist prompt injection, accessed June 27, 2026, https://simonwillison.net/2023/Apr/25/dual-llm-pattern/
39. Design Patterns to Secure LLM Agents In Action \- Reversec Labs, accessed June 27, 2026, https://labs.reversec.com/posts/2025/08/design-patterns-to-secure-llm-agents-in-action
40. The Protocol That Every AI Company Is Quietly Building On | What is MCP? Ft. Marc Benioff, accessed June 27, 2026, https://www.youtube.com/watch?v=ksLab69-Rkw
41. NSA publishes security guidance on designing AI systems with Model Context Protocol (MCP) \- Reed Smith LLP, accessed June 27, 2026, https://www.reedsmith.com/our-insights/blogs/viewpoints/102mvg9/nsa-publishes-security-guidance-on-designing-ai-systems-with-model-context-protoc/
42. The Security Risks of Model Context Protocol (MCP) \- Pillar Security, accessed June 27, 2026, https://www.pillar.security/blog/the-security-risks-of-model-context-protocol-mcp
43. Model Context Protocol (MCP) — Full Visual Guide | by Parvez Mohammed @ Techlatest.net | Jun, 2026, accessed June 27, 2026, https://medium.com/@techlatest.net/model-context-protocol-mcp-full-visual-guide-ffbbf2121c38
44. Security Best Practices \- Model Context Protocol, accessed June 27, 2026, https://modelcontextprotocol.io/docs/tutorials/security/security\_best\_practices
45. Model Context Protocol (MCP): Security Design Considerations for AI-Driven Automation \- Department of War, accessed June 27, 2026, https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI\_MCP\_SECURITY.PDF
46. NSA Releases Security Design Considerations for AI-Driven Automation Leveraging the Model Context Protocol, accessed June 27, 2026, https://www.nsa.gov/Press-Room/Press-Releases-Statements/Press-Release-View/Article/4496698/nsa-releases-security-design-considerations-for-ai-driven-automation-leveraging/
47. Model Context Protocol (MCP) Companion Guide \- CIS Center for Internet Security, accessed June 27, 2026, https://www.cisecurity.org/insights/white-papers/controls-v8-1-model-context-protocol-companion-guide
48. CIS MCP Security Guide: How to Govern AI Agent Access in Enterprise Environments, accessed June 27, 2026, https://www.cequence.ai/blog/ai/cis-mcp-security-guide-how-to-govern-ai-agent-access-in-enterprise-environments/
49. What Is AI in Cybersecurity? Definition, Benefits | Proofpoint US, accessed June 27, 2026, https://www.proofpoint.com/us/threat-reference/ai-cybersecurity
50. What Is AI-Powered Cybersecurity? Benefits & Use Cases \- Cyberhaven, accessed June 27, 2026, https://www.cyberhaven.com/infosec-essentials/what-is-ai-powered-cybersecurity
51. Control which domains your AI agents can access | Artificial ... \- AWS, accessed June 27, 2026, https://aws.amazon.com/blogs/machine-learning/control-which-domains-your-ai-agents-can-access/
52. Malicious AI Assistant Extensions Harvest LLM Chat Histories | Microsoft Security Blog, accessed June 27, 2026, https://www.microsoft.com/en-us/security/blog/2026/03/05/malicious-ai-assistant-extensions-harvest-llm-chat-histories/
53. AI Agent Guardrails That Won't Slow Your Team Down \- HatchWorks AI, accessed June 27, 2026, https://hatchworks.com/blog/ai-agents/ai-agent-guardrails/