The application passed every security check. Then it approved something it should not have.
The expense assistant approved a reimbursement with legitimate credentials, against the legitimate endpoint, with parameters that passed every rule in the schema. It did so on the instruction of a wiki page an employee had edited that morning. Eleven controls had looked at it, and every one reported green.
Nobody skipped a check. The checks were reading the code, and the application was reading a wiki page.
Not a tooling problem. A limit.
An AI application's behavior is produced at runtime from the model, the prompt, the retrieved context, the tool descriptions, and the memory. None of that is in the artifact your scanner inspects, and any of it can change without a commit. Verifying that behavior beforehand is not merely hard. It is formally undecidable in the general case.
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.
For the enterprise that builds its own software
Not the vendor shipping AI to customers. Not the buyer evaluating someone else's model. The enterprise with four hundred applications on a register, six hundred and forty actually running, three people in the security function, and an engineering organization that adopted assistants and doubled its merge rate without asking anyone.
What you will build
How it is written
Every chapter opens on an operational problem, installs one instrument, and closes with the board question you must answer, the evidence required, the failure pattern that breaks it, and a thirty-day move with a named owner. Chapter 18 sequences the first ninety days.
No vendor names anywhere. Every executive-level number carries its source and its denominator in the same sentence. The book also states plainly what it does not solve: three conditions remain open in the research literature, and nothing here closes them.
Includes 131 figures, a 133-entry research bibliography, and a twenty-two-instrument appendix available free as working files. Mapped to NIST SP 800-218, the NIST AI Risk Management Framework, ISO/IEC 42001, the OWASP Top 10 for LLM Applications, MITRE ATLAS, and the EU AI Act.
Written for CISOs, directors of application security, security architects, and the engineers who build what they secure.
Volume VIII of The Operating Discipline for AI Library(TM). Volume V found the exposure. Volume VI built the program. Volume VII built the product so the exposure is designed out. This Volume secures the applications the enterprise builds for itself.
