Application Security in the Age of AI™

About this book

Application Security in the Age of AI is a professional handbook for the people responsible for securing software that an enterprise builds and runs for itself, at the moment when that software started making decisions. It opens with an incident. An expense assistant at a freight company approved a four thousand dollar reimbursement. It used legitimate credentials, called the legitimate endpoint, and passed every validation rule in the schema. It did all of this because a wiki page an employee had edited that morning told it to. Eleven separate security controls had examined that application, and every one of them reported green. Nobody skipped a check. The checks were reading the code, and the application was reading a wiki page. That gap is the subject of the book. Conventional application security verifies properties of artifacts: source code, dependencies, build outputs, configuration. It assumes that a component behaves the same way twice, which is what makes a scanner useful, a gate meaningful, a severity score stable, and a penetration test worth reading a month after it was written. That assumption held for forty years. It does not hold for an application with a language model in it, because such an application's behavior is produced fresh at runtime from the model, the prompt, the retrieved context, the tool descriptions, and the memory. None of that sits in the artifact the scanner inspects, and any of it can change without a single line of code being committed. The book names this the Runtime Determinism Gap and then does something unusual for a practitioner title: it proves the gap is a formal limit rather than a tooling shortfall. Verifying that an arbitrary agent satisfies a safety property defined by a permission set reduces to the halting problem. Context-aware verification reduces to it as well, because deciding whether the current step is safe requires deciding what the rest of the trajectory will do. Distinguishing an authentic instruction from an injected one is a non-trivial semantic property of behavior, which makes it undecidable in general. No future scanner closes this. The consequence organizes the entire book: if you cannot prove what an AI application will do before it runs, security must also control what it is allowed to do while it runs. From that follows a complete operating model, delivered as five frameworks in dependency order. The AI application portfolio register finds the estate, across five populations that four different systems of record reveal, because the register almost always describes a fraction of what is actually running. The blast radius tier map sorts applications by what each can reach and change rather than by how important anyone thinks it is, with seven stop conditions in front of it that refuse designs which cannot be bounded at all. The runtime authority plane bounds what any application can cause, as a platform service every application inherits and none can bypass, positioned outside the execution step because the book demonstrates that is the only place a control can hold. The runtime behavior baseline observes what applications actually do, from telemetry the enterprise owns rather than from a vendor's logs. And the AI Security Debt model closes findings at the rate they arrive while being honest that some findings never close at all, because six of the seven components a finding can live in have no diff to fix. Twelve supporting instruments sit underneath those five, each a working artifact rather than a concept: a maturity baseline scored on four levels, a discovery sweep built from queries an enterprise can already run, five trust boundaries with a diagramming convention, an authority ledger that turns excessive agency from a category into a number, a retrieval authorization standard, a developer environment admission standard, a two-lane assurance model, a five-part security requirement form, a consumption envelope, an internal forcing function map, a testing bench with corpus custody rules, and a Control Evidence Pack that answers internal audit, the external auditor, the cyber insurer, and the board from a single assembly. The book covers subjects that most application security literature has not caught up to: retrieval-augmented generation as an access control boundary where relevance is not authorization; non-human identity, delegation depth, and token scoping for software that acts on a person's behalf; the developer's own AI-assisted environment as an application that reads untrusted content and takes action; availability and cost as a security class, because a denial-of-wallet incident reaches finance before it reaches security; and remediation for findings that reopen without anyone touching the code, because a model provider pushed an update. It is written for four readers at once. Chief information security officers get the board question each chapter must answer and the sentence that defends a budget. Vice presidents of engineering and platform get the ratio and the condition of done they sign. Directors of application security get the instrument, with an owner, a cadence, and the decision it feeds. And application security engineers get one worked artifact at build depth in every chapter: the policy as it would actually be written, the ledger row as it would be filled in, the query as it would be typed. Every chapter opens on an operational problem told through one of four composite organizations, installs a single instrument, and closes with the board question, the evidence required to answer it, the failure pattern that breaks it, and a thirty-day move with a named owner. The final chapter sequences the first ninety days as twelve weeks so that a program starting on Monday has an evidence pack by week twelve. Three disciplines run through the whole book. No vendor, product, or service is named anywhere; solution categories and architectural patterns only. Every executive-level number carries its denominator and its condition in the same sentence, so nothing can be quoted out of shape. And the book states plainly what it does not solve, in a dedicated section of the final chapter, because three of the conditions it describes remain open problems in the research literature and a program that believes otherwise will be surprised. 350 pages, 131 figures, a 133-entry bibliography of peer-reviewed and preprint security research, a twenty-two instrument practitioner appendix available as working files, and mappings to NIST SP 800-218 and 800-218A, the NIST AI Risk Management Framework, ISO/IEC 42001, ISO/IEC 27034, ISO/IEC 5338, the OWASP Top 10 for Large Language Model Applications, MITRE ATLAS, the supply chain integrity levels framework, and the EU AI Act. This is Volume VIII of The Operating Discipline for AI Library, a nine-volume series by Stephen R. Jordan on running artificial intelligence as a permanent, governed business function. It is the fourth volume of Pillar II, AI Risk Governance and Security, and the second of a three-volume sequence that moves from the product an organization ships, to the applications it builds for itself, to the infrastructure underneath both.