Independent assurance around the agent control boundary.
Alongside its agent control platform, Averon provides a pre-deployment engagement that produces a launch position your board can sign, and a continuous programme that keeps that position true as the system changes. Both run against the system as it will actually operate, within the delivery boundary you approve.
Adversarial assessment
A time-boxed, full-scope engagement against the system as configured for launch. It ends with a written position: fit to deploy, fit to deploy with stated conditions, or not fit to deploy — with the evidence behind that position attached.
- 01 Architecture and trust-boundary review We map every point at which untrusted content enters the system and the identity it inherits when it does. Corpus sources, tool registry, memory stores, log destinations, and the identity plumbing between the orchestration layer and each system of record. Nothing is tested until the boundaries are drawn and agreed.
- 02 Entitlement matrix construction With your access management team, we establish who is entitled to what, in the source systems, before the model is involved. This matrix is the ground truth against which over-reach is measured. In most engagements, building it surfaces findings on its own.
- 03 Adversarial testing Manual, chain-oriented exploitation across all five classes and the languages relevant to the deployment. Automated tooling is used for coverage assurance only; every reported finding is established and reproduced by hand.
- 04 Entitlement differential The full test corpus is run as each persona in the matrix. We report the exact delta between entitlement and access, per persona and per corpus, expressed in records.
- 05 Detection gap analysis For every successful attack chain, we establish what your SIEM, DLP and monitoring actually observed. A finding that your stack cannot see is a second finding.
- 06 Reporting and launch position Executive position, technical findings with reproduction, control mapping in appropriate operating languages, and remediation stated architecturally. Delivered in a working session with your engineering and risk functions, not as an emailed PDF.
- 07 Remediation review and retest All Critical and High findings are retested against the remediated system, and the launch position is reissued. Included in scope.
What we need to scope accurately
- System purpose and the decisions or actions it influences.
- Architecture diagram to the level of the tool boundary.
- Corpus inventory: sources, sensitivity classification, and current index scoping.
- Tool registry: each tool, its side-effect class, and the identity it executes under.
- User population and the entitlement tiers that distinguish them.
- Deployment target — on-premise, private cloud, public cloud, or hybrid — and its data posture.
- Regulatory context: applicable security, privacy, AI, and sector-specific obligations.
We test against a production-equivalent environment with the real corpus and real identity configuration. A staging system with synthetic data does not exercise the failure that matters, because the failure is in the entitlement model — and synthetic data has no entitlements.
We do not test production systems that process live customer transactions without a written change window and named approver. We do not exfiltrate real personal data as proof; exposure is evidenced by record count, field schema and a redacted sample under agreed handling.
Continuous assurance
An AI deployment is not a static artefact. Prompts are revised weekly, tools are registered by product teams, corpora are re-indexed, and model versions change under you. A point-in-time assessment describes a system that no longer exists.
Re-test on material change
Defined triggers, agreed at onboarding, that require re-assessment before the change reaches production.
- Model or model-version change, including provider-side updates.
- System prompt or instruction-hierarchy revision.
- New tool registration, or a change to an existing tool's side-effect class.
- Corpus addition, re-index, or change to index scoping.
- Any change to the identity or token model between orchestration and systems of record.
Regression against your own history
Every attack chain that has ever succeeded against your system is retained and replayed on cadence. Regressions are the most common finding in Mode B.
- Full replay of the client-specific attack corpus, on an agreed cadence.
- New techniques — public and Averon-developed — folded into your corpus as they emerge.
- Entitlement differential re-run against the current matrix, catching drift in either direction.
- Standing assurance statement, dated and defensible, issued each cycle.
The question a regulator asks is not whether you tested before launch. It is whether the control you described is effective in the system you are running today.
Mode B — rationaleWhat you actually receive.
Documents written for three distinct readers — the board, the engineers who must fix it, and the regulator who will read it later. We do not ask one document to serve all three.
| Artefact | Reader | Contents | Language |
|---|---|---|---|
| Launch position | Board · exec risk | A stated position on deployment readiness, the conditions attached to it, and the residual risk accepted if it proceeds. Four pages. | As scoped |
| Technical findings register | Engineering · AppSec | Per finding: class, chain reconstruction, reproduction steps with bounded variance, identity context at each hop, and architectural remediation. | EN |
| Entitlement differential | IAM · data owners | Per-persona, per-corpus statement of the delta between entitlement and actual access, in records and field schemas. | As scoped |
| Control mapping | Compliance · audit | Findings mapped to the applicable security, privacy, AI, and sector frameworks in review-ready form. | As scoped |
| Detection gap analysis | SOC · detection eng | What your monitoring observed during each successful chain, and the telemetry that would have been required to see it. | EN |
| Assurance statement | Regulator · third parties | Mode B only. A dated statement of control effectiveness against the system as running, reissued each cycle. | As scoped |
All artefacts are produced, stored, and transmitted under the agreed evidence-handling plan. Evidence is retained for an agreed period and then destroyed to a documented standard, with certificate of destruction.
Reports carry named authorship and a named engagement lead. The person who signs the finding is the person who found it, and is available to defend it.
Findings are yours. We retain no client-identifiable material in our technique library, and nothing from your engagement is reused in another client's testing.
Begin with a scoping session.
Ninety minutes against your architecture. No commercial commitment, and no material leaves your environment.
contact@averon.systems