A security reviewer, auditor or enterprise customer looking at an AI system wants four things: the threat model, the controls, the test results and the name of whoever accepted the risk that remains.
Most AI teams can supply pieces of each from tickets, chat threads and slides, but rarely one coherent record. This template defines the security record for a single AI system across ten artefacts, from the threat model and AI bill of materials to agent permissions, red-team findings and kill switches.
It is mapped to the OWASP Top 10 for LLM Applications 2025 and written to answer customer security questionnaires as well as internal review.
All ten artefacts have a job, but three do most of the work for reviewers, customers and incident responders. Fill these first for your most exposed AI feature.
System overview, trust boundaries, threats organised by OWASP LLM risk and the top risks ranked by likelihood and impact. It is the first thing a reviewer reads and the map an incident responder needs. The artefact is a threat model dated within the last major change.
Each agent's workload identity and credential lifetime, the tools and scopes it may use, where a human must approve and the budgets that cap a task. It turns autonomy into something that can be reviewed. The artefact is a manifest checked against deployed configuration.
The kill switches for tools, agents, features and keys, with how to pull each and who may do it, plus links to playbooks and notification paths. It is the page on-call opens first. The artefact is a record of the last time each switch was tested.
Do it this week for your most exposed AI feature. Together they answer most reviewer and responder questions.
Pull model versions, hashes, libraries and connectors automatically so the inventory stays current.
Review expiring exceptions monthly and close, renew or escalate each one.
Use it as the single source, and add any question it could not answer as a new field.
A list of the components behind an AI system: base model and version with its hash, datasets used for fine-tuning or retrieval, libraries and frameworks, and plugins, tools and MCP servers, each with an owner.
Most AI questions in enterprise questionnaires ask about data flows, model provenance, access control, testing and incident response. The record holds all of those, so answers come from one maintained source.
The application's technical owner, with the security architect reviewing the threat model, controls and exceptions and signing off each release.
With every release that changes the model, prompts, tools, data sources or provider, and whenever a red-team test or incident produces findings.
No. It records the outcome of assessments and testing so they can be reviewed and repeated. The assessment itself still has to be done.
They are companions. The governance record covers purpose, classification, impact and approval; the security record covers threats, controls, testing and response. Link the two from the AI register.
Write down why, and treat it as a finding with an owner and a date. A gap that is recorded can be managed; one that is hidden cannot.
Drop your details and we'll send AI Security Documentation Template straight to your inbox - no spam, unsubscribe anytime.
Bring an AI system with external users or agent capabilities and the engineers who built it. We will build the threat model, permission manifest and incident artefacts with you and set up the rest to update from your pipeline. SECTION 7 - FAQ - 5 to 8 questions
Book an AI security documentation sprint