What evidence does the EU AI Act expect for an AI agent, and what a buyer's questionnaire will ask

This page explains the Act's requirements in plain language and is not legal advice. Timelines for some obligations have been revised since the Act entered into force; check the current text for the dates that apply to you.

Why agents get asked about the AI Act even when they are not "high-risk"

The EU AI Act (Regulation 2024/1689) places its heaviest duties on high-risk systems: those used in listed areas such as credit, employment, education, essential services and law enforcement, or acting as safety components of regulated products. Most AI agents sold to businesses — support triage, document review, research, internal automation — do not fall into those categories on their own.

Buyers still ask. A bank reviewing a vendor's agent is itself under the Act, under DORA (Regulation 2022/2554) for ICT risk, and under its own model-risk policy. Its security questionnaire now carries a block of AI questions, and the vendor who answers them with evidence closes the deal; the one who answers "we follow best practice" waits. The practical standard for any agent that touches customer data is therefore the high-risk evidence set, applied proportionately.

The Act's requirements, as evidence you can hold

Article (high-risk chapter)	What it asks for	Evidence to have on file for an agent
Art. 9 — Risk management	A continuous process to identify, evaluate and mitigate risks	A written risk assessment naming the agent's attack surfaces (inputs it reads, tools it can call, data it can reach) and the mitigations
Art. 11 + Annex IV — Technical documentation	A description of the system, its design, capabilities and limits	An inventory: model, tools, MCP servers and their auth, skills, permissions, what it can and cannot do
Art. 12 — Record-keeping	Automatic logging of events over the system's life	Logs of tool calls and consequential actions, retained; a sample on request
Art. 13 — Transparency	Instructions and information enabling deployers to use it properly	A plain description of purpose, known limitations and what was not tested
Art. 14 — Human oversight	Measures allowing humans to understand, monitor and intervene	A human gate on actions that pay, send, delete or change records; a stop mechanism
Art. 15 — Accuracy, robustness and cybersecurity	Resilience to errors and to attempts to alter use or performance, including attacks specific to AI such as data poisoning and adversarial inputs	Dated test results against prompt injection, data exfiltration, tool misuse and secret exposure, with run counts and statistical bounds; re-tests after changes
Art. 50 — Transparency obligations	People interacting with an AI system must be told so	Disclosure in the agent's interface

Article 15 is where most of the questionnaire lives, and where "we have a policy" is weakest. The Act's own language — robustness against "attempts by unauthorised third parties to alter their use, outputs or performance by exploiting system vulnerabilities" — is a description of prompt injection and tool misuse.

The fifteen questions, and how to answer them

A typical AI block in a 2026 vendor security questionnaire, grouped by what it really asks:

What is it and what can it reach? 1. Which model(s) and providers are used, and where do they run? 2. What data does the agent access, and is any used for training? 3. Which tools, APIs and connectors can it call? Which can take irreversible actions? 4. Which third-party skills, plugins or MCP servers does it load, and how were they vetted?

Evidence: the inventory (Annex IV line above). A Guard report maps files, MCP servers (and whether each has authentication), skills and configuration.

How was it tested? 5. Has the agent been tested against prompt injection? How, how often, by whom? 6. Has it been tested for data leakage and secret exposure? 7. Have tool-misuse and excessive-agency scenarios been tested? 8. Are results mapped to a recognised framework (OWASP, NIST AI RMF, MITRE ATLAS, ISO 42001)? 9. When was the last test, and what changed since?

Evidence: a dated report that names the attacks, the run counts and the outcome per finding. For the run count, say what bound it gives: no obedience in 32 runs bounds the true rate at roughly 9%; in 8 runs, roughly 37%. A clean single run is not evidence.

What stops it going wrong? 10. Is there a human approval step before consequential actions? 11. Are tool permissions least-privilege? Are MCP servers authenticated? 12. Is there a kill switch and an incident process? 13. What is logged, and for how long?

Evidence: the gate list, the permission inventory, the logging statement.

Who is accountable? 14. Who owns AI risk for this product, and is there a re-test cadence? 15. Will you provide independent evidence, not only self-attestation?

Evidence: a named owner, a cadence (re-scan on every release; monthly or weekly subscription), and a third-party report. Independent research in 2026 found 83% of vendors' AI security claims could not be independently verified — being in the other 17% is a selling point.

What a good answer to question 5 looks like

"The agent is tested against prompt injection on every release. Each probe runs 32 times in a fresh context; the worst finding sets an A–F grade. On version 2.3 (18 Oct 2026) no injection obedience was observed in 32 trials (upper 95% bound ≈ 9%). One medium finding (partial compliance in 3 of 32 runs on an indirect-injection probe) was fixed and re-tested. Report and evidence attached; mapping to OWASP LLM01/ASI01 and NIST AI RMF Measure function included. Not assessed: inter-agent communication and persistent-memory poisoning."

Every clause of that paragraph is something a reviewer can check. That is the difference between evidence and assurance.

Where Sloopt fits

Sloopt produces the dated, standards-mapped test report that answers questions 5–9 and 15: Rate for a skill before it is installed, Guard for a running agent (read-only repo access plus live probing of the endpoint). Every finding carries the probe, the reply, the fix and the clause of OWASP, MITRE ATLAS, NIST AI RMF or the EU AI Act it relates to, and the report lists what was not tested. See /compliance for the full mapping.

A grade is independent supporting evidence — one input into your security and compliance programme. It does not certify legal compliance.