Running an AI and LLM security engagement means scoping your model's attack surface, testing it against known failure classes like prompt injection and RAG leakage, and validating fixes before you ship. Most teams can run the first pass internally in two to three weeks; the parts that need outside expertise are adversarial testing design and mapping findings to a defensible standard like the OWASP LLM Top 10.
AI products get shipped faster than security review cycles can keep up with, and that gap is where the incidents happen. A chatbot that leaks another customer's data through a poorly scoped retrieval index. An agent with tool access that gets talked into deleting records it shouldn't touch. A support bot that discloses its own system prompt on request. None of these require a nation-state attacker. They require a curious user and a model that was never tested against adversarial input. This guide walks through how to structure that testing as a real engagement, not a one-off red-team afternoon.
Step 1: Define What "AI System" Actually Means for Your Scope
Before any testing starts, write down every place a large language model touches your product. Teams routinely miss half of this list because "the AI feature" in the roadmap is actually three or four separate integrations:
- Customer-facing chat or copilot interfaces
- Retrieval-augmented generation (RAG) pipelines pulling from internal documents, tickets, or databases
- Agents with tool-calling or function-calling access to internal APIs
- Internal employee tools built on the same model with looser guardrails
- Third-party AI features embedded via vendor APIs you don't control end to end
Each of these has a different threat model. A public chatbot needs prompt injection and jailbreak testing. A RAG pipeline needs data segregation testing. An agent needs abuse-case testing against every tool it can invoke. Scoping all four the same way wastes the engagement's time on the wrong risks. This is the step most internal teams underinvest in, and it's usually where a firm running AI security assessments earns its fee just by asking the right scoping questions before a single prompt gets fired at the model.
Step 2: Map Findings to the OWASP LLM Top 10 Early, Not at the End
Don't wait until the report to decide how findings get classified. Structure your test plan against the OWASP LLM Top 10 categories from day one: prompt injection, insecure output handling, training data poisoning, model denial of service, supply chain vulnerabilities, sensitive information disclosure, insecure plugin design, excessive agency, overreliance, and model theft. Mapping to this framework upfront does two things. It gives you a checklist that prevents blind spots, and it gives your findings a vocabulary that auditors, procurement teams, and enterprise security reviewers already recognize. A finding labeled "excessive agency in the refund-processing agent" moves through a security review faster than "the bot did something weird when we asked it to."
Step 3: Test Prompt Injection Against Realistic Attack Surfaces
Prompt injection testing has to go beyond typing "ignore previous instructions" into a chat box. The realistic attack paths are indirect: injected instructions hidden in a PDF the model summarizes, in a web page an agent fetches, in a support ticket the model reads as context, or in an email subject line that gets passed into a prompt template. Build test cases around every input channel the model consumes, not just the ones a user types directly. For each channel, test whether:
- The model follows instructions embedded in retrieved content over instructions from the actual user
- System prompt contents can be extracted through direct or indirect questioning
- Output filters can be bypassed through encoding, translation, or role-play framing
Document every successful bypass with the exact input, not a paraphrase. Reproducibility matters more here than in most security testing because model behaviour drifts across versions and temperature settings.
Step 4: Test RAG Pipelines for Data Leakage Across Boundaries
RAG systems fail in a specific and predictable way: the retrieval layer doesn't respect the access boundaries the rest of the application enforces. A multi-tenant SaaS product might correctly scope database queries by tenant ID everywhere except the vector index feeding the AI feature, because that index was built later, by a different team, without the same review. Test for this directly. Create test accounts in separate tenants, seed each with distinguishable data, and query the AI feature from one account asking about the other's content, directly and through indirect phrasing. Also test whether the model discloses metadata about documents it can't fully return, source filenames, internal project names, or document counts that reveal information about other customers.
Step 5: Build Agent Abuse Cases Around Every Tool It Can Call
Agentic systems are where excessive agency findings concentrate. If an agent has a tool to issue refunds, cancel subscriptions, or modify records, treat that tool the same way you'd treat an API endpoint in a penetration test: enumerate the abuse cases first, then try to reach them through conversation. Common findings include agents that can be talked into calling a tool outside its intended context, agents that chain multiple tool calls in ways the developer never anticipated, and agents that fail to re-verify authorization between conversational turns. Timelines here run longer than prompt injection testing because abuse-case design against a novel tool set takes real thought, budget an extra three to five days for any engagement involving tool-calling agents.
Step 6: Realistic Timelines for an AI Security Engagement
For a single production AI feature (one chatbot or one RAG pipeline), a properly scoped engagement runs:
- Days 1 to 2: Scoping, architecture review, threat model against OWASP LLM Top 10
- Days 3 to 7: Prompt injection, jailbreak, and output-handling testing
- Days 5 to 9: RAG leakage and data boundary testing (runs in parallel where feasible)
- Days 8 to 12: Agent abuse-case testing, if applicable
- Days 12 to 15: Report, remediation prioritization, retest of critical findings
Add a week if you're testing multiple agents or a production system with real customer data where you need to build synthetic test tenants first. Compress this if the system is pre-launch and the model's tool access is narrow.
Where an External Partner Actually Helps
Internal teams can and should run the basic prompt injection checklist themselves; it doesn't require an outside firm to type adversarial prompts into a chatbot. Where an outside partner earns its cost is in three places. First, adversarial creativity, a tester who does this across many clients has seen bypass techniques your team hasn't thought of, because they're not the ones who wrote the system prompt. Second, independence, a finding that a customer's enterprise security team or a Canadian regulator will trust carries more weight coming from a third party than from the team that shipped the feature. Third, mapping results into a format that survives a procurement review or a responsible AI management readiness conversation, most engineering teams have never had to write a finding an external auditor will read.
This is also where Canadian context matters more than it gets credit for. A RAG pipeline that leaks data across tenant boundaries isn't just an AI security bug, it's a PIPEDA problem, and for Quebec-facing products, a Law 25 problem. Teams in Toronto, Waterloo, and Ottawa building AI features for regulated or cross-border customers increasingly get asked in due diligence whether their AI systems have been independently tested, not whether the model card looks good. Vancouver and Calgary fintech and health-adjacent startups face the same question earlier in their sales cycles than they expect.
Turning Findings Into a Remediation Plan, Not Just a PDF
The engagement isn't done when the report lands. Prioritize findings by exploitability and blast radius, not by OWASP category number. A prompt injection that only leaks the system prompt text is lower priority than a RAG leak that crosses a real tenant boundary or an agent abuse case that touches money movement. Set a retest date for critical and high findings, two to four weeks out is realistic for most engineering teams, and confirm the fix actually closes the attack path rather than just filtering the specific prompt used in testing. Attackers don't reuse your test cases verbatim, so a fix that only blocks the exact string you tested isn't a fix.
If you're shipping an AI feature and haven't had it tested against prompt injection, RAG leakage, and agent abuse cases, that gap is worth closing before a customer's security review finds it for you. Traztech runs AI security assessments for Canadian teams building on LLMs, scoped to your actual architecture and mapped to the OWASP LLM Top 10. Get in touch to talk through scope and timeline for your system.