Free · no signup · no email required to read it
The EU AI Act Annex IV & ISO 42001 evidence checklist, for teams running AI agents / MCP servers
Every team deploying an LLM agent or an MCP server in production eventually gets asked for an Annex IV technical documentation package or an ISO/IEC 42001 evidence set. Most guides list the legal section headings. This one maps each section to the actual artifact you have to produce, and says plainly which parts a security scan can help with and which parts are entirely a human judgment call. No invented capabilities, no fake case studies.
EU AI Act — Annex IV, section by section
Primary text: Annex IV, artificialintelligenceact.eu. Nine sections, not the "seven-section" summary that circulates online.
1. General description of the system
Purpose, provider identity, version history, interconnections with other systems/hardware, software versions, deployment forms, hardware specs, user-facing instructions.
You can generate this
- System inventory: every MCP server, tool connection, and model version in the deployment
- Interconnection / dependency map from actual runtime topology
- Software bill of materials
You still have to write this
- Provider legal-entity identity
- Intended-purpose narrative
- User-facing instructions / UI description
2. Development elements & process
Development methods, third-party tools, design specs, algorithmic logic, architecture, compute resources, training data/methodology, human oversight design, validation and testing procedures and results.
You can generate this
- Third-party tool / dependency inventory
- Architecture diagram from actual MCP topology
- Security testing results (a red-team / scan report is validation evidence for the security slice)
You still have to write this
- Training data provenance and methodology
- Algorithmic design rationale
- Human-oversight process design
3. Monitoring, functioning & control
Capabilities and limitations, accuracy by subgroup, foreseeable unintended outcomes/risks to health, safety or fundamental rights, technical measures for deployer interpretability.
You can generate this
- Concrete unintended-outcome risk sources: prompt-injection paths, excessive tool permissions, unauthenticated MCP endpoints
You still have to write this
- Accuracy-by-subgroup fairness analysis
- Health / safety / fundamental-rights impact assessment
- Capability and limitation narrative
4. Performance metrics appropriateness
Justification that the chosen performance metrics fit this specific system.
You can generate this- Nothing directly – no scan output selects or justifies a business metric
You still have to write this- Entirely a product / ML team judgment call
5. Risk management system
Structured risk identification and mitigation per Article 9.
You can generate this
- Vulnerabilities, misconfigurations, excessive permissions, and injection vectors as a severity/likelihood risk register
- Before/after mitigation evidence from re-scans
You still have to write this
- Risk acceptance decisions and sign-off
- Non-security risk categories: bias, safety, societal harm
6. Lifecycle changes
Log of all modifications over the system's life.
You can generate this- Diff reports between scans, if scanning runs continuously or in CI – becomes an automatic change log for the security surface
You still have to write this- Non-security changes: model swaps, prompt/policy edits, business logic
7. Standards compliance
Harmonised standards applied, or the alternative solution used if none exist.
You can generate this- A mapping of security checks to known frameworks (OWASP LLM Top 10, MCP security practices), citing which check enforces which control
You still have to write this- Formal standards mapping and legal sign-off on applicability
8. EU Declaration of Conformity
Formal compliance declaration under Article 47.
You can generate this- Nothing – this is a signed legal attestation, not a generated document
You still have to write this- Entirely legal / provider sign-off; scan reports can be cited as supporting evidence, not as the declaration itself
9. Post-market monitoring plan
A system for evaluating post-deployment performance.
You can generate this- If scanning runs on a recurring schedule against production, the cadence and alerting is a real post-market monitoring mechanism for the security slice
You still have to write this- The monitoring plan document itself; non-security monitoring (drift, fairness); incident response process integration
ISO/IEC 42001 — evidence clauses most relevant to agent/MCP deployers
ISO 42001 is a management-system standard (like ISO 27001, but for an AI Management System). It asks for policy and process evidence, not just technical output. The clauses below are the ones a team running production AI agents will actually be asked about first.
| Clause | What an auditor wants to see | Concrete artifact you produce |
|---|
| 6.1 Risk assessment | Documented AI-specific risk assessment methodology and results | Risk register covering security findings (prompt injection, tool over-permissioning, data exposure) plus non-security AI risks, reviewed and dated |
| 8.2 AI system impact assessment | Assessment of impact on individuals/groups before deployment | A written impact assessment doc; a scan can supply the security-risk inputs, not the full assessment |
| 8.3 Data for AI systems | Evidence of data quality, provenance, and handling controls | Data-flow diagram showing what data reaches the model/tools, retention and redaction policy |
| 9.1 Monitoring & measurement | Evidence the AI system is actually monitored, not just described once | Recurring scan/test logs with timestamps and pass/fail trend, tied to defined metrics |
| 10.1/10.2 Nonconformity & corrective action | Evidence that findings get tracked to closure | Remediation tracker: finding, severity, owner, close-out date, re-test evidence |
| A.6 Third-party / supplier relationships | Evidence third-party AI components (models, MCP servers, plugins) were assessed | Inventory of third-party AI/tool dependencies with a security review status per dependency |
The honest limit of what a security scan covers. A tool like Sentinel Scan (our own CLI, included) can generate strong evidence for maybe 4–5 of the 9 Annex IV sections, and only the security-relevant slice within those, mainly sections 2, 3, 5, 6, and 9, plus ISO 42001 clauses 6.1, 9.1, and 10.1/10.2. It cannot write your intended-purpose narrative, your fairness analysis, your Declaration of Conformity, or your impact assessment. Anyone selling "we generate your full Annex IV pack" from a security scan alone is overclaiming. The upfront documentation burden is real, and a scanner only closes part of it.
Want the security-evidence slice generated for you?
Sentinel Scan CLI is free and produces the artifacts marked "you can generate this" above: dependency inventory, risk register, OWASP-mapped findings, and re-scan diffs. MIT licensed, runs locally, nothing sent to us.
Pre-launch signal only, not a live product. We use this to gauge real demand for a full Annex IV / ISO 42001 evidence pack before building one.