Security, Governance, and the Road Ahead

The same properties that make AI powerful — that it acts, that it’s non-deterministic, that it reads instructions and data through a single channel — are exactly what make it attackable and what make regulators want a say. This is the reality you deploy into. None of it is a reason to wait; all of it is your turf.

This is the last chapter, and it does three things. It gives you the adversarial reality — how these systems are attacked, and how you contain what you can’t prevent. It gives you the governance reality — the regulations arriving now, framed as architecture you build rather than paperwork you dread. And then it pulls the whole book together into a single reference architecture and a roadmap you can walk from Monday. Security and governance are where corporate engineers are most tempted to defer to someone else. Don’t. They are the most engineering-shaped problems in the book, which means they are yours.

The adversarial reality: the attack you can’t patch

Start with the one that matters most, because it is both the most exploited and the most misunderstood. Prompt injection has held the top of the OWASP list of LLM risks for two editions running, and it is not a bug you will fix. It is a consequence of how these models work: a language model reads instructions and data through the same channel, with no clean separation, so an attacker can craft input the model interprets as a new instruction rather than as content to process — and the model obeys, because it genuinely cannot tell the difference. Security researchers have taken to calling it the new SQL injection, and the analogy is apt except for one crucial difference: SQL injection has a clean fix, and prompt injection does not. You cannot patch your way out of a design property.

It comes in two forms, and the second is the one that should worry an enterprise. Direct injection is a user typing a malicious instruction. Indirect injection hides the instruction inside content the model will later retrieve — a document, a web page, an email, a support ticket — so that a perfectly innocent user question pulls poisoned content into the context and the model acts on the buried command. Every retrieval-augmented and agentic system you build is exposed to this by construction, and the attacker needs no special access at all. This is not theoretical: there are documented cases of data exfiltrated from an AI assistant through content it was fed, and of an agent tricked via leaked prompt logic into abusing a URL-reading tool to steal configuration secrets. And the numbers are sobering precisely because they’re improving but not solved — a recent frontier model’s own safety documentation reported indirect-injection success rates in an agentic setting climbing from a few percent at one attempt to well over half at a hundred attempts. Defenses reduce the risk; they do not eliminate it.

Which is why the strategy is the one Chapter 8 already gave you, now with its adversarial justification made explicit: you assume injection can succeed, and you contain the blast radius. Defense in depth — validate inputs, treat every model output as untrusted until checked, segregate untrusted external content from trusted instructions, restrict what tools and permissions the model can reach, and put a human in the loop for anything irreversible. The model layer is porous by nature. The controls you wrap around it are not, and that is where your security actually lives.

The rest of the threat surface

Prompt injection is the headline, but a defensible program maps the whole surface, and the OWASP catalog of LLM and agentic risks is the community’s shared coverage map — grounded in real incidents, and the right checklist to threat-model against. The rest, briefly, because each one connects to something you’ve already built:

Sensitive information disclosure and system prompt leakage — models can reveal training data, retrieved records, or their own system prompts, so the rule is simple: never put secrets or confidential logic in a prompt, and enforce your controls outside it, because a prompt is not a secure place. Improper output handling — the mirror of injection: treat every model output as untrusted data, and validate and encode it before it ever reaches a database, a browser, or a shell, or you’ve built a fresh injection vector downstream. Supply chain and data-and-model poisoning — your model, its training data, and its dependencies are an attack surface, and research shows that a strikingly small number of malicious documents can poison a model’s behavior. Excessive agency — an agent with more tools and permissions than its task requires is a larger blast radius waiting to happen; least privilege, from Chapter 8, is the direct control. Vector and embedding weaknesses — the retrieval layer of Chapter 7 carries its own leakage and poisoning risks, and embeddings are derived data that can expose what they were built from. Unbounded consumption — the resource and cost attacks that Chapters 8 and 10 bound with limits and budgets. And multimodal inputs widen the surface further, since an instruction can now hide inside an image as easily as inside text.

