The protocol stack,
written down.

Aether Security is the defensive and adversarial validation layer for AetherSystems infrastructure. It reduces infrastructure predictability, continuously tests the environment from an attacker’s point of view, and produces verifiable security evidence for operators and auditors.

The protocol stack is organized into four layers:

• Ghost — rotation and exposure reduction.
• Scrambler — controlled mesh route randomization.
• Predator — autonomous red-team validation.
• Attestation Ledger — signed security evidence and audit records.

Aether Security does not claim infrastructure becomes unhackable or impossible to observe. Its purpose is to make systems harder to map, harder to rely on as static targets, and easier to validate continuously.

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.

Moving Target Defense (MTD) is Aether's dynamic routing security stack. Instead of presenting attackers with fixed, predictable infrastructure, MTD continuously changes how services are exposed and how internal traffic is routed, so a map of the system goes stale before it becomes a durable advantage.

In practice, MTD combines controlled rotation of exposed surfaces with randomized internal paths across trusted nodes, validated continuously by authorized adversarial testing. The detailed rotation and routing semantics are documented in the protocol sections below (Ghost, Scrambler, and Predator).

Quantum-Constrained AI (QOPC) is a patent-pending 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 layers Moving Target Defense (rotation and randomized routing), authorized autonomous red-team validation, and 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 reduce static exposure, continuously test controls from an attacker's point of view, 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 three principles:

• Rotate what should not remain predictable.
• Randomize internal paths where static routing creates risk.
• Continuously test the system using authorized adversarial automation.

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

Ghost is the exposure-reduction layer. It rotates selected service mappings, internal routes, temporary aliases, tunnel bindings, and short-lived access surfaces so sensitive infrastructure does not remain fixed longer than necessary.

Ghost is not magic invisibility — it is controlled rotation for systems where static exposure increases risk.

What Ghost protects

• Public gateway mappings
• Internal service aliases
• Temporary tunnels
• Short-lived service tokens
• Reverse-proxy upstream mappings
• Blue-green handoff routes
• Decoy or retired endpoint monitoring

Ghost should not rotate critical persistent assets (primary domains, database identities, root signing keys, long-lived customer-facing URLs) unless the system has a safe handoff and rollback policy.

Rotation strategy

1. Prepare the replacement route or alias.
2. Health-check the replacement target.
3. Run both old and new routes during an overlap window.
4. Shift traffic to the new route.
5. Retire the old route.
6. Watch the retired route for suspicious reuse.
7. Record the completed event in the attestation ledger.

Defensive value

Ghost reduces the value of stale reconnaissance. If an attacker maps an endpoint, token, alias, or internal route, that mapping should expire before it becomes a durable advantage.

Claim: Ghost reduces static exposure by rotating selected service surfaces through controlled, health-checked handoffs.

Scrambler is the controlled mesh-randomization layer. It changes how traffic moves across trusted Aether-controlled nodes so internal service paths do not remain static.

Scrambler is for trusted mesh environments. It is not a public anonymity network.

What Scrambler does

Route decisions can consider node health, service sensitivity, region, latency, current load, trust tier, recent path usage, maintenance state, and rotation events triggered by Ghost or Predator. The goal is to reduce predictable internal routing while preserving reliability.

Route policy

A practical route policy:

scrambler:
  enabled: true
  minHops: 2
  maxHops: 4
  avoidRecentPaths: true
  recentPathWindow: 10m
  requireHealthyRelays: true
  latencyBudgetMs: 250

Conservative by design. More hops can increase privacy properties inside a controlled mesh, but they also increase latency and operational complexity.

Cryptographic sessions

Where relay encryption is enabled, each session uses fresh session keys. X25519 (RFC 7748) is the elliptic-curve Diffie-Hellman key agreement mechanism. Scrambler derives traffic keys from ephemeral key exchange material bound to both participating peers — limiting the value of captured session material.

Claim: Scrambler reduces static routing patterns across trusted Aether mesh nodes.

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 routes still respond after rotation?
• 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
• Mesh route resilience checks
• Detection-trigger validation
• Ghost rotation validation
• Scrambler path-change validation

Adversary emulation

Predator models realistic attacker behavior using structured tactics, techniques, and procedures (per MITRE ATT&CK methodology). Validation focuses on Aether’s actual controls: did Ghost rotate the targeted route, did Scrambler refresh the path, did monitoring catch the behavior, did retired endpoints stop accepting traffic, 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

• Ghost rotations
• Scrambler route changes
• Predator tests
• Predator findings
• Counter-rotation events
• 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 rotation, 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

• Aether reduces static exposure through controlled route and alias rotation.
• Ghost makes stale reconnaissance less useful.
• Scrambler reduces predictable internal routing across trusted mesh nodes.
• Predator performs authorized autonomous 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 the Ghost / Scrambler / Predator / Ledger stack 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, deployment, or red-team engagements? Contact the security team.