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
- The AI application portfolio register – one row for every application that calls a model, found four ways across five populations
- The blast radius tier map – five dimensions, sorted by what an application can reach and change rather than by how much it matters
- The runtime authority plane – one enforcement point outside the model that every application inherits and none can bypass
- The authority ledger – granted scope against exercised scope, which turns excessive agency into a number
- The runtime behavior baseline – the detection content that catches what an authorized identity did with its authority
- The consumption envelope – six ceilings, so a denial-of-wallet incident reaches security before it reaches finance
- The Control Evidence Pack – nine parts answering internal audit, the auditor, the insurer, and the board from one assembly
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™. 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.
