Take a hypothetical. A long-standing client books its annual application pentest and adds a line to the scope request. Its customer-service team now uses an AI assistant that searches internal policy documents and retrieves customer records through an API. The client wants to know whether your next test can cover it.
Your team can test the API, the authentication, and the hosting. The open questions sit one layer up: whether a poisoned document in the retrieval index can redirect the assistant, whether a user can talk it into fetching another customer’s record, and who will stand behind the finding that says so. Your answer to the last question decides how you add the capability.
Requests like this follow adoption. In 2025, 55% of EU enterprises with 250 or more employees used at least one AI technology, according to Eurostat’s annual enterprise survey. The measure is broad, but if you serve large enterprises, expect some accounts to run systems like the one above. The failure modes are documented. In June 2025, researchers disclosed EchoLeak (CVE-2025-32711), a zero-click vulnerability in which a single crafted email could lead Microsoft 365 Copilot to send internal data to an attacker-controlled server. Microsoft had fixed it server-side before disclosure and reported no evidence of exploitation. The chain bypassed an AI-specific injection classifier and then conventional web controls, so an assessment confined to one layer could miss the full attack path.
Start With a Client Requirement
A service line needs a named client system and a decision the client has to make. Put five questions to the client before you scope anything:
- Which AI system is involved, and who owns it?
- What sensitive data can it reach, including through retrieval?
- What actions can it take through tools, APIs, or integrations?
- What testing already covers it, and what did that testing exclude?
- What decision does the assessment need to support, and by when?
In Europe, the fifth question often has a regulatory dimension. If a client’s system is high-risk under the EU AI Act, Regulation (EU) 2026/1744 set the application dates at 2 December 2027 for systems classified under Article 6(2) and Annex III, and 2 August 2028 for those classified under Article 6(1) and Annex I. Article 15(5) requires such systems to be resilient against unauthorised attempts to exploit their vulnerabilities, with measures against data poisoning, model poisoning, adversarial examples, confidentiality attacks, and model flaws where appropriate. Classification and the client’s role as provider or deployer decide which duties apply.
For a financial entity under the Digital Operational Resilience Act (DORA), an AI assessment has to fit the entity’s existing testing programme, and it doesn’t, on its own, satisfy DORA’s threat-led penetration testing requirements, which include rules on scope and testers. For a manufacturer of products with digital elements, the Cyber Resilience Act has required reporting of actively exploited vulnerabilities since 11 September 2026. An assessment can supply evidence for these obligations. It doesn’t establish conformity with any of them.
If the answers stay vague, propose discovery before you hire or launch a service line.
Define the Capability You Need to Deliver
Plan for six areas of work: scope design, threat modelling, test execution, validation, reporting, and method upkeep. Your application, API, identity, and infrastructure skills help you trace whether an injected instruction can lead to data disclosure.
The additional work concerns how the system behaves in context. Retrieval sources, system instructions, and tool permissions become attack surface. Severity depends on what the system can reach and do, and the 2026 edition of the OWASP Top 10 for Large Language Model (LLM) Applications moved Excessive Agency from sixth to third place.
Model output also varies between runs. One verified unauthorised disclosure establishes a vulnerability. Ask assessors to repeat the test under recorded conditions and report how often the disclosure occurred. They should state what the result establishes and what remains uncertain. Automated results need human validation, as in any pentest, and our breakdown of seven gates to a validated finding sets out one approach.
Method upkeep is a standing cost. Between December 2025 and August 2026 came the OWASP Top 10 for Agentic Applications, ETSI EN 304 223 on baseline security requirements for AI models and systems, and the 2026 LLM list. The OWASP GenAI Red Teaming Guide treats model evaluation, implementation testing, infrastructure assessment, and runtime behaviour as distinct areas of work. Tools automate parts of execution; people own interpretation and severity. For definitions, see our AI red teaming primer.
When Building Is the Right Call
Building an internal practice makes sense when these conditions hold together.
- Sustained demand. Weigh size, predictability, and strategic importance against your capacity. One large engagement with a follow-on programme can justify investment; a scatter of small requests may not.
- The right people. You have, or can hire, testers who combine application security with working knowledge of model behaviour, retrieval, and agent tooling. Plan around skills your team has demonstrated. For context, respondents to the 2025 ISC2 Cybersecurity Workforce Study ranked AI as the most-needed security skill, at 41%, ahead of cloud security at 36%. The study measures broad needs, so test the market for your own profile.
- Funded upkeep. You will pay for method maintenance, including time your best people spend away from billable work.
- A reason to own it. You want full control of the method and its quality, or you want AI security to differentiate your offer.
A firm that meets these conditions may not need a partner, or may need one for a defined gap, such as peak capacity.
Compare Building, Referral, Joint Delivery, and a Hybrid Model
| Decision factor | Build internally | Refer the client | Joint delivery with a specialist | Hybrid |
|---|---|---|---|---|
| Demand | Sustained work supports investment in a dedicated capability | Occasional or uncertain requests; you commit no delivery capacity | A bounded engagement helps you evaluate demand before larger investment | Internal demand exists alongside intermittent specialist needs |
| Expertise | Recruit or develop the required skills and review capacity | Enough understanding to recognise the need and choose a credible specialist | Evaluate the partner’s method and evidence; retain enough expertise to commission and review the work | Define which skills and decisions stay internal |
| Method ownership | Maintain test design, tooling, validation, and reporting | The specialist owns the method; you judge whether it suits your client | Agree the specialist scope and quality expectations | Assign ownership of the shared method and handoffs |
| Delivery control | Manage staffing, scheduling, support, and quality | Limited; agree how the introduction and handoff work | Agree access, availability, escalation, and client communication | Prevent gaps or duplicated work across teams |
| Economics | Staffing, training, tooling, research, and utilisation | Referral terms against the value of the wider relationship | Engagement fees, coordination, review, and commercial terms | Internal effort and purchased support together |
Treat each cell as a question to investigate. Here, referral means an introduction after which the client contracts with the specialist. It is the lightest route and gives you the least control. Joint delivery means specialist work you commission inside your own engagement; other structures exist. It lets you test demand and partner quality at the same time, provided you keep enough in-house understanding to judge the method and the evidence. For a hybrid model, name who owns each handoff and who signs the findings.
Run the numbers with your own inputs. For each route, set expected engagement revenue against direct delivery, review, coordination, and retest costs. Then add the standing costs: training, tooling, and method upkeep for building, and partner management for joint delivery. Use the same time horizon and the same demand assumptions for every route. A comparison that assumes more work for one route will favour it.
Define the Responsibilities You Keep
Your responsibilities follow the route. Agree them in writing, using the following allocation as a starting point.
If you refer, you own the quality of the introduction. Describe the client’s need without overstating it, select a provider you have reasons to trust, and agree in writing how the handoff works and how you’ll stay informed.
If you sell or sign the assessment, through building, joint delivery, or a hybrid, keep six responsibilities and the final quality decision:
- Client qualification: confirm the system, the decision, and the timeline before scoping.
- Accurate proposals: state what the assessment covers and excludes, in terms the client’s security and governance owners understand.
- Evidence review: review the assessment findings, reproduce what you can, and challenge any severity rating you can’t support.
- Communication: keep one voice to the client on schedule, scope changes, and results.
- Escalation: agree in advance how a critical finding reaches the client, and how fast.
- Remediation coordination: connect AI findings to the conventional findings in the same environment, since the fix often sits in permissions or integration code.
Account ownership and assessor access can coexist. Testers need time with system owners, and clients may want to question whoever found an issue. Agree who joins which conversation, and why, before kickoff.
Check Readiness, Then Run One Engagement
Before the first engagement, review sample outputs, method documentation, and reviewer credentials, whether the capability is yours or a partner’s. Then agree three rules with the client: written test authorisation, access and data-handling terms, and stop and escalation conditions.
Run one engagement as a test of the route:
- A named client system with a security or governance decision attached
- An agreed scope, including what stays out
- Written delivery responsibilities for your team and any specialist
- A quality review of the evidence before it reaches the client
- An evaluation afterwards of actual effort against the estimate, and of whether the client used the findings
Afterwards, you should know how much of the work your team could deliver next time, what the client did with the output, and whether similar requests exist elsewhere in your accounts. Judge the route on those answers.
Capture the decision in a record your team can revisit:
| Field | What to record |
|---|---|
| Client requirement | The named system, the data and actions in scope, and the decision the client needs, with a date |
| Missing capability | The parts of scope design, testing, validation, or reporting you want outside support for, if any |
| Preferred route and rationale | Build, refer, joint delivery, or hybrid, and the evidence and cost comparison behind the choice |
| Responsibilities retained | Which responsibilities your firm keeps on this route, and who owns each |
| Readiness evidence | What you reviewed before the engagement, and what remained open |
| Review criteria | The measures you’ll check afterwards: effort, evidence quality, client use, and repeat demand |
Discuss a Defined Capability Gap
Provion is an independent adversarial testing service for AI systems, built for teams in security-conscious and EU-regulated environments. It produces structured, defensible evidence of how an AI system behaves, fails, and exposes risk. We work with pentest and offensive-security firms that want to add AI adversarial assessment to their services. The starting point is a named client use case, for which we agree scope, responsibilities, and support before any work begins.
Discuss how AI adversarial assessment could fit your services. Bring a client use case or a defined capability gap.
