After 25 years defending against man-in-the-middle attacks, I see a troubling pattern in how most AI agents are built that should concern any CISO. 

Strip away the marketing language, and the architecture looks remarkably similar to the threats I’ve spent my career fighting. Consider what AI agents actually do in practice. They sit between users and foundation models, intercepting and modifying prompts through processes vendors call enrichment or context injection. When models respond, agents intercept those responses, filter or modify outputs, and deliver their own versions back to users. Most systems offer limited ability to audit these modifications and keep no verifiable logs. 

If any traditional technology operated this way, security teams would recognize it immediately as a man-in-the-middle attack and refuse deployment. Yet organizations are implementing AI agents throughout their infrastructure with far less scrutiny. 

The Architecture Creates Real Compliance Gaps 

This structural similarity creates three concrete problems. First, data flows through systems that organizations cannot fully verify. Many agents route data to third-party services with unclear retention policies, creating direct conflicts with GDPR, HIPAA, and SOC 2 requirements. Security teams bear responsibility for data protection but cannot verify what happens once information enters the agent layer. 

Second, business decisions get made on information that cannot be independently validated. Agents modify inputs by adding unrequested context, filtering prompts in undisclosed ways, and potentially injecting hidden instructions. Organizations are running operations based on information they cannot verify independently. 

Third, meaningful audit trails do not exist. Unlike open-source software, where teams can inspect code, or traditional black-box systems where identical inputs produce identical outputs, AI agents operate non-deterministically. Training data provenance is unknown. Processing remains opaque. No cryptographic proof of integrity exists. This violates every zero-trust principle the industry has built over two decades. 

Why We Built StrongestLayer Differently 

Security vendors learned to measure failure long before AI became fashionable. When security AI produces false positives, consequences arrive immediately through wasted analyst time, business disruption, and eroded trust. When systems miss real threats, organizations face breaches, regulatory penalties, and customer churn. 

This forced us to develop capabilities distinct from pure-play AI vendors. We built continuous validation, made explainability mandatory, designed for human-in-the-loop workflows, and published performance data. When building StrongestLayer, we asked different foundational questions. What would it take to deploy this in our own environment? How could we prove, rather than merely promise hat systems work as advertised? 

One realization changed our entire approach. Organizations that train AI models on customer data create structural lock-in requiring months and hundreds of thousands in compute costs. Economic recovery before retraining becomes justifiable and takes six to twelve months. 

Attackers face none of these constraints. When new frontier models appear, attackers jailbreak them within weeks with zero sunk costs and zero hesitation to upgrade. The result puts defenders using yesterday’s AI capabilities against attackers exploiting tomorrow’s models. The reasoning gap favors offense and compounds over time. 

This insight led us to reject training on customer data entirely. Instead, we use large language models as reasoning engines rather than trained artifacts. Each analysis happens independently with no retention of contents, no cross-customer learning, and no training data pipelines. When new models become available, we can deploy them within hours. Zero sunk cost in training means zero hesitation to upgrade. 

Four Architectural Principles 

We built complete visibility into detection reasoning through detailed chains of evidence. As emails traverse our analysis pipeline, each processing stage documents its findings in structured records. Security teams can trace the complete decision logic: what signals the prosecutor collected, what legitimacy patterns the defender validated, how the LLM judge weighed conflicting evidence, and why a specific confidence level was assigned. 

This chain of evidence provides transparency where it matters—in daily incident investigation, compliance documentation, and system tuning. Unlike black-box AI systems, where verdicts are explained with confidence scores and vague “anomaly detected” labels, our architecture makes every reasoning step visible and reproducible. 

We solved what I call the prosecutor-only problem. Traditional email security can only hunt for evidence of guilt with no mechanism to prove innocence. We implemented dual evidence collection. For every email, our systems run parallel investigations. The prosecutor collects evidence of failed authentication, suspicious relay paths, and threat intelligence signals. The defender collects evidence of business legitimacy patterns, vendor relationship validation, and organizational context. An impartial LLM judge weighs evidence from both sides. 

We made the LLM the orchestrator, not the assistant. Most vendors bolt AI onto existing systems where traditional detection runs first and calls the LLM for a second opinion. We built the opposite. Email goes through structured extraction, evidence collection happens in parallel for both prosecution and defense, and the LLM judge makes the final determination while weighing everything holistically. The LLM is the detection layer, informed by traditional signals. 

This architecture provides documentability that bolt-on approaches cannot match. No hidden training occurs. No proprietary algorithm learns from customer data. Just verifiable flows that organizations can audit, test, and validate. 

Performance Validates the Approach 

A recent case study with a Global 50 law firm illustrates why reasoning beats pattern-matching. Over 10 days, we blocked 347 AI-generated threats that bypassed Microsoft E5 plus a top-tier secure email gateway. 

One attack disguised as an HR performance review employed domain typo-squatting and Unicode right-to-left override manipulation. The email body contained reversed text using \u202e that displayed as “Official Notification: Performance Evaluation Access.” 

Every technique appeared benign in isolation—typo-squatted domains get medium-risk scores, Unicode is standard internationalization, HR notifications are routine. Prosecutor-only systems evaluate signals independently and miss the pattern. 

Our dual-evidence architecture reasoned holistically: Why would HR use an external typo-squatted domain? Why employ Unicode evasion techniques? Why create urgency around “terminations marked in red”? 

The prosecutor found domain spoofing and evasion tactics. The defender confirmed this violated documented HR workflows. The judge’s verdict: malicious with high confidence. 

Pattern-matching cannot solve this. Reasoning about intent—regardless of technical novelty—can. 

This validated our core thesis. When attacks are truly novel, reasoning about intent and context beats pattern matching every time. We see average detection times of one second or less, false positive rates around one percent, and routine detection of novel attacks with no matching indicators of compromise. 

What Should Become Industry Standards 

The AI security industry stands at a decision point. One path involves deploying AI agents as black boxes, accepting opacity as the price of capability. The other path requires transparent audit trails, explainable reasoning, and architectures that prove security rather than promise it. 

Several capabilities should become baseline requirements. Vendors should provide complete reasoning chains with verifiable input and output documentation. When breaches happen, organizations need to prove to regulators what security systems did and did not detect. Vendors should not train on customer data, which creates both lock-in and compliance risk. Every time a new model generation appears, training-based architectures lock organizations into yesterday’s reasoning capabilities while attackers upgrade immediately. 

Vendors should publish performance metrics, including false positive rates, false negative rates, and detection latency, all validated by third parties. If vendors will not publish false positive rates, those rates are probably unacceptable. Vendors should build model-agnostic architectures. When new models become available, deployment speed matters. If the answer is six to twelve months, that represents obsolescence by design. 

The security industry spent 20 years learning to encrypt everything, authenticate everything, and verify everything. The AI boom should not erase those lessons. AI agents are intermediaries. Some are transparent, auditable, and respectful of zero-trust principles. Others are architectural man-in-the-middle attacks with effective marketing. 

Organizations evaluating AI security should ask whether they can trace the reasoning behind every decision, verify data flows match documentation, swap reasoning engines without retraining, and explain to regulators why specific verdicts were rendered. If the answer to any question is no, organizations are deploying opacity and calling it innovation. I’ve spent 25 years defending against man-in-the-middle attacks. I’m not about to deploy one in my own infrastructure regardless of marketing quality.