Generative AI has moved well beyond the stand-alone chatbot. It now drafts code, searches internal knowledge, reviews contracts, opens support cases and, in some deployments, takes action through connected tools. That broader role changes the security question. A tester is no longer looking only for a model that will say something it should not. The real concern is whether manipulated language can reach protected data or trigger an unauthorized business action.
That makes an LLM application closer to an attack graph than a single endpoint. Prompts, retrieval services, vector databases, identities, plug-ins, model gateways and downstream APIs all influence the final result. A conventional web test still matters, but it will miss the routes that are unique to systems in which instructions and data arrive through the same channel.
A useful engagement begins with an architecture walk-through. Document the system and developer prompts, model endpoints, fallback models, retrieval layer, embedding service, vector store, memory, tool definitions, API gateway, moderation controls, secrets, approval steps and logging. Mark each place where content changes trust level or where one component passes authority to another.
This map exposes the paths worth testing. A document uploaded by an ordinary user might later become trusted retrieval context for an executive. A model response might be treated as a parameter for an SQL query or a refund API. A tool result might be returned to the model without filtering. None of those transitions look dangerous when viewed in isolation; the chain is what creates the exploit.
OWASP’s current guidance on prompt injection distinguishes direct manipulation by a user from indirect instructions hidden in external content. It also notes that retrieval-augmented generation (RAG) and fine-tuning do not remove the underlying risk. In practice, that means the test surface includes email, tickets, web pages, PDFs, code repositories, spreadsheets and any other content the application can read.
Agentic systems can produce side effects during testing. They may send a message, edit a record, call an external service, expose regulated data or consume a surprising amount of paid inference. The rules of engagement should therefore name the approved tenants, test identities, models, rate limits, cost ceiling, permitted tools and emergency stop condition. Destructive functions belong in a simulator or a disposable environment.
Use canaries instead of real secrets. Create synthetic customer records, decoy API keys and tenant-specific phrases that are easy to recognize in logs. Define success before the campaign starts: retrieving a canary from another tenant, invoking a tool without approval, changing a protected transaction value, persisting an instruction in memory or causing a measurable resource-exhaustion condition. A refusal to one obvious jailbreak is not a meaningful pass criterion.
Sunil Gentyala
Single-turn prompts such as ‘ignore previous instructions’ are useful smoke tests, but experienced attackers do not depend on one phrase. Testers should vary the language, formatting, encoding, role-play, Unicode, attachments and conversation history. They should also divide intent across several turns, because controls that block an explicit request may fail when the objective is assembled gradually.
Model evasion testing should ask a practical question: can the attacker keep the harmful objective while changing its surface form? Try paraphrases, translations, long-context placement, quoted material, nested instructions and content that claims to come from a trusted workflow. Repeat the same objective after a session summary, context compression, model fallback or tool error. Those state changes often alter which instruction receives priority.
The strongest finding connects the injection to an observable effect. Can a poisoned document make the assistant retrieve a second restricted document? Can a support bot pass an altered refund amount to a tool? Can model-generated SQL, shell text, HTML or an API parameter reach an interpreter without deterministic validation? The report should show the complete chain, including the identity used, retrieved records, tool arguments and resulting state change.
NIST’s 2025 adversarial machine-learning taxonomy provides a sound frame for this work because it organizes attacks by model type, life-cycle stage, attacker objective, capability and knowledge. That wider lens keeps the assessment from collapsing every GenAI problem into the label ‘jailbreak.’
A RAG system introduces another decision layer: which content the model sees. Even a well-behaved model can produce a compromised answer when the retrieval pipeline supplies poisoned or unauthorized context. The assessment should cover ingestion, parsing, chunking, embedding, indexing, metadata, query construction and authorization filters.
Begin with controlled poisoning. Insert a synthetic document that contains a hidden instruction and observe whether the pipeline indexes, retrieves and follows it. Move the instruction through visible text, metadata, comments, white-on-white text, OCR layers, spreadsheet cells and source-code comments. Measure how consistently the poisoned object appears for targeted queries and whether it remains retrievable after the source is changed or deleted.
Isolation testing is just as important. Create two tenants or security groups with distinct canary facts, then issue semantically similar queries from both sides. Inspect the retrieved document IDs, not just the final prose. Authorization should limit the retrieval set before sensitive content enters the model context. Test empty metadata, malformed filters, case differences, wildcard values, stale access-control caches and permission changes made after indexing.
OWASP’s vector and embedding guidance calls out unauthorized access, cross-context leakage, embedding inversion and data poisoning. It recommends permission-aware stores, logical partitioning, source validation and detailed immutable retrieval logs. Those recommendations translate neatly into pen-test assertions: prove that the filter cannot be bypassed, that untrusted content is traceable and that every sensitive retrieval can be reconstructed.
Some compromises happen before inference. Review training and fine-tuning data, notebooks, embedding code, model registries, object storage, CI/CD workflows, adapters, package dependencies and deployment manifests. Test whether an unauthorized user can replace a dataset, edit an evaluation set, publish a new model version or change which prompt and policy bundle is deployed.
For predictive ML components, bounded adversarial examples can expose evasion near decision thresholds. For generative systems, use controlled poisoning in a non-production corpus and measure whether a targeted behavior survives retraining, re-indexing or rollback. Artifact hashes, signatures and separation of duties should be tested, not accepted from a diagram. A reliable rollback also has to restore the prompts, retrieval index, tool policy and model version as one coherent release.
Secrets deserve their own test track. Search notebooks, prompt templates, environment variables, traces and model logs for credentials or sensitive context. Use decoys when attempting extraction. The evidence should demonstrate the route without copying a real production secret into the report.
Manual probing is valuable for discovery, but it is a poor regression method. A small Python harness can define an objective, generate approved mutations, send them through the same interface used by clients, capture retrieval and tool traces, score the result and preserve evidence. The code should run only against authorized targets and should stop on unexpected side effects.
for case in approved_cases:
for prompt in mutate(case.seed):
result = sandbox.send(
prompt, identity=case.test_identity,
trace=True, max_cost=case.cost_limit,
)
finding = score_outcome(result, case.objective, case.canaries)
evidence.write(case.id, prompt, result, finding)
if finding.critical or result.unexpected_side_effect:
emergency_stop()
A public reference implementation of this loop runs these same four functions against a local, deliberately vulnerable RAG and tool-calling target, so every finding it reports is reproducible by running a test suite rather than asserted.
The framework around the loop matters more than the loop itself. Keep seeds and mutations under version control. Record the model and prompt versions, retrieved source IDs, identity, tool calls, latency, token use and policy state. Score concrete outcomes — a forbidden record retrieved, a file written, a tool called or an approval bypassed — rather than relying only on another model to judge whether a response sounds unsafe.
Microsoft’s current PyRIT documentation uses a comparable modular design built around datasets, scenarios, attack techniques, executors, converters, targets and scorers. It is useful for scaling red-team campaigns, but it cannot decide the organization’s threat model or the business severity of a finding. That judgment still belongs to the tester and system owner.
A strong report separates model misbehavior from system compromise. Severity should account for access required, repeatability, persistence, affected users, data sensitivity, tool privileges and the presence of a meaningful human approval step. A dramatic prohibited answer may be less serious than a plain-looking response that quietly retrieves another tenant’s contract.
Because model behavior is probabilistic, repeat each material chain. Report the attack success rate, turns required, estimated cost, time to impact and whether the result survives a new session or model revision. For RAG, track unauthorized retrieval and poisoned-document influence. For agents, track unauthorized tool calls and approval-gate failures. For the ML pipeline, record whether integrity controls detected a modified artifact and prevented promotion.
Every high-risk finding should become a regression test. Prompt wording alone is rarely a durable fix. Effective remediation usually combines least-privilege tools, permission-aware retrieval, source provenance, output validation, sandboxing, deterministic policy checks, approval for irreversible actions, rate limits, monitoring and tested rollback.
GenAI penetration testing should begin before launch and return whenever the model, system prompt, tools, retrieval corpus, identity rules or permissions change. The final deliverable is not a collection of clever prompts. It is a set of reproducible paths showing where manipulated content crossed a trust boundary and what business consequence followed.
The practical objective is not to make a language model impossible to confuse. That is not a realistic security boundary. The objective is to design and verify the surrounding application so that a confused model cannot retrieve what it should not see, execute what it should not control or quietly change the state of the business.