Five finding classes, each with a defined test methodology, evidence standard,
and control mapping. This is the taxonomy Averon works to. It is deliberately narrow: these are
the failures that reach real data and real systems.
TaxonomyAVR
Classes
5 primary classes
Test languages
Arabic · English · mixed-script
Method
Manual adversarial, chain-orientedAutomated scanners used only for coverage, never for findings.
Evidence standard
Reproducible, identity-contextual, mapped
Scope boundary
Why your existing testing programme does not cover this.
Application penetration testing assumes a deterministic system: fixed code paths, enumerable
inputs, a definable authorisation model. An AI deployment satisfies none of those assumptions.
Its input space is natural language, its behaviour is probabilistic, and its effective privilege
is the union of everything it can retrieve and every tool it can call.
Averon does not replace your application testing. It covers the surface that testing was never
designed to reach.
Dimension
Application pentest
AI deployment assessment
Input space
Enumerable parameters
Unbounded natural language
Determinism
Reproducible on demand
Probabilistic; variance must be bounded
Trust boundary
User ↔ application
Content ↔ model ↔ tools ↔ records
Privilege
Session-scoped
Union of corpus and tool registry
Attack entry
Request payloads
Any ingested document or tool result
Persistence
Stored payloads
Vector index, memory, cached context
Detection
WAF, signatures, anomalies
Well-formed authenticated traffic
Class register
Prompt injection
Instructions reaching the model from a channel that was assumed to be data.
Direct injection — the user overriding the system prompt — is the well-known and least dangerous
form. The consequential form is indirect: an instruction planted in content the
model retrieves or is handed, executing under the model's privilege rather than the attacker's.
How it presents
A payload placed in a document that will be indexed, and fires months later when someone asks a routine question.
Injected text in a ticket comment, CRM note, supplier email, or web page fetched at runtime.
Instructions embedded in a tool result — the model trusts its own tooling implicitly.
Payloads that survive summarisation and re-enter on the next turn through conversation memory.
Arabic-language and mixed-script payloads that pass filters tuned on English corpora.
What Averon tests
System prompt extraction and override resilience. Ingestion-path injection across every
content source feeding the index. Tool-result trust. Cross-turn and cross-session persistence.
Instruction-hierarchy enforcement under conflicting directives. Delimiter, encoding, homoglyph and
multilingual evasion against whatever filtering is deployed.
Reporting note
We do not report injection in isolation. A successful injection is only a finding when it is
chained to a consequence — data reached, action taken, or control bypassed. Everything else is
noise in a report that has to be defended to a regulator.
Data and PII exfiltration through the model
Regulated data leaving the estate inside a legitimate completion. The model
is an authorised reader of nearly everything and an unmonitored writer to the user. Conventional
data-loss controls inspect files and network flows; they do not inspect meaning in a token stream.
How it presents
Retrieval returning documents outside the requester's entitlement, then summarised into the answer.
Context bleed between sessions, tenants, or business units sharing an orchestration layer.
Secrets and connection strings surfaced from indexed configuration, runbooks or wiki pages.
Out-of-band channels: rendered markdown images, callback URLs, and outbound tool calls carrying data in parameters.
Training and fine-tuning corpora assembled from production data without a residency or minimisation decision.
Prompt and completion logs written to a store with a wider access list than the source data.
What Averon tests
Corpus scoping against the entitlement matrix. Session and tenant isolation under
adversarial pressure. Every output channel the interface can render, including those the product
team did not know were live. Log-store entitlements. Egress paths from the inference host itself.
Agent tool-access abuse
Where an assistant answers, an agent acts. Once a model can call tools, the
question is no longer what it might say — it is what it might do, on whose authority, and whether
anything stops it at the tenth attempt.
How it presents
Composition: two individually-authorised calls chaining into an outcome neither authorises alone.
Confused deputy — the agent performing a privileged action on behalf of an unprivileged requester.
Argument injection into tool parameters, reaching a downstream query, filesystem path or command.
Unbounded loops and retry storms against rate-limited or billable internal APIs.
Write and state-changing actions executing without an approval gate, or with a gate the model can satisfy itself.
Third-party tool and MCP server registration without a trust decision or an egress boundary.
What Averon tests
The full tool registry, per tool: authorisation model, argument validation, side-effect
class, and reversibility. Action budgets and circuit breakers under sustained adversarial pressure.
Human-in-the-loop gates — specifically, whether the model can construct a state in which the human
approves without understanding what they are approving.
Commonly absent control
An action budget — a ceiling on the number, rate, or cumulative impact of tool calls a single
conversation may issue — is rarely present by default in agent frameworks. An agent that can be talked into a loop is
an availability incident and, where the tools are billable, a financial one.
Model supply chain
The provenance question every other part of your estate already answers, asked
of artefacts that entered production without passing through the process that asks it. Weights,
adapters, embedding models, tokenisers, inference runtimes and third-party tool servers.
How it presents
Weights or adapters pulled from a public hub into a production path with no integrity verification.
Inference-runtime dependencies with no SBOM, no pinning, and network reach from a host holding your data.
Third-party plugins and MCP servers granted tool access without a trust review or an egress boundary.
Embedding models substituted or upgraded without re-validating retrieval behaviour or index integrity.
Fine-tuning data of unverified origin, and no record of what the resulting artefact was trained on.
What Averon tests
Artefact provenance and integrity verification across the deployment pipeline. Egress
policy on inference hosts. Trust posture of every externally-authored component in the tool path.
Reproducibility of the deployed artefact from a recorded source. For sovereign-cloud deployments,
the residency of every dependency the pipeline reaches.
Broken authorization between the model and your systems
The class we report most often and weight most heavily. The AI system holds a
single identity. Your users hold many. Between them, the authorisation decision is either
re-evaluated per requester — or it is not made at all.
In the common architecture, retrieval executes under a service principal with broad read
access, and tool calls execute under an application token scoped to the application rather than
to the person. The orchestration layer knows who is asking. The systems being read do
not. That gap is the finding.
How it presents
A single retrieval service account holding read access across every indexed corpus.
Vector indexes built without per-document entitlement metadata, making post-hoc filtering impossible.
Tool tokens issued to the application, never exchanged for a token bearing the requester's identity.
Entitlement enforcement implemented as prompt instruction — "only answer about the user's own accounts."
Access revocation that reaches the source system but not the index built from it.
Method: the entitlement differential
Averon runs the same test corpus as every persona in your entitlement matrix, from the
most privileged to the least, and computes the difference between what each persona is entitled to
and what the system will actually return to them. The differential is the deliverable: a per-persona,
per-corpus statement of over-reach, expressed in records rather than adjectives.
Why nothing detects it
There is no exploit and no anomaly. The retrieval call is well-formed, authenticated, and issued
by a trusted internal service that is expected to read broadly. Your SIEM sees a healthy system.
The only place the failure is visible is in the gap between two authorisation models — and nothing
in your stack is looking there.
Severity bands reflect Averon's assessment methodology. Detectability describes how far the class
falls outside what SIEM, DLP and monitoring are built to see. It is an expectation, not a result:
what your stack actually observes is established empirically during the engagement.
Scope an assessment against this taxonomy.
A ninety-minute technical session establishes which classes apply to your
architecture and what a full engagement would cover.