You don’t memorize this list; you use it. Map your system against it, then red-team — attack your own thing deliberately, using the OWASP taxonomy as your script and frameworks like NIST’s AI Risk Management Framework and its generative-AI profile, and MITRE’s ATLAS knowledge base of real adversary techniques, as your reference. The discipline is exactly the security engineering you already know, pointed at a new component whose defining trait is that it can be talked into things.

Governance you can build: the regulatory landscape without the panic

Now the part corporate engineers most want to hand to legal — and shouldn’t hand over entirely, because most of what regulation asks for is architecture, and architecture is yours. Three frameworks matter, and they fit together rather than competing.

The EU AI Act is mandatory law, and the world’s first comprehensive one. It sorts every system into four risk tiers — unacceptable (banned), high, limited (transparency obligations), and minimal (most systems, essentially untouched) — and puts the heavy obligations on high-risk uses. Two features catch enterprises off guard. It is extraterritorial: it applies to any organization whose AI is placed on the EU market, used by people in the EU, or whose output is used there, wherever the company is headquartered. And it distinguishes providers from deployers — so a company that embeds a third-party model into its own product is very often both at once, and “we only call someone else’s API” is not the exemption people assume it is.

Its timeline is phased, and here you must check the current state rather than trust a printed date, because it is actively moving. Prohibited practices and AI-literacy duties applied from early 2025; general-purpose-model obligations from mid-2025; broad transparency rules land in 2026. The full high-risk obligations were originally set for August 2026 — but a simplification package (the “Digital Omnibus”) agreed in the first half of 2026 has deferred them, pushing standalone high-risk systems to late 2027 and product-embedded ones to 2028, with the original dates snapping back if that package isn’t formally adopted in time. The penalties are large enough to command attention (into the tens of millions of euros or a meaningful percentage of global turnover for the worst violations). The specific dates will keep shifting; the direction — real, enforceable, risk-tiered obligations — will not. Track the current status rather than any single reference (leapfrog.lerias.org keeps a live pointer).

Around that sit two voluntary frameworks that make compliance practical. The NIST AI Risk Management Framework is a flexible, sector-agnostic structure organized around four functions — govern, map, measure, manage — with a dedicated generative-AI profile; it tells you what good practice looks like. ISO/IEC 42001 is the first certifiable AI management-system standard, provable through an accredited audit, and increasingly a line item in enterprise procurement questionnaires; it lets you prove the practice. The three share a common core — risk assessment, human oversight, accountability, documentation, continuous monitoring — so a program built well against one advances the others, and the efficient path is to use NIST for method, ISO 42001 for structure and evidence, and layer the EU AI Act’s specific obligations on top where you have exposure. One honest gap worth flagging: none of these was designed for agentic AI, so cascading failures, scope creep, and attribution across autonomous steps are things you’ll have to extend the frameworks to cover yourself.

Governance as architecture, not paperwork

Here is the reframe that turns all of that from a burden into your work: governance, done well, is shift-left engineering (Chapter 4), and its deliverables are things engineers build, not memos lawyers file.

Start with an AI system inventory — a living registry of every AI system and feature running in your organization, each classified by risk tier. This sounds mundane and is foundational, because the most common enterprise reality is not knowing what’s running or where, and you cannot govern, secure, or budget for what you can’t see (the shadow AI is always more than you think). On top of the inventory sit a small set of artifacts that make governance inspectable: a control catalog listing each safeguard and how it’s enforced at runtime, a compliance matrix mapping each control to the framework clauses it satisfies, and a risk register naming the owners, mitigations, and evidence for risks like data leakage or unauthorized action. Each high-risk system gets a named accountable owner and, crucially, stop authority — a specific person with the explicit right to pause, halt, or roll back the system in production without waiting for escalation. That last one is the tell: it’s the EU AI Act’s human-oversight requirement and Chapter 8’s kill switch, wearing a governance hat, and if nobody actually holds that authority, your governance documents are theater.

