AI Security
From PsyOps to CyberOps

There's a Reason This Book Has an Uncomfortable Subtitle

With enough information, all behavior makes sense. Every AI security failure this book documents: hallucination, sycophancy, excessive agency, an agent quietly overstepping its permissions, has a human name you already recognize. Not from a textbook, but from your own lived experience. That's not a metaphor to open a chapter with. It's the actual argument underneath all 22 chapters: the reason PsyOps and prompt injection work the same way isn't coincidence, it's the same failure mode in a different substrate. This book teaches you to secure the machine by finally being honest about the mechanism, because you already understand it as much as you think you know yourself.

Here's What Makes This Different From Every Other AI Security Book on the Shelf

Most books in this category do one of two things: they tell war stories with no operational depth, or they hand you frameworks with no proof any of it actually works. This book refuses that choice.

• Real, cited, documented incidents, not hypotheticals. SolarWinds. xz Utils. Log4Shell. 3CX. The Replit agent that deleted a production database after being told eleven times not to. Every one reconstructed down to the exact technical control that would have stopped it.
• Interactive labs, not screenshots. A working drag-and-drop AI governance policy builder. Click-through diagrams that walk you through an actual intrusion, artifact by artifact. This is the only book in the category you don't just read, you use.
• Written by someone doing the work, not narrating it. The author is a practicing CISO and has architected AI cloud data platforms at enterprise scale, not a journalist who interviewed one.

What This Actually Changes for Your Career

You finish this book able to do three things almost nobody in security can do yet: read an AI system's architecture and know exactly where it will fail before an attacker finds it, build the governance and control plane that makes "we didn't think of that" stop being your team's excuse, and run all of it as a 90-day program instead of a panic response after the incident. That is the exact skill gap the market is currently paying for, and it's the same skill gap most of your competition is still guessing at.

What It Changes in the Rest of Your Life Is Harder to Name, But Definitely More Important

This book will make you a better engineer of AI systems. It will also, if you let it, make you a little more honest about your own failure modes, the same ones the models have, because we built them in our own image. That's not a bonus feature. It's the whole reason the subtitle is what it is.

Six Ways AI Systems Actually Fail

Each blip in the live sweep on the cover is one of the six failure classes below. Every one of them already appeared in Chapter 3. This section takes each apart into its actual mechanism: what reached the system, what the system trusted without checking, and what broke as a result.

AI Agent Context Poisoning

Every AI agent works the same way under the hood. It pulls in documents, emails, Slack messages, search results, whatever it can find that seems relevant, stuffs them into a context window, and reasons over all of it at once to reach a decision. That single property is what makes an agent useful. It is also, without any modification at all, what makes it exploitable.

Context poisoning is not prompt injection

Context poisoning inserts a single adversarial document next to a set of otherwise legitimate ones the agent was already going to ingest. There are no rogue instructions to filter for, no command hidden in white text, nothing a prompt injection scanner would ever flag, because the poisoned document never tells the agent to do anything. It simply reads like every other document already sitting in the context, formatted the same way, referencing the same records, except that it asserts the opposite of what everything else in that context says. The entire goal is not to hijack the agent's behavior. It is to flip a single decision the agent was always going to make on its own, by changing what the agent believes is true.

Two techniques achieve that flip, and neither requires sophistication. A subtle or strong assertion, propped up by a plausible "the record has been updated" framing, exploits the same trust in recency that makes a corrected document more credible than an older one. A blunt or even fabricated claim, needing no craft at all, works just as well when the agent has no way to verify the claim against a primary source before reasoning over it. This is exactly where the psychological primitives from Chapter 2, authority, urgency, familiarity, reciprocity, come back into play, translated from a spoken or written attack on a person into the framing of a single planted document an agent will read as calmly and completely as every legitimate one around it. The same techniques that manipulate a person into skipping deliberation work on an agent by giving it a document that looks exactly like something it should trust.

Nothing about this technique is specific to one department. The same planted document can poison an HR decision, a financial report, a supply chain optimization, a customer program, or any other corporate function an agent has been given context over. All it requires is one adversarial document sitting anywhere the agent already pulls from.

The threat model

• 01Attacker capability required. Write access to any single source the agent already ingests, a shared drive, a wiki page, a support ticket, an email thread, a Slack channel. Not privileged access to the agent itself, and not access to its instructions or configuration.
• 02Attacker goal. Flip one specific decision the agent will render, not take over the agent's behavior generally. The narrower the goal, the more the poisoned document can be written to target it precisely.
• 03Delivery vector. Agnostic to the specific ingestion channel. The same technique works through a RAG index, a Slack integration, an inbox the agent reads, or a search result the agent retrieves, because the vulnerability lives in how the agent weighs conflicting context, not in any one integration.
• 04Why it evades detection. A content filter tuned to catch instructions has nothing to catch. A permissions audit finds nothing, because no permission was ever exceeded. The only thing that happened is that a plausible-looking document said something false, in a context the agent had no mechanism to verify against a source of truth.

And One Uncommon Pattern

