AI penetration testing for Australian businesses.

Scope is set against what the AI feature does and what it touches: a chatbot or copilot answering from a knowledge base, a retrieval pipeline pulling from client data, an agent that can call internal tools, or a model-facing API consumed by another system. The quote names its drivers: the number of AI features and integration points in scope, whether retrieval or tool access is involved, tenancy count for multi-tenant products, and whether any of the work needs to run on-site.

Rules of engagement are agreed in writing before testing begins, extended to cover the AI-specific surface: the prompts and inputs that are in scope, any content the system is excluded from generating even to prove a finding, and a stop-work procedure if testing surfaces a live production issue. Access granted for the engagement is least-privilege and time-boxed to the testing window, and covers what a normal user of the feature would have plus whatever the scope calls for on the configuration behind it, such as the system prompt or guardrail settings.

Prompt injection, direct and indirect: an instruction typed straight into the input, or planted in a document, email or web page the system later retrieves and treats as trustworthy

Jailbreak and guardrail bypass: attempts to make the system act outside the behaviour boundary it was configured with

Insecure output handling: whether the system's output is trusted by whatever reads it next, including being rendered as executable content or passed to another system unchecked

Data leakage through retrieval: whether a retrieval-augmented system can be made to surface data outside the requester's access, including across tenants or permission levels

Tool and agent permission abuse: whether an agent's access to internal tools and systems can be escalated, redirected or used outside its intended scope

Tenant isolation of AI features: for multi-tenant products, whether the AI feature enforces the same tenant boundary as the rest of the system

Model-facing API abuse: rate limiting, cost abuse and unauthorised access to the API surface the model sits behind

OWASP's agentic work separates security for a single model interaction from security for what happens when models can plan, persist and delegate across tools and systems. Agentic AI penetration testing follows that separation. The agent is tested as a system that plans a sequence of steps, calls tools without a person approving each call, and carries state between those steps. Testing runs against the threat categories the OWASP Top 10 for Agentic Applications sets out, including tool misuse and exploitation, identity and privilege abuse, memory and context poisoning, and cascading failures, alongside the adversary tactics and techniques MITRE ATLAS records against AI systems. The practical questions are whether one successful injection triggers a chain of tool calls, whether state written earlier in a session changes what the agent does later, and whether permission is enforced on each connected tool or inherited from the account that started the session.

Black Shard's AI and automation engineering practice builds speech-to-text and OCR pipelines and workflow automation, with an audit trail and guardrails around each automated action.

An AI penetration test run by a firm that builds and operates this class of system tests the guardrail, the tenant boundary and the audit trail against the engineering decisions behind them.

OWASP's 2025 Top 10 for large language model applications lists vector and embedding weaknesses as LLM08:2025, covering how vectors and embeddings are generated, stored and retrieved in systems using retrieval-augmented generation. The category names data poisoning, which can reach the store from insiders, prompts, data seeding or unverified data providers; access control failures that allow unauthorised access to embeddings holding sensitive information; embedding inversion, where an attacker recovers source information back out of an embedding; and cross-tenant leakage, where embeddings from one group are retrieved in response to another group's queries in a shared vector database.

Source poisoning and prompt injection are tested as separate problems because the exposure differs. Content planted in a source the pipeline indexes stays in the index, can be returned to any user whose query retrieves it, and survives until it is removed at the source and the affected index entries are deleted or rebuilt. An instruction placed in a single conversation reaches that conversation. Testing also covers whether the store can be reached outside the application's own access control, and whether a shared index lets a query made at one permission level return content that was indexed at a higher one, including across tenants in a multi-tenant product.

A RAG finding names the source document that populated the retrieved context, the query that surfaced it, and whether the exposure crosses a tenant or a permission boundary. Where the cause sits in the embedding, the finding records what was recovered from it and the control that allowed the query.