Two closing points on governance, because they change how it feels. First, it’s a competitive asset, not just a cost: in regulated industries, being able to prove your controls wins the contracts that competitors lose to delay. Second, this is compliance-by-design — you build the controls into the architecture from the start (the risk-tiered instinct: rigorous documentation and human oversight for the high-risk system, a light touch for the low-risk one), rather than reverse-engineering them under audit pressure later. Regulation, approached this way, stops being a wall and becomes scaffolding.

A reference architecture: the book on one page

Step back, and everything in this book assembles into a single, vendor-neutral shape — not a product to buy, but a set of layers to reason about, each of which you now understand.

At the base is the cloud foundation (Chapter 4): the control plane, containers, identity, and infrastructure-as-code you already command. Above it, a model-access layer reached through a gateway (Chapters 3 and 5) that abstracts providers, so you route, swap, pin, and fall back without rewrites — your insurance against lock-in and against the model changing under you. Above that, the orchestration and pattern layer (Chapter 6): context engineering, structured outputs, tool use through open protocols, and the workflows-and-agents logic that does the actual work, sitting beside a retrieval and grounding layer (Chapter 7) that connects the model to your data with permission-awareness built in. Wrapping the runtime is the operations layer (Chapter 8): deployment as versioned response paths, eval gates, safe rollout, durable execution for agents. Watching all of it is the observability and evaluation layer (Chapter 9): open-standard tracing with quality scored on the spans. And threaded through every layer, not bolted on at the end, are the three cross-cutting concerns this book has returned to again and again — cost (Chapters 5 and 10), security and control (Chapters 8 and 11), and vendor neutrality (Chapters 3 and 6). Above it all sits the layer that decides whether any of it matters: the workflow you chose to redesign (Chapter 2), because the architecture serves the co-invention, never the other way around.

That is the whole book in one picture. If you can draw it and say where each of your decisions lives on it, you can build, run, and defend AI at scale.

The road ahead, and the durable core

It’s customary to end a book like this with predictions, so here are the honest ones — agents will keep maturing from assistants you visit into systems that run whole workflows; the general-purpose-technology future of Chapter 2 will keep arriving, AI dissolving into everything until it’s as unremarkable as the spellchecker; inference will keep moving toward the edge, the Convergence completing; the open standards will keep hardening; the injection arms race will continue, defenders and attackers trading moves; and regulation will keep converging across jurisdictions toward a common risk-tiered core. Some of that will be wrong. Prediction is not the point.

The point is what doesn’t change, and it is the reason this book was written the way it was. The specific models will turn over — several times before this ink is dry. But the fundamentals underneath them are durable: the cloud-engineering discipline, the evaluation muscle, the containment mindset, the co-invention that turns a model into value, and the neutrality that keeps you free. Those outlast every release, which is why the book taught the layer beneath the vendor rather than this quarter’s tool. Learn the durable core and you are never behind, no matter how fast the frontier moves.

So here is the roadmap, and it is deliberately small at the start, because that is the whole ethos. You do not begin with a platform or a strategy deck. You begin by choosing one workflow worth redesigning, grounding one model in one real dataset, putting one thing behind a deployed endpoint, and wrapping it in one eval and one control. Then you compound: attribution and guardrails and a governance registry; then agents, the edge, and an organization-wide platform, as the value earns each next rung. That progression — not a big bang — is how the five percent got there, and how you will.

Which returns us, at the end, to where we began. The barriers a corporation places in front of delivering AI are mostly deferral dressed as prudence, and AI has revoked the patience that made deferral survivable. You were always qualified for this — it was a cloud-engineering problem all along, and that is your ground. The map in these pages was drawn by someone who got lost a great deal, pointing at the researchers and builders in the references who charted the real territory; the credit is theirs, and the walking is yours. So go experiment. Ship something small this week. The territory is open, and you were always equipped to cross it.