The ACSE Control Plane — Operating Surface Mutation at Estate Scale

Abstract

The Polymorphic Mutation Engine (PME) enforces the Kali Invariant on a single node; ASMP/1.0 coordinates that enforcement across an estate. Neither, on its own, is something an enterprise can operate. The ACSE Control Plane is the fourth architectural layer — the management surface through which operators discover assets, onboard them into the catalog, monitor live state, set policy, integrate with existing security infrastructure, and produce a tamper-evident record of every action.

This paper covers Control Plane v0.3.0. It specifies TEE-attested authentication and RBAC, the live estate dashboard, the Auto-Discovery pipeline (22 source types), the zero-config agent self-registration mechanism, the push protocol, outbound firewall and SIEM integration, the policy engine and estate REST API, and the cryptographic audit chain — followed by deployment, operations, and the v2 roadmap.

1. From Engine to Operable System

A mutation engine that no one can deploy, monitor, or audit is a research artifact, not a product. The journey from PME to a fielded defence runs through a set of unglamorous but decisive operational requirements: how do you discover the hundreds of assets that need protecting? How do you watch their state in real time? How do you change policy across an estate without touching every node by hand? How do you feed events into the SOC's existing SIEM? And how do you prove, later, exactly what happened and who authorised it?

The Control Plane answers each of these. Crucially, it does so without weakening the security model of the layers beneath it. A management plane is the highest-value target in any system — compromise it and you inherit the estate. The Stryker–Handala wiper attack of March 2026 is the canonical example: the attackers did not break encryption, they weaponised the victim's own MDM management console to issue estate-wide wipe commands.

2. Control Plane Architecture

The Control Plane sits atop the three runtime layers — PME, ASMP/1.0, and the eleven domain profiles — as the operator-facing management layer. It is a single Rust binary (acse-cp) backed by PostgreSQL, exposing a REST API on port 9000 and the pme-console live dashboard, with four families of connectors: inbound discovery, inbound agent push, outbound firewall orchestration, and outbound SIEM dispatch.

3. TEE-Attested Authentication & RBAC

Authentication in the Control Plane is two-factor in the architectural sense: an operation requires both an authenticated identity with sufficient role and a fresh hardware attestation. The attestation mechanism is ASMP message MSG-005, which binds a management trust token to a Trusted Execution Environment quote. The token's time-to-live is exactly one mutation cycle — it cannot be replayed against a later surface.

3.1 Role-Based Access Control

• Admin — full estate authority: policy changes, node registration, profile assignment, connector configuration, user management.
• Operator — day-to-day operations: trigger defensive leaps, acknowledge anomalies, run discovery, configure SIEM and firewall adapters, read all state.
• ReadOnly — observation only: dashboard, audit chain, and reports, with no mutating operations.

3.2 The Five TEE Adapters

Selecting an adapter is a one-line change at construction; all Control Plane logic is adapter-agnostic.

4. The Estate Dashboard

The pme-console dashboard presents a live organ-state view across every registered node, refreshing every five seconds. It is the operator's primary situational-awareness surface, and the same data is available programmatically through the REST API (GET /v1/estates).

Asset rows are auto-classified — firewall, server, or network device — so an operator can tell at a glance which surfaces are under which profile, and which discovered nodes are still awaiting onboarding.

5. Auto-Discovery — 22 Source Types

Most deployments stall at inventory: nobody has a complete, current list of the assets that need protecting. Auto-Discovery removes that obstacle by enumerating the estate from the identity and network systems an organisation already runs — then cataloguing, classifying, and suggesting the appropriate mutation profile for each asset.

v0.2.2 ships with 22 source types across six categories, up from 6 in v0.1.0. The expansion covers HCI management planes (Nutanix, Cisco UCS, VMware vCenter, Azure Stack HCI) and storage fabric controllers (Pure Storage, NetApp ONTAP, Dell EMC, Brocade FC, Cisco MDS, Ceph) — surfaces that carry catastrophic blast radii and have historically been protected by static, never-rotated credentials.

6. Estate Catalog — Discover → Decide → Protect

