Averon  //  AI Deployment Security Riyadh  ·  Data resident in KSA  ·  NCA-aligned reporting أمن أنظمة الذكاء الاصطناعي
Averon/Attack surface

The AI deployment attack surface.

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.

DimensionApplication pentestAI deployment assessment
Input spaceEnumerable parametersUnbounded natural language
DeterminismReproducible on demandProbabilistic; variance must be bounded
Trust boundaryUser ↔ applicationContent ↔ model ↔ tools ↔ records
PrivilegeSession-scopedUnion of corpus and tool registry
Attack entryRequest payloadsAny ingested document or tool result
PersistenceStored payloadsVector index, memory, cached context
DetectionWAF, signatures, anomaliesWell-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.

Reference

Class register, summarised.

IDClassReachesSeverityDetectability in a standard stack
AVR-PIPrompt injectionModel behaviour, downstream toolsHigh — CriticalLow
AVR-EXExfiltration through the modelRegulated data, PII, secretsCriticalVery low
AVR-TAAgent tool-access abuseProduction systems, state changesHigh — CriticalLow
AVR-SCModel supply chainInference path integrityMedium — HighModerate
AVR-AZBroken authorizationEverything the system can readCriticalVery low

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.

Request an engagement
Riyadh, Saudi Arabia
admin@averon.systems