The EU AI Act Starts Applying August 2. Here Is What Security-Testing Evidence Looks Like.

On August 2, 2026, the majority of the EU AI Act's rules begin to apply and its enforcement machinery starts. If you provide or deploy a high-risk AI system in the EU, your technical documentation is supposed to include security testing: procedures, results, and records. Not a policy stating that you take security seriously. Evidence that testing happened and what it found.

Most teams shipping AI agents today cannot produce that artifact. This guide covers what the Act actually requires for security testing, why agent and MCP systems change what "testing" means, and what auditor-ready evidence looks like.

The timeline, precisely

The Act entered into force on August 1, 2024 and applies in stages:

One honest caveat: the Digital Omnibus package under negotiation in Brussels could extend some high-risk deadlines toward late 2027 if harmonized standards are not ready. It is not agreed. Planning around a delay that may not arrive is a bet, and procurement teams are already asking for evidence now.

One more nuance: systems already on the market before August 2, 2026 are only pulled into scope when significantly modified. For agent systems that ship weekly, that grace period is mostly theoretical.

What the Act actually asks for on security

Four places in the text matter for security testing:

Article 9: risk management. High-risk systems need a risk management system that runs across the lifecycle, and it must include testing. Testing is expected against defined metrics and probabilistic thresholds, appropriate to the system's intended purpose.

Article 15: accuracy, robustness, and cybersecurity. High-risk systems must be resilient against attempts to exploit vulnerabilities. The article names the AI-specific attack classes: data poisoning, model poisoning, adversarial examples and model evasion, and confidentiality attacks. Your testing has to speak to these, not just to network hygiene.

Annex IV: technical documentation. The documentation that backs your conformity assessment must describe validation and testing procedures and include the results. This is where a testing artifact physically lands.

Article 55: GPAI models with systemic risk. Providers must conduct and document adversarial testing of the model. This one is already in force and it is the clearest red-teaming mandate in the text.

Deployers are not exempt. Article 26 puts operational obligations on organizations that deploy high-risk systems, and in practice the evidence question flows down the vendor chain: enterprises ask their AI vendors, who ask their platform providers.

Penalties for non-compliance with high-risk obligations reach 15 million euros or 3 percent of global turnover, whichever is higher.

Agents and MCP change what "testing" means

Model-level evaluations do not cover the system the Act regulates. The Act regulates AI systems: the model plus the tools it calls, the data it reaches, and the boundaries it crosses.

The most immediate AI security risk is not in the model. It is in the integration layer.

Our assessment work across agent infrastructure keeps finding the same classes: prompt injection that pivots into tool abuse, tool-call boundaries that skip authorization, MCP servers that trust any caller, and credential paths that leak through agent context. A test regime that only evaluates model outputs misses the attack surface that Article 15 names.

So security testing for an agentic system has to exercise the running system: send adversarial inputs through the real agent, watch what the tools do, and record the outcome.

What auditor-ready evidence looks like

A screenshot of a dashboard is not evidence. A vendor PDF that says "passed" is barely evidence. Testing evidence that survives review has five properties:

1. Bounded. The test ran against a defined target, in a defined scope, within defined limits. An auditor can see what was and was not covered.
2. Reproducible. Findings carry enough detail to run the test again and get the same class of result.
3. Mapped. Findings reference public taxonomies a reviewer already knows: OWASP LLM Top 10, MITRE ATLAS, CWE. Building on shared frameworks, not competing with them.
4. Tamper-evident. The artifact is signed, and anyone can verify the signature and content hashes offline. Trust in the evidence should not require trust in whoever hands it over.
5. Portable. The artifact can be handed to an auditor, a customer, or a regulator without them needing an account on anyone's platform.

Mapped against the Act:

How we produce it

This is the shape Tachyonic ships today. A bounded runtime starts against your agent, MCP server, or tool-using workflow. It runs attack patterns drawn from our public taxonomy of 168 agent attack patterns, mapped to OWASP LLM Top 10 and MITRE ATLAS. When it completes you get reproducible findings and a signed evidence bundle.

The bundle is the part built for the Annex IV use case. It contains the findings, a manifest with content hashes, and a signature. Annex IV already expects test reports dated and signed by a responsible person. A cryptographically signed bundle is the same idea in a form a reviewer can verify without trusting the signer. tachyonic verify checks the whole thing offline. You can retain it under your plan's retention window and hand a reviewer a share link that renders the verified evidence without an account.

Evidence, not certification. Tachyonic does not certify conformity, and no testing vendor can. What we produce is the security-testing input your conformity documentation needs, in a form a reviewer can verify rather than take on faith.

What to do before August 2

1. Inventory which of your AI systems touch Annex III workflows: employment, credit, insurance, essential services, health.
2. Check whether your technical documentation has any security-testing results in it today. If the answer is a policy document, that is the gap.
3. Run a bounded test against your highest-exposure agent or MCP surface and keep the signed evidence. The free tier covers your first runtimes, and the quickstart takes minutes.
4. If you are preparing conformity documentation and want the testing scoped properly, book 15 minutes.

The deadline is dated, the testing obligation is written into the text, and the difference between a claim and evidence is whether someone else can verify it.