Your assistant is not a web application with a model behind it: it is a non-deterministic component holding permissions, reading content you do not control, and acting on systems you do care about. That breaks nearly every assumption your authorisation model was built on.
If your model only answers questions about public documentation and touches nothing, the risk is reputational and far less than this will cover it. The conversation changes the moment the system reads other people's data, invokes tools, or speaks to customers on your behalf.
The same as any other engagement, with one important difference: here findings carry a success rate, not a yes or a no.
A non-deterministic system does not fail always or never. Each finding is run an agreed number of times and delivered with its rate — “17 of 40 attempts” — the exact template and the full transcripts. It is the only way your team can verify the fix and the only way improvement can be measured.
What a third party can achieve against your assistant, at what effort, and what decision follows. No model jargon, because whoever signs the budget has no reason to know it.
Every finding referenced to the corresponding taxonomy, so your report is comparable with any other assessor's and with your next review.
What is fixed in the system prompt, what in the input or output guardrail, what in the authorisation model, and what is only fixed by taking a permission away from the agent. The distinction matters: almost everything patched in the prompt breaks again.
The set of cases used, in executable form, so you can run it yourself on every deployment. A model changes behaviour when it is updated, even if you never touch a line.
Two hours with the people who built the system, reproducing findings live. This is where it becomes clear why the guardrail they had in place was not doing the job.
The order matters. Most of the real risk sits not in the model but in what is wired to it, so the work starts with the permission inventory rather than with the prompt.
Which model, which tools it can invoke, under which identity, over which data, and what enters the context. The inventory of the agent's effective permissions is usually the engagement's first finding.
System prompt extraction, instruction evasion and — what actually matters — injection from the content the system ingests: documents, email, pages, tickets. An attacker does not need to talk to the assistant if the assistant reads something of theirs.
RAG corpus leakage, access to another user's or another tenant's documents, and recovery of information that was in the context of somebody else's conversation.
Unauthorised function invocation, action chaining, confused deputy, and exfiltration through the output channel — markdown images, links, outbound requests — which is how data leaves without anybody seeing an alert.
Provenance of weights and adapters, MCP servers and third-party plugins, and cost per query: denial of service by invoice is real and almost never in the threat model.
Statistical repetition of each finding, report, technical session and regression battery.
They overlap but they are not the same. This service seeks coverage: enumerating as many exploitable weaknesses in the AI system as possible, with your team informed. A red team with an AI component uses the assistant as one vector among several to reach a business objective, covertly and unannounced. If you have never assessed the assistant, start here: the red team will cost more and tell you the same thing.
Because the system is non-deterministic. The same input may work one time in three, and a report that says “vulnerable” without saying how often supports neither prioritisation nor verification of the fix. We run each case an agreed number of times and deliver the rate. It is more work, and it is the only honest way to measure it.
It helps against obvious misuse and does not address the underlying problem, which is authorisation. A guardrail filters text; it does not stop the agent invoking a tool with permissions it should not hold. If the model can read the entire database, no output filter is going to fix that reliably.
Two to four weeks for an assistant with tools and RAG. We need a staging environment equivalent to production, credentials for at least two users with different permissions — isolation cannot be tested from a single account — and documentation of the exposed tools. If only production exists, we agree a window and a stop condition.
It is one of the pieces. Article 15 requires high-risk systems to achieve an appropriate level of accuracy, robustness and cybersecurity, and expressly names data poisoning, model poisoning, adversarial examples and model evasion. High-risk obligations under Annex III apply from December 2027 and those under Annex I from August 2028, so there is room to arrive in order rather than at the last minute.
Yes, where it earns its place: surface coverage, variant generation and triage. Not to decide. No tool issues a verdict in our reports; every finding is reproduced and verified by hand before it goes in. That is precisely the part a supervisor examines, and the part that still has a name attached to it.
Describe the environment and the reason behind the engagement. I will reply with the recommended mode and an estimated order of effort.