The protocol stack,
written down.

Aether Security is Predator — authorized offensive validation — together with the attestation layer that records its evidence. Predator tests systems from an attacker’s point of view, inside a written scope, and the attestation ledger makes the resulting security evidence verifiable for operators and auditors.

Predator is offered three ways:

• Predator Red Team — operator-led, scoped testing of live, authorized infrastructure (live engagements).
• Predator Strikes — fixed-scope missions on one authorized repository (repository missions).
• Predator Security Check — a locked assurance operation on one exact commit, run on Aether Actions.

Aether Security does not claim infrastructure becomes unhackable. Its purpose is to find what an attacker could use, within an agreed scope, and to leave evidence that can be checked afterwards.

The Protocol Family is the cryptographic foundation that secures everything Aether AI builds. It is a set of complementary commitment and attestation protocols — Protocol-C, Protocol-L, and Protocol-T — each addressing a different trust requirement, from zero-cost classical commitments to quantum-authenticated commitments and hardware-enclave execution attestation.

For the full breakdown of each protocol — what it does, how it is built, and where it applies — see the dedicated Protocol Family reference.

Aether Cloud is a desktop-native AI coding environment built for fast, easy coding — in the same family as tools like Cursor and Lovable. At its core is an editor where you select frontier LLMs (such as Claude, GPT, and Gemini) directly in-editor with conventional routing, and assemble custom model teams so different models handle different kinds of work. Aether Cloud routes work across these frontier models without retraining or modifying their weights.

For larger, multi-step work, Aether Cloud exposes two orchestrators you can optionally layer on top of that direct frontier-LLM routing. They are off by default: you can use Aether Cloud purely as a fast in-editor coding environment and never turn them on. Which of them your account sees depends on your plan and on deployment configuration.

• Neo is the optional bounded macro-orchestrator, decomposing a goal into a structured plan — the tasks, their order, and the tools each step needs — and carrying it out across everyday projects.
• Kronus is the wider frontier orchestration system for larger, more demanding multi-agent work, carrying a plan out step by step, dispatching tools and models, then feeding results back so the plan can adapt.

Once shipped and enabled, Neo and Kronus are designed to form an agentic loop: plan, execute, observe, and re-plan until the goal is met. "Supercomputer" describes the orchestration role each is intended to play inside Aether Cloud — it is positioning for the orchestration tier, not a claim about specialized hardware.

Underneath everything, Aether Cloud is secured by an app-wide cryptographic commitment chain. The chain of custody does not stop at the orchestrators — it spans every model and every function of the app: chat, workflows, projects, the vault, and updates. It is built on Protocol-C (zero-cost classical commitments from OS kernel entropy, CSPRNG), so the security layer is the same whether you are coding directly with a single model or running an autonomous multi-step task.

Aether no longer offers Scrambler, Ghost or the moving-target-defense plans built on them (Shield, Fortress and defensive Enterprise). They are not sold, and this page no longer documents them as a product. The idea behind them — making a map of a system go stale before it becomes useful to an attacker — is described in an archived research note.

If you have an existing agreement for one of these services, contact us and we will handle it directly.

Quantum-Constrained AI (QOPC) is a research approach in which quantum-derived constraints guide Aether Cloud's routing and decisioning. The AI doing the routing and decisioning is classical; the constraints that bound its choices are quantum-derived.

To be precise about what QOPC is and is not: Aether Cloud does not run on a quantum computer, and the orchestrator's reasoning is classical software. QOPC applies quantum-derived constraints as guardrails over that classical decisioning — for example, to shape which model handles which class of work and how budgets and policy are applied — and records those choices in the attestation ledger.

At a high level, Aether's security model assumes infrastructure is always being observed and that no single control is sufficient on its own. It pairs authorized red-team validation with tamper-evident attestation, so that meaningful security events are recorded as signed, verifiable evidence.

Aether does not claim systems become unhackable. The goal is to test controls from an attacker's point of view, within an agreed scope, and produce evidence operators and auditors can verify. The sections below describe each layer in detail.

Aether assumes modern infrastructure is always being observed. Attackers may scan public endpoints, enumerate DNS records, monitor certificate issuance, test expired routes, probe authentication surfaces, or correlate service behavior over time.

Aether responds with two principles:

