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, you can optionally layer two orchestrators 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.

• Neo is the optional planning macro-orchestrator. It decomposes a goal into a structured plan — the tasks, their order, and the tools each step needs.
• Kronus is the optional execution macro-orchestrator. It carries the plan out step by step, dispatching tools and models, then feeds results back so the plan can adapt.

When enabled, Neo and Kronus form an agentic loop: plan, execute, observe, and re-plan until the goal is met. "Supercomputer" describes the orchestration role each plays 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 patented 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 (v0.9.8). Capabilities, model availability, and protocol behavior may change between minor 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. Aether services never see plaintext vault contents.
• 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.

Questions about scope, deployment, or red-team engagements? Contact the security team.