Foundations of AI Safety Engineering

The discipline of AI safety, despite a decade of progress, remains an archipelago rather than a continent. Three distinct practitioner communities—alignment researchers who study intent fidelity in foundation models, infrastructure security engineers who harden the systems around them, and application developers who compose prompts, agents, and tools—have built parallel vocabularies, parallel threat models, and parallel success criteria, with relatively little shared infrastructure connecting them. A red-team finding from an academic alignment paper is rarely consumable by a security operations center; a CVE in a model-serving stack rarely informs a prompt-injection schema; a jailbreak dataset rarely propagates into a deployable guardrail. The result is a paradox: as LLM-powered systems move from research demonstrations into load-bearing roles in healthcare, finance, law, and infrastructure, the engineering practices that surround them are less standardized than those that surround a typical web application circa 2005.

This chapter argues that AI safety is not merely a research problem or a deployment problem, but an engineering discipline in its own right, with its own primitives, control surfaces, and lifecycle. We make the case by introducing a small set of abstractions that can be used across the rest of the book and, more importantly, can be used in a code review tomorrow morning. The chapter's central contribution is twofold: a tripartite taxonomy that separates *alignment*, *robustness*, and *confinement* as orthogonal design objectives, and the *AI Safety Control Plane* (AISCP), a layered architectural abstraction that locates every safety control in an LLM system at a well-defined layer with well-defined responsibilities.

The Fragmentation Problem: Why an Engineering Discipline Is Missing

Before introducing abstractions, it is worth being precise about what is missing. Classical engineering disciplines mature when three conditions are met: a shared vocabulary for failure, a layered architecture with well-defined interfaces, and a lifecycle with reproducible artifacts at each phase. Software engineering matured when it acquired type systems, linkers, package managers, version control, and CI pipelines. Information security matured when it acquired the CIA triad, STRIDE, the CVSS scoring system, and the kill chain. AI safety, in contrast, is still negotiating its primitives.

Consider what happens when a new jailbreak is reported. The alignment community treats it as a data point for evaluating alignment techniques; the security community treats it as an input to a threat model; the application developer treats it as a unit test for a prompt filter. Each community's response is locally rational, but each operates on its own schema, so the cumulative response is uncoordinated. The same observation holds for prompt injection, model exfiltration, training-data leakage, hallucination-induced harm, agent goal drift, and supply-chain compromise of model weights. Each failure has a research framing, a security framing, and an application framing; the three framings rarely meet in a single artifact.

The cost of this fragmentation falls on the practitioner who must ship a system. The application developer is told to "do red-teaming," but red-teaming has no standard procedure; to "add guardrails," but guardrails have no standard interface; to "monitor for misuse," but misuse signals have no standard taxonomy. In the absence of standards, every team reinvents control planes, and most teams under-invest in the parts that are hardest to test in isolation—exactly the parts where safety failures originate. AI safety engineering is the project of turning these ad hoc reinventions into a shared discipline.

A useful way to think about the gap: AI safety today resembles application security in the late 1990s. We have many useful primitives—prompt filters, output classifiers, retrieval guards, sandboxed code execution, policy engines—but they are unevenly deployed because no architectural pattern specifies where each belongs. This book, and this chapter, attempt to provide that pattern.

Tripartite Taxonomy: Alignment, Robustness, and Confinement

The first abstraction is a taxonomy of *safety objectives*. We propose three primary objectives that together cover the design space of safety controls for LLM-powered systems. They are not phases of a pipeline and they are not features of a model; they are *goals* that any safety architecture must satisfy to some measurable degree.

Alignment is the property that a system faithfully pursues the intent of a properly authorized operator. The operator may be a human user, a downstream automation, or a regulatory body that has delegated authority through policy. Alignment failures occur when the system executes an objective that diverges from the authorized one: a model hallucinates a citation; a chatbot adopts a persona that contradicts its system prompt; an agent pursues a side goal that an authorized chain of prompts did not request. Alignment is therefore about *intent fidelity*—the semantic relationship between what was asked and what was attempted.

Robustness is the property that a system preserves alignment and confinement under adversarial pressure. Robustness failures occur when an attacker can degrade alignment: a prompt injection that overrides the system prompt; an adversarial suffix that bypasses refusal training; a poisoning attack that installs a back door in fine-tuned weights; a context-window overflow that suppresses policy text. Robustness is the resilience dimension of safety and the one most familiar to security engineers. Robustness is *not* synonymous with safety: a perfectly robust but misaligned model is still dangerous, and a poorly robust but tightly confined one may be acceptable.

Confinement is the property that the system's *capability surface* is bounded to a range that has been risk-assessed. Confinement failures occur when the system exceeds its assessed envelope: an agent invokes a tool it was not authorized to invoke; a model emits code that escapes its sandbox; a fine-tune restores capabilities that were removed at the base-model stage; a retrieval-augmented generation pipeline exfiltrates documents the user is not entitled to see. Confinement is about *what the system is structurally capable of doing*, independent of whether any single inference intends to do it.

Three observations follow. First, the three are orthogonal in principle: a system can be well-aligned and unrobust (it does the right thing unless attacked), well-aligned and unconfinement-free (it does the right thing but can do the wrong thing when it wants), or robust but misaligned (it consistently and resiliently does the wrong thing). The three dimensions are independent design axes, which is why they must be controlled by different mechanisms at different layers.

Second, the three map onto familiar concerns but are not identical to them. Alignment overlaps with classical *correctness* and *specification*, but extends it to stochastic, generative systems where the spec is partial and the system has agency. Robustness overlaps with classical *adversarial security*, but extends it to semantic-level attacks where the adversary speaks a natural language and the defender's policy is also natural language. Confinement overlaps with classical *least privilege* and *sandboxing*, but extends it to a setting where the boundary is between two natural-language programs.

Third, the taxonomy is small on purpose. We deliberately do not enumerate every failure mode—hallucination, sycophancy, deception, jailbreaks, prompt injection, data exfiltration, goal drift, tool misuse, and so on—as independent safety objectives. Such enumerations grow with each new paper and lose their architectural utility. The tripartite taxonomy is an *invariant* of the safety design problem; the failure-mode list is a *current snap