AXUMIS architecture

AXUMIS is the AI pentesting engine behind AXUM SEC's agentic testing. AXGNT orchestrates the engagement — planning, delegating to specialist agents, and consolidating what comes back. This document describes the architecture at the level needed to evaluate it.

Two ways to run the same engine

The engine, the evidence model and the finding structure are the same in both cases. What changes is where it executes and who operates it.

Orchestration

AXGNT is a planner and a dispatcher:

1. Plan — the engagement's scope, rules of engagement and objectives are turned into a test plan.
2. Delegate — specialist agents are assigned work: reconnaissance, authentication testing, injection classes, business-logic analysis, reporting.
3. Coordinate — the orchestrator sequences work so agents build on each other's results rather than repeating them, and holds shared context such as discovered endpoints and credentials.
4. Validate — candidates are re-tested before they are reported, so a finding that cannot be reproduced does not reach triage.
5. Consolidate — findings are normalised, severity-scored and drafted into the platform's report structure.

The agent team is visible while it works, so an operator can see what is being tested and stop it.

Why validation is central

Automated testing has a false-positive problem. AXUMIS addresses it by treating validation as part of the pipeline rather than as triage's burden:

• A candidate must be reproducible against the affected target.
• Evidence is captured at reproduction time, so the report carries proof rather than a description of intent.
• Findings that fail validation are retained internally as negative results, which informs later planning instead of surfacing as noise.

The evidence ledger

Every action taken by an agent is recorded in an append-only ledger: what was attempted, against which asset, what the response was, and which agent performed it. This is what makes an agentic engagement auditable:

• A finding can be traced back to the exact sequence that produced it.
• Evidence can be replayed to confirm a fix or to explain a decision.
• The boundary of what was tested is demonstrable — useful when someone asks whether an asset was really assessed.

Sandbox and containment

• Agents execute in a sandboxed environment with network reach limited to the engagement's scope.
• Egress to anything outside scope is blocked rather than discouraged.
• Credentials supplied to the engagement are held under the same controls as the platform's credential locker.
• Kill switches stop agent activity for the whole engagement or a single agent.

Exports and integration

• Findings land in the AXUM SEC tenant as ordinary findings — triaged, deduplicated, rewarded and remediated through the same workflows as any other source.
• Exports produce structured reports for engineering and, where required, compliance artefacts.
• AXUMIS-authored findings can be routed into Jira, GitHub, GitLab or Azure DevOps like any other. See Integrations.

What it does not replace

• Expert judgement on scope and risk acceptance. Agents propose; humans decide what is in scope and what the organisation accepts.
• Compliance attestation. Certification artefacts come from engagements with named testers, not from an automated run.
• Your own controls. The engine tests what you point it at; it does not change the state of your environment.

Availability and limits

• Managed AXUMIS testing is operated through AXUM SEC engagements.
• AXUMIS-LOCAL is designed for organisations that need testing to run inside their own perimeter, including air-gapped deployments.
• Automated testing complements crowd-sourced and expert testing; it does not replace the scheduled depth or the defensible evidence a formal engagement produces.

Related docs

• Platform overview — how AXUMIS fits alongside the two testing engines
• PTaaS engagement lifecycle — how an expert engagement is structured
• AI assistance — the assistance applied to triage and remediation