Every node discovered by any source lands in the discovered_nodes catalog table. The catalog is the intermediate state between "found" and "protected." The admin reviews, approves, and clicks Protect — the Control Plane creates an estate and api_key automatically.

The POST /v1/discovery/catalog/:id/protect endpoint returns the estate record, api_key, and platform-specific install instructions in a single response — the operator copies the key to the node, installs the agent, and that node is under the Kali Invariant within minutes.

7. Estate Lifecycle

An estate is the Control Plane's representation of a protected node. It is the join point between the PME agent (which executes mutations) and the Control Plane (which aggregates, dispatches, and monitors).

1. Registration: POST /v1/estates (manual) or via catalog Protect (auto). Returns a per-estate api_key — shown once, SHA3-256 hash stored only.
2. Agent push: The PME agent calls POST /v1/estates/:id/push every 30 seconds with mutation count, EWMA score, organ state, and audit records.
3. SIEM dispatch: On every push, the bridge module dispatches CEF-formatted events to all configured SIEM sinks.
4. Firewall sync: When a TorpedoRay surface mutates, the CP pushes the new channel fingerprint to connected firewall adapters automatically.
5. Audit chain: Every mutation record is appended to the estate's SHA3 audit chain in PostgreSQL. Each record contains the SHA3-256 hash of its predecessor — the chain is tamper-evident.
6. Kali Invariant: The CP continuously checks that every active estate is in a valid mutation state. A violation (estate offline, chain gap) flags the global invariant.

8. Agent Self-Registration — New in v0.3.0

Self-registration is the zero-config deployment model introduced in v0.2.1. It eliminates the manual register-then-install workflow for large fleets: set a pre-shared registration token on the CP and on each agent. On first boot, the agent registers itself and receives its api_key.

The self-register endpoint is the only /v1/ path that is public (not behind the Bearer auth middleware). It is disabled by default — only enabled when ACSE_REGISTRATION_TOKEN is set on the CP. This makes it opt-in and auditable.

9. Agent Push Protocol

The PME Agent pushes its status to the Control Plane every ACSE_PUSH_INTERVAL_S seconds (default: 30). The push is a single authenticated POST with the estate's api_key as a Bearer token.

POST /v1/estates/:id/push
Authorization: Bearer acse_XXXXXXXXXXXXXXXXXXXX
Content-Type: application/json

{
  "organ_state":    "sachs",
  "ewma_score":     0.08,
  "torpedo_count":  0,
  "mutation_count": 2880,
  "transport_mode": "asmp",
  "audit_records": [
    {
      "cycle_seq":           2880,
      "surface_fingerprint": "sha3hex...",
      "record_hash":         "sha3hex...",
      "tee_signature":       "base64...",
      "trigger_reason":      "timer",
      "mutation_result":     "success"
    }
  ]
}

On receiving a push, the CP: (1) updates estate_live_status in PostgreSQL, (2) appends audit records to the SHA3 chain, (3) dispatches CEF events to all enabled SIEM sinks, (4) checks the Kali Invariant. Response: {"status":"ok"}.

10. Firewall & SIEM Integration

10.1 Firewall Orchestration

When a protected surface mutates, the perimeter must follow — otherwise the firewall rule references an identity that no longer exists. The Control Plane pushes the updated surface identity to connected firewalls automatically, so policy stays coherent across every mutation cycle.

10.2 SIEM Dispatch

Every mutation event and every Torpedo firing is dispatched to the SOC's SIEM, enriched with node, profile, organ state, and audit-chain references so analysts have full context without leaving their console.

11. Policy Management & the Estate REST API

Policy is defined per estate and applied across nodes in a single call: mutation schedules, EWMA thresholds that govern organ-state transitions, and the active profile for each class of asset. The REST API is the substrate for everything — the dashboard, automation, and third-party integrations all speak to it, and every privileged route carries the RBAC + TEE attestation gate described in Section 3.

# Assign a profile across an estate (Admin role + TEE token required)
POST /v1/estates/{estate_id}/policies/{policy_id}

