AvalonX’s October 30, 2026 launch release describes Artemis, its AI-powered penetration-testing platform, as powered by Aether, a proprietary security model. For a developer evaluating the announcement, the first planning question is which product can actually be accessed.
Primary source: AvalonX’s October 30 release
Separate the model from the service
The current AvalonX website explicitly says Aether has no public API and no licensing, and exists exclusively to power AvalonX. The company describes Aether as a 400-billion-parameter model. That architectural claim is not an invitation to download weights, obtain a model key or run it in another application.
Primary source: Aether access statement and Artemis platform description
Artemis is the platform that orchestrates the model and testing agents. Access to a service that uses a model and access to the model itself are different requirements. The Aether statement should not be broadened into an unsupported assertion about every possible Artemis integration; platform integrations need their own documentation.
Try two fictional project briefs
Imagine Team A wants a security-testing service and a report for an environment it is authorised to assess. Team B wants to send prompts directly to Aether from its own software. These invented teams are asking for different deliverables, even if both put the same model name in a project title.
A’s requirement belongs in a platform evaluation. B’s requirement conflicts with the currently stated absence of a public model API. A platform demonstration would not, by itself, resolve B’s endpoint requirement. Neither example establishes that Team A qualifies for a service or that its proposed testing scope is accepted.
Put the access layer in the worksheet
For each proposed integration, record the object you need: a testing engagement, a report export, a platform integration or direct model inference. Then record the documentation that establishes access to that exact object. Leave the interface, permission and output format unresolved until there is a matching source.
A useful handoff describes the desired input and output without assuming an implementation. For example, an internal team could ask how an approved testing report would enter its issue tracker. That is a question about a reporting workflow, not evidence that a general-purpose Aether endpoint exists.
Ask the provider to identify the supported workflow, access requirements and limits for the intended use. Keep any answer dated. A sales conversation, a product demonstration and documented programmatic access should be recorded separately so another engineer can see which part of the plan is established.
Keep the evaluation within its actual scope
AvalonX’s site describes defining targets, exclusions, testing windows and escalation contacts before an engagement. A product announcement does not replace that process. This article does not authorise testing any domain or system, and no test was requested or run for this guide.
No Aether weights, model endpoint, platform integration or customer report was tested here. The company’s description establishes how it currently presents model access; it does not independently validate the model’s capability. Preserve that distinction when deciding what a prototype can rely on today.
Which Access Layer Do You Need?