The six patterns above are all failures inside an AI system. This one is different, and arguably harder to sit with: what happens when the threat actor stops attacking the system and starts hijacking the tools the defenders themselves reach for. Not a jailbreak, not a poisoned dependency. The attacker profiles the administrator, the DevOps engineer, the security analyst, and turns the utilities on their own desktop into the delivery mechanism.

How traditional malware works

Strip away any single family's specifics and almost all traditional malware follows the same five stage shape: a payload is delivered to a machine, it executes, it establishes persistence so it survives a reboot, it opens a channel back to the attacker for command and control, and only then does it pursue its actual objective, credential theft, lateral movement, ransomware, exfiltration. Each stage exists because skipping it defeats the whole operation: no persistence means losing the foothold at the next restart, no working C2 channel means an attacker with a beachhead and no way to give it orders.

The distribution problem: staying one step ahead

Delivery and command and control are where traditional malware actually dies. A domain gets reported, a hash gets added to a blacklist, and every infection that depended on it goes dark in hours. Automated sandboxes make it worse before the malware ever reaches a real victim: a file that behaves identically in an analyst's detonation chamber and on a real desktop gets caught and signatured before wide distribution even starts, so most working malware is built to look inert in an automated environment and only act once it is confident it is on a real machine. Staying ahead of both problems at once, blacklisting on the way in and sandbox detection on the way in, is what separates malware that survives for months from malware that survives for a news cycle.

EtherRAT: solving both problems by targeting the people who solve problems

In March 2026, Atos's Threat Research Center documented a campaign built around exactly that resilience question, and it answers it by refusing to cast a wide net at all. The campaign, identified as delivering a modular Node.js backdoor called EtherRAT, does not target general consumers. It targets enterprise administrators, DevOps engineers, and security analysts directly, by impersonating the specific utilities that only those roles ever search for.

The tools being impersonated are the point. Atos catalogued installers spoofing Sysinternals utilities like Autoruns, ProcDump, Sysmon, Process Monitor, and Process Explorer; administrative tools like Windows LAPS, RSAT, and Windows ADK; remote access clients like Dameware and ScreenConnect; and data movement tools like AzCopy and FSLogix. A standard user has no reason to ever search for a debugger like WinDbg or a deployment kit like Windows ADK. Anyone who does is, with near certainty, a person holding elevated system or network permissions, which makes the search query itself a free victim-profiling filter, no exploit required. Atos's own researchers named the outcome plainly: a successful infection on an administrator's workstation hands the attacker the keys to the kingdom, and a direct path to lateral movement across the rest of the environment. There is also a sharper irony sitting underneath the profiling: several of the impersonated tools, Process Explorer and TCPView among them, are the exact utilities a security professional reaches for to investigate a suspected problem in the first place.

EtherHiding: a command and control channel with no seizable center

Once EtherRAT is running, it does not reach out to a hardcoded server address the way most malware does, since a hardcoded address is exactly what gets blocklisted. Instead it uses a dead drop resolver: rather than connecting directly to its command infrastructure, the malware first checks a public, legitimate platform for an encoded pointer to where the real command server actually is. EtherRAT's variant of this technique, dubbed EtherHiding, stores that pointer inside an Ethereum smart contract. The malware queries nine separate public Ethereum RPC services in parallel and accepts whichever address the majority return, which keeps the lookup working even when individual RPC providers are temporarily unavailable. A background timer repeats the same query every five minutes, so if the attacker updates the contract, every already-infected machine picks up the new address automatically, with no need to re-infect anything.

The resilience this buys is structural, not incidental. Blocking a domain or seizing a server assumes there is a single physical or administrative point to remove. A smart contract address lives on a public, globally replicated ledger with no owner to serve a takedown notice to, and updating the C2 address the malware resolves to costs the attacker one transaction, not a new domain registration, a new DNS record, or a new server. Even the beacon traffic once a C2 address is resolved is built to blend in, styled to look like an ordinary request for a static web asset, a random hex path, a common file extension like .ico or .png, nothing that reads as command and control traffic to a network defender at a glance.

Attribution here is genuinely split rather than settled. Sysdig's Threat Research Team linked EtherRAT to the North Korean state-sponsored Lazarus Group, citing tooling overlaps with the separately documented "Contagious Interview" campaign. eSentire's Threat Response Unit, investigating an unrelated open-directory server, separately found extensive code commonalities between EtherRAT and the Tsundere botnet malware used by the Iranian state-sponsored group MuddyWater. Read together, the honest conclusion is not that either attribution is wrong, but that this delivery and C2 pattern is portable enough to be moving between distinct state-linked operators, not staying locked to one.

Three Diagrams From the Full Edition

This book is built around interactive labs and diagrams, not screenshots. Here are three of them, live, chosen because they show exactly what the paid chapters actually deliver: real documented incidents, a real published defense architecture, and a real tool you can use immediately.

Continue Into the Full Edition

Every chapter, all 22 of them across all three Parts, is in the full edition: the narrative chapters, the technical deep dives, the case studies, and the full reading and reasoning behind every interactive diagram you just clicked through above.