# Create a policy
POST /v1/policies
{
  "name":              "production-default",
  "schedule_secs":     30,
  "ewma_threshold":    0.70,
  "hunter_threshold":  0.35,
  "active_profiles":   [11]
}

# Trigger an estate-wide defensive leap (Operator role)
POST /v1/invariant/leap

# Read live estate state (any role)
GET  /v1/estates/{estate_id}

# Browse discovery catalog
GET  /v1/discovery/catalog?status=discovered&node_type=windows_server

# Protect a discovered node
POST /v1/discovery/catalog/{id}/protect

Policy changes are themselves audited — a policy change is a privileged operation and appears in the audit chain alongside the operations it governs.

12. The Cryptographic Audit Chain

The audit chain is the Control Plane's answer to "what happened, and who authorised it?" Every mutation event and every management operation from every node is aggregated into an append-only log, persisted in PostgreSQL, with each entry cryptographically linked to its predecessor by a SHA3-256 hash — the same chaining property as ASMP MSG-001. Removing or altering any entry breaks every subsequent hash, making tampering detectable rather than merely discouraged.

The chain is exposed through a paginated REST API designed for compliance review, incident forensics, and regulatory reporting — the evidentiary spine for SEC, NIS2, DPDP, CERT-In, and HIPAA obligations.

The chain is TEE-signed at each mutation cycle — every entry carries a hardware attestation quote that links the mutation record to the physical enclave that produced it. This makes the chain verifiable not just for integrity (SHA3 chain) but for authenticity (TEE quote chain).

13. Deployment & Operations

The Control Plane ships as a single binary with platform-native installers, so it drops into existing enterprise estates without bespoke packaging.

Operationally, the Control Plane is designed to sit alongside an existing stack — firewalls, EDR, SIEM, Zero Trust — rather than replace any of it. It makes those tools more effective by ensuring the surfaces they protect are no longer static.

14. Roadmap — Control Plane v2

v0.2.2 establishes the full operable core including Auto-Discovery, self-registration, and the HCI/Storage Wave 2 connectors. v2 extends toward multi-tenant operation, richer analytics, and executive-grade reporting. The flagship v2 deliverable is the Reporting Module — ACL-scoped historical reports covering EWMA spikes, attack/defence timeline, and audit-log extracts formatted for CISO-level review and compliance submission.

15. Patent Claims Coverage

The Control Plane contributes directly to multiple claims in Patent IN202641070690:

• ACSE Control Plane (ACSE-CP): The Control Plane itself is claimed as a core component of the patented system — the management layer that makes the PME estate operable.
• Estate management and profile assignment: The mechanism by which profiles are assigned to estates and the Kali Invariant is enforced estate-wide.
• ASMP/1.0 MSG-005 — Management Binding: The TEE-attested two-gate authentication directly evidenced by the Stryker MDM weaponisation case. Admin credential (necessary) + TEE-attested token (sufficient). ProVerif confirms CORRECT under Dolev-Yao.
• Tamper-evident audit chain: The SHA3-256-chained, TEE-signed audit chain stored in PostgreSQL constitutes the forensic record claimed in the patent — cryptographic proof that is admissible as compliance evidence.
• Auto-Discovery with profile suggestion: The 22-source discovery engine and automated profile assignment are novel contributions. No prior art exists for cryptographic surface mutation profile assignment from enterprise discovery data.
• Agent self-registration protocol: The zero-config deployment mechanism using a pre-shared registration token to bootstrap a TEE-bound estate key is a novel architectural contribution to the estate management domain.

16. Conclusion

The Control Plane completes the ACSE stack. The four-layer architecture — Control Plane, PME, ASMP/1.0, and the eleven domain profiles — is now operable end to end: an estate can be discovered (22 source types), catalogued, onboarded (manually or zero-config), monitored, governed by policy, integrated with existing security infrastructure, and audited, all under a management plane whose every privileged operation is hardware-attested.

The same invariant that protects the data plane now protects the management plane. The map an attacker builds expires before they can act on it — and the console they would weaponise rejects them at the protocol layer because a valid TEE attestation quote is the second gate, and that gate closes on every mutation cycle.