Vulnerability verification with proof of exploitability, decompilation of binaries with no source, and control of your communication perimeter — without binaries, findings or mail ever leaving your network.
In security analysis a language model hallucinates in a way that is worse than silence: an invented vulnerability burns a day of the team's work, a missed one kills the audit. That is why in AE the model never speaks to the user directly.
Disassembler, static analysis, signatures, symbolic execution, reachability checks. Deterministic, fast and explainable — but brittle, with weak recall on patterns it has never seen.
Generalises, names things, reconstructs the intent of code and the connections heuristics cannot see. Its statements, however, are unverifiable on their own.
Recompilation and semantic comparison, proof executed in an isolated sandbox, a verifiable fact from DNS and your records. Decides deterministically whether the hypothesis holds.
A tool with no way to say “I don't know” is lying. The third state is therefore a deliberate part of the design, not a gap.
The oracle passed and evidence exists — the recompiled code behaves identically, the proof actually ran in the sandbox, the fact matches your records. The output stands up as audit evidence.
The oracle showed the finding does not hold — the vulnerable code is unreachable, the version does not match, the configuration rules the problem out. The false positive is closed with a reason.
The oracle reached no conclusion. The finding goes to a human together with what was established and where the analysis hit a wall. No silent conclusions, no filling gaps with guesses.
Every engine rests on the same triad — heuristics, hypothesis, verification. They differ in their input and in what serves as the oracle.
A finding from a scan or pentest is checked for version, configuration and reachability; the model proposes an exploitation path and a proof; that proof runs in an isolated sandbox against a clone of the target. The result is not a score but proof or refutation — and a recalculated residual risk.
A binary with no source — vendor firmware, a legacy component, a suspicious executable. The model reconstructs names, types and the intent of functions; the oracle recompiles the result and compares it with the original. The output marks what is verified and what is an estimate.
An inventory of channels, control of what comes in and what goes out. Payment-detail fraud, look-alike partner domains, attachments detonated in a sandbox, data leaving through an unapproved channel. In detail below →
What a vendor patch actually fixes and whether it concerns you. A binary diff before and after, matched against your component inventory. The answer to the question that costs hours with every bulletin — must we patch now, or are we not affected.
First-line triage of security alerts through the same harness. A claim about an alert must agree with an independent telemetry source; otherwise it is marked unproven and reaches the analyst with the context already gathered.
Review of your own code against your conventions and your libraries, not against a generic template. A finding counts only once there is a test case that reproduces the defect.
Translation of a technical finding into the language of cybersecurity law and its implementing rules, including entries in the statement of applicability and the risk analysis. The engineer does not write the documentation, they review it.
Communication is the largest and worst-mapped attack surface a company has — and the only channel that crosses the organisation's boundary in both directions every day. AE-COMM handles it on three levels.
Monitoring employee communication has hard limits — data protection, privacy of electronic communications, employment law and the case law of the European Court of Human Rights. If those limits are not built into the tool, it exposes the operator to sanction. In AE-COMM they therefore cannot be switched off:
The model is a replaceable part. What turns it into a usable tool is the envelope of classifiers in front of it and behind it — and a gate no change passes without evaluation.
Decides whether a task belongs to AE at all and to which engine. Prevents the tool from degenerating into a general-purpose chat over company data.
Keys, passwords and personal data are stripped before input reaches the model. The inputs are memory dumps, logs and configurations — material full of sensitive data.
AE's inputs are attacker-controlled — strings in malware, lines in a log, message content. An attempt to embed an instruction for the model must be caught before the model sees it.
Estimates cost and splits or refuses the task. Compute is a finite resource: it is planned, not spent.
Every claim must point to a specific place — an offset in the binary, a line of code, a record. A claim without an anchor is discarded.
Catches the shift from “possible” to “confirmed” without the oracle ever running. This is the most common way AI tools lie.
The model's score is converted into confidence calibrated against real historical accuracy. No “97 %” pulled out of the model.
The same task runs independently several times. Disagreement between runs means escalation to a human, not averaging the result.
No change to a classifier or the model reaches production without a run over an annotated set and a signature. A profile is either promoted, rolled back or rejected.
AE is not sold as software you install somewhere. It arrives as a sealed appliance, is plugged in and runs. The reason is not convenience but provability — if the client assembles the machine, nobody can attest what runs on it or whether the model weights ever left the node.
The compute node holding the model and the sandbox node are physically separate, not separated by configuration. Configuration separation can be undone by mistake — and an exploit running next to the model reaches the weights and your data.
The component list and their fingerprints are part of the delivery note. Opening the chassis is detectable.
Boot fingerprints are compared at every start. A mismatch is an event that gets acted on — not a quiet carry-on.
Disks and model weights alike. Keys are bound to the boot state, so a disk removed from the appliance is unreadable.
By default no outbound traffic except the secured administrative channel. In the closed variant, not even that.
Model, classifiers and firmware are signed and verified before loading. For closed environments there is a dedicated package on media — never “no updates at all”.
That an update really happened is verified by the fingerprint of the running version, not by an operator's report.
On a service replacement the appliance ships without its disks — they hold your data and the model. This belongs in the contract, not in a verbal agreement.
The appliance is sold or leased; the AE licence is bound to it by the same mechanism as Praetorix perpetual licences. Power draw and consumption are quoted up front — on the larger tiers it is a line item operations will notice.
For operators of regulated services and industrial control environments. The appliance has no link to the outside world; updates arrive as a signed package on media and are verified before loading.
The appliance runs in your network and we manage it over a secured administrative channel. Every unit has its own keys — nothing is shared between customers.
For organisations without their own hardware. It runs in your environment under your identity management; data stays within boundaries you define.
The core is mandatory; the remaining modules are bought according to what you actually need. The same principle as the Praetorix core — you pay for what you use.
The classifier harness, profiles and their evaluation, evidence records, integration with monitoring. Mandatory in every delivery.
The AE-VER engine and the sandbox for running proofs. Builds on the vulnerability register in Praetorix.
The AE-DEC engine with recompilation checking. For vendor firmware, legacy components and suspicious files.
The AE-TRIAGE and AE-PATCH engines. Build on continuous monitoring and the component inventory.
The AE-CODE engine over the organisation's own code, with a reproducible test for every finding.
The AE-DOC engine — turning findings into risk analysis, the statement of applicability and audit outputs.
The AE-COMM engine — channel inventory, control of inbound and outbound communication, including the impact assessment and template documentation.
No. The model runs on the Praetorix HW appliance at your site. By default the appliance has no outbound connectivity except a secured administrative channel — and in the closed variant not even that. Binaries, source code, findings and mail are never sent anywhere.
In AE the model never speaks to the user directly. It only produces hypotheses that a deterministic oracle must confirm — recompilation, a proof executed in the sandbox, or a verifiable fact from your records. A claim without evidence is not released. AE also has no open conversational mode and no right to act on production systems: it proposes an intervention, it does not perform one.
Every finding gets one of three states — CONFIRMED (the oracle passed, evidence exists), REFUTED (the oracle showed the finding does not hold) and UNPROVEN (the oracle reached no conclusion, the finding goes to a human). The third state is deliberate: a tool with no way to say “I don't know” is lying — and that is precisely why AI findings cannot be trusted.
No. The purpose is detection of cyber risk, not assessment of people — the tool has no performance-assessment function and will not be given one. The default mode processes metadata, not content; access to content requires a second approval and is recorded. Communication with legal counsel, trade-union and whistleblowing communication are excluded technically. A data protection impact assessment and template documentation for informing employees are part of the deployment.
If the client assembles the machine, we cannot attest what runs on it or how it boots. With a delivered appliance the whole chain is provable — a sealed assembly with fingerprints on the delivery note, measured boot, and encryption bound to the boot state. For a security tool this, not raw performance, is what the audit examines.
Praetorix governs compliance — records, risks, the statement of applicability and audit outputs. Vigil provides continuous monitoring. AE is the third layer: the technical analysis that turns a finding into a verified conclusion. AE findings feed the vulnerability register and the risk analysis. It can also be deployed on its own.
No, and it does not try to. It removes the routine — sorting false positives, first-round triage, transcribing findings into documentation — and hands over a substantiated basis. The decision stays with the human, and everything the oracle did not verify is handed over explicitly.
Fill in the form — we will open a tracked ticket and come back within 24 hours with a proposed date. We can build the demo around your own case: a finding from a scan, a binary with no source, or an overview of your communication channels.