• Test the system the way an attacker would, only within authorized scope.
• Record what was tested and what was found so it can be checked later.

Every meaningful security event is recorded as a signed receipt. Receipts can later be grouped into tamper-evident audit bundles.

Predator is Aether’s autonomous red-team and adversarial validation layer. It does not merely detect threats — it actively tests Aether-controlled systems the way a real attacker would, within authorized scope.

Predator is offensive security automation with guardrails. It exists to find weaknesses before hostile actors do.

Purpose

Predator continuously asks:

• What can be discovered from the outside?
• Which endpoints are exposed?
• Which authentication paths are weak?
• Which services leak metadata?
• Which controls fail under realistic adversarial pressure?
• Which detections actually fire when attack behavior appears?

Authorized scope

Predator only operates against systems owned by Aether or explicitly authorized by the customer. Every engagement runs inside an explicit scope model with defined permissions, constraints, and approval boundaries — destructive testing and credential stuffing are off by default, rate limits are respected, and an emergency stop is always available.

Red-team modules

• External exposure discovery
• DNS and subdomain visibility checks
• Retired route validation
• Authentication surface testing
• Token replay resistance checks
• Header and metadata leakage checks
• Rate-limit validation
• Service misconfiguration checks
• Detection-trigger validation

Adversary emulation

Predator models realistic attacker behavior using structured tactics, techniques, and procedures (per MITRE ATT&CK methodology). Validation focuses on the controls in scope: did monitoring catch the behavior, did retired endpoints stop accepting traffic, did authentication hold, did the ledger record the event.

Safety controls

• Written authorization required
• Explicit asset scope
• No third-party targets unless authorized
• No destructive payloads by default
• No persistence implants
• No data exfiltration
• Rate limits enforced
• Production-safe test modes
• Emergency stop available
• Every action logged

Findings

Predator findings are clear and actionable. Each finding carries a severity, a plain-language summary of what was observed and why it matters, the supporting evidence, and a recommended remediation — written so an operator can act on it without digging through raw logs.

Claim: Predator performs authorized autonomous red-team validation against in-scope Aether-controlled assets. Predator does not hack back, does not attempt attacker attribution, and does not act against external systems.

The attestation layer records important security events as signed receipts so operators can prove what happened without relying solely on mutable logs. Receipts are signed with Ed25519 (RFC 8032).

Attested events

• Predator tests
• Predator findings
• Policy changes
• Ledger digest creation
• Operator acknowledgements
• Emergency stops

Receipt structure

Each receipt links the event to the one before it with a hash chain and is signed, so any later tampering is detectable. Receipts never store secrets, raw credentials, sensitive customer data, or unnecessary payload contents.

Key handling

Entropy

Aether uses cryptographically secure randomness from the host operating system for session and signing workflows. Hardware entropy sources are supported on enterprise deployments where available.

The commitment ledger groups signed receipts into tamper-evident audit records, proving security events were recorded consistently and not silently modified later.

Digest model

At a configured interval, Aether collects receipts into a signed digest covering a time range, using a Merkle tree that provides efficient inclusion proofs for any individual receipt. When external timestamping is enabled, the digest carries an RFC 3161 trusted timestamp token so the record can be verified against an independent time authority.

Audit value

The ledger helps answer: was the event recorded, when, by which node, is the receipt included in a later digest, has it changed since digest creation, can an auditor verify the evidence independently. The ledger supports audit evidence — it does not automatically make an organization compliant.

Aether does not modify any models beyond the QOPC (Quantum-Optimized Policy Compute) learning architecture. Frontier models accessed through Aether — Claude, GPT, Gemini, DeepSeek — are routed and orchestrated by the QOPC layer, not retrained or fine-tuned by it. Aether’s self-improving structure operates on routing policy, token budgets, and tool dispatch — never on vendor model weights.

QOPC chooses which model handles which class of work, applies budget envelopes, and records the choice in the attestation ledger. Model providers see the same model API surface they always have; Aether owns the policy layer above it.

Strong claims

• Predator performs authorized red-team validation against in-scope assets.
• Aether records important security events as signed receipts.
• The commitment ledger makes security evidence tamper-evident.
• Aether is designed to support continuous security validation, not one-time assessment.

Compliance-safe claims

• Aether can support audit workflows by producing signed security evidence.
• Aether receipts may help demonstrate control activity during security reviews.
• Aether’s ledger can provide evidence useful for SOC 2, ISO 27001, NIST, and internal governance programs.
• Final compliance mapping depends on the customer environment, policies, scope, and auditor review. NIST SP 800-53 provides a control catalog — alignment to that catalog is not the same as certification.

Things Aether does not claim

• “Unhackable.”
• “Impossible to trace.”
• “Quantum-secure.”
• “Predator hacks attackers back.”
• “Predator identifies the real attacker.”
• “Every node uses HSM-backed signing.”
• “Certified QRNG entropy.”
• “Automatically SOC 2 / ISO 27001 compliant.”
• “Public timestamping is enabled by default.”
• “No relay can ever see source or destination.”

AetherCloud is in active beta and active development (release notes). Capabilities, model availability, and protocol behavior may change between releases.

• Model availability. AetherCloud is not obligated to provide access to frontier models that are not part of the agreed plan. Model lineup per tier is the current default, not a contractual guarantee — vendor outages, deprecations, or policy changes upstream may temporarily restrict access.
• Model behavior. Aether does not modify any frontier models beyond the QOPC learning architecture. QOPC orchestrates routing, budgets, and tool dispatch — it does not retrain or fine-tune vendor weights.
• Token consumption. Customers are responsible for monitoring their own token consumption. Aether provides per-plan token meters, but operators using autonomous agents or scheduled automations should configure their own budget envelopes. Aether is not liable for incidental token spend caused by user-configured automations.
• Data handling. AetherCloud operates a zero-trust vault model. We do not store, mirror, or train on customer files outside the customer’s own vault scope. Vault contents stay on customer-controlled infrastructure (local-first by default) and are referenced through scoped, revocable handles. When you invoke an AI action, relevant file content is sent as context to the model provider you've selected (Claude, GPT, DeepSeek, etc.) for that call only. Aether commits a cryptographic seal to the audit chain for each response; sealing is additive — in the rare case a seal can't be completed, the response still completes rather than being blocked, but a missing seal is itself logged and visible in your audit trail.
• Security incidents. Aether provides Predator services and the attestation ledger on a best-effort basis. No security product can guarantee prevention of every breach. Aether is not liable for damages arising from system compromise where the cause originates outside the Aether attack surface (e.g. third-party credential leaks, customer-side misconfiguration, social-engineering attacks against operators).
• Contractual primacy. The customer’s signed enterprise agreement, MSA, or Order Form takes precedence over the language on this page. This page is documentation, not a contract.

Aether Actions runs work against one exact commit of a connected GitHub repository on Aether infrastructure. Every run is quoted first and executes only after you explicitly authorize a maximum UVT spend. Connecting GitHub does not authorize spend.

Two products run on it: Aether Hosted Build & Test, which runs your project’s configured checks, and the Predator Security Check, a locked assurance operation described below. Hosted Build & Test does not require a Predator assurance profile, but repository availability is still controlled by the deployment.

Four different things share the name. They are not interchangeable:

Aether Actions — The repository execution plane.

Runs work against one exact commit of a connected GitHub repository on Aether infrastructure, with a quote and an explicit spend authorization before anything executes.

Predator Security Check — A locked exact-commit assurance operation that runs on Actions.

Replays 5 registered security assurance routes (54 checks) against one commit under a versioned assurance profile. The operation, routes, catalog, and price are server-owned and cannot be edited by the repository or its owner.

Predator CLI — Deeper local software analysis.

A separate tool. It is not the hosted Check, does not run on Aether infrastructure, and does not issue the same evidence.

Predator Red Team — An operator-led live engagement.

Human-run, scoped and scheduled with the Aether team. Not automated and not purchasable with UVT.

The real path, end to end. Every step below exists in the product today — there is no local Predator execution, and no step depends on a capability listed as in development.

1. Connect GitHub. Open Aether Actions and connect the GitHub App. You choose which repositories it can see. Connecting authorizes access, not spend.
2. Select a repository. Only repositories your installation grants are listed.
3. Read the compatibility answer. Aether checks whether an approved assurance profile covers the repository before offering a run. If none does, you get an onboarding route instead of a button that would fail — and no charge for asking.
4. Configure .aether-ci.yml for Build & Test. Hosted Build & Test runs the checks this file declares. The Predator Security Check does not read it — its operation is locked.
5. Resolve the exact commit. Aether resolves the branch head to a full commit SHA and verifies that exact revision. Nothing is verified “on the branch”.
6. Review the estimate and the maximum UVT. The quote names an estimate, a hard maximum, and the profile that will run.
7. Authorize. Nothing executes and nothing is reserved until you confirm that maximum. For a manual browser run, a changed assurance profile or a newly required maximum above the ceiling you approved triggers a fresh quote and another confirmation.
8. Read the results. In Aether you get the run view and an integrity-checked, digest-bound report; in GitHub you get a Check on the commit, naming the profile and revision that produced it. See Reading a result — “did not verify” is not a finding.
9. Turn on automation and set a ceiling. In Actions settings, enable pull-request or push runs and set a maximum UVT per run. Automation stays off until you do; it is never inferred.
10. Fix, rerun, verify. Push the fix and run again against the new commit. Each result is bound to its own revision, so a fixed commit needs its own run.

This table is built from the same source the product uses, and a test asserts it against the runtime. If a capability is not listed as Production, do not plan around it.

Predator does not verify arbitrary repositories. The current verifier is specific to the AetherCloud backend surface, so a repository without an approved assurance profile is refused before any UVT is reserved — it costs nothing to find out.

An assurance profile is Aether’s versioned, digest-bound description of one qualified verification product: which repositories it covers, which routes it replays, which catalog it references, and what evidence it produces. You select a profile by name. You cannot supply an executor image, commands, environment, route implementation, verdict reducer, catalog, or price — those are the security boundary, and they are server-owned.

The profile in production is aethercloud/core, revision 1.0.0: 5 registered routes and 54 locked checks against the AetherCloud backend surface. Its identity, revision, and digest travel with the run through the quote, the report, the GitHub Check, and the run view, so a result always says which product produced it.

Before a quote, Aether answers a compatibility preflight for your repository and commit:

• Supported — an active profile covers this repository.
• Onboarding required — no approved profile covers it yet. You can request one; there is no automatic support and no committed turnaround.
• Unsupported — this commit does not contain the surface the profile verifies, or the profile has been retired.
• Temporarily unavailable — capacity, configuration, or GitHub is unavailable right now. Nothing was reserved; retry later.

Runs recorded before assurance profiles existed remain readable and are labelled legacy. They are not retroactively relabelled with a profile they did not run under.

A Predator result is not a pass/fail badge. Three outcomes look similar from the outside and mean very different things:

• A finding — a registered route detected a real violation at this commit. This is the only outcome that is a security result about your code.
• Did not verify — a route could not complete. This is not a finding, and Aether reports it as non-blocking rather than red, because a check that is red for infrastructure reasons teaches reviewers to ignore it.
• Did not run — no route executed at all: no runner was available, the run timed out in the queue, or authorization was refused. Nothing was verified.

A clean result verifies the registered routes at one exact commit. It is not a statement that the repository is free of vulnerabilities, and it does not extend to any other commit.

Every run is quoted before it starts. The quote states an estimate and a maximum UVT; you authorize that maximum explicitly, and the server — never the worker or the repository — owns the rate card. A worker can report resource facts but cannot select or increase a price.

• Connecting GitHub authorizes no spend.
• Automation stays off until you save Actions settings with a maximum UVT per run.
• A refused or unsupported run reserves nothing and charges nothing.
• For a manual browser run, a changed assurance profile or a newly required maximum above the ceiling you approved triggers a fresh quote and another confirmation.

The properties that make a result meaningful:

• A repository cannot select or replace the executor, image, commands, route catalog, verdict reducer, or price.
• A repository process cannot write its own successful verdict.
• The report is integrity-checked and digest-bound to an exact revision, a verifier identity, and a route catalog.
• A real route violation stays a security finding even when the worker’s terminal state is a failure.
• A route error, unavailable runner, timeout, or billing refusal is never presented as a security finding.
• The accepted execution receipt remains an immutable historical fact; the product outcome shown to you is a separate projection of it.

Questions about scope, a repository mission, or a red-team engagement? Contact the security team.