Autonomous Cyber-Physical Defense for Evulgare: Identity, Attestation, Evidence Integrity, Compromise Containment, Rekeying, Reconciliation, and Attested Recovery

1. Executive Summary

Modern cyber-physical systems and multi-tenant platforms face adversaries capable of subverting identities, manipulating software supply chains, and forging cryptographic evidence. The Evulgare platform requires a defensive architecture that shifts away from reactive perimeter defense toward a mathematically provable, cryptographically bound zero-trust environment. This report details the architectural design for an autonomous defensive system capable of continuous identity attestation, evidence integrity verification, automated compromise containment, and attested recovery.
Rooted in the IETF Remote ATtestation procedureS (RATS) framework1, SPIFFE/SPIRE workload identity2, The Update Framework (TUF) and Uptane for authority and epoch management4, and RFC 6962 Merkle tree verifiable logs6, this architecture provides a deterministic defense model. The system evaluates synthetic fault injections—such as FORGED_IDENTITY or COMPARTMENT_BREACH—and issues bounded autonomous responses ranging from ALLOW_OBSERVATION to SEVER_COMPARTMENT and RESTORE_ATTESTED_BASELINE.
This exhaustive specification provides schemas, behavioral invariants, Python pseudocode for core services, and a comprehensive synthetic cyber-range design to simulate and validate the architecture without employing offensive capabilities.

2. Capability and Traceability Statements

The architecture requires strict adherence to predefined constraints regarding operational boundaries and defensive scope. The following tables and declarations map the foundational requirements to the engineering outputs provided within this document.

2.1 Traceability Matrix

2.2 Defensive Capabilities Demonstrated

This architecture demonstrates the ability to cryptographically identify workloads via TPM 2.0 and SPIRE8, attest to the integrity of AI models using CycloneDX 1.6 and SLSA v1.010, manage distributed trust via TUF delegations5, and maintain tamper-evident audit logs via RFC 6962 Merkle trees13. It provides automated, reversible containment boundaries and threshold-based recovery protocols that mathematically prevent unauthorized state transitions.

2.3 No Offensive Capability Implied

This document contains zero offensive material. It does not provide exploit code, malware, ransomware, credential theft mechanisms, persistence techniques, evasion techniques, destructive payloads, unauthorized scanning instructions, real intrusion instructions, offensive command-and-control, weapon-control logic, or operational targeting. All adversarial behaviors are modeled exclusively as abstract, synthetic fault injections (e.g., TIME_SOURCE_DIVERGENCE, UNSIGNED_UPDATE).

2.4 What Requires Authorized Private Testing

Validation of this architecture requires authorized deployment within a closed, synthetic cyber-range. Interactions with physical TPM hardware, generation of real cryptographic keys, the deliberate injection of state faults (such as memory corruption or clock skew), and the execution of the Python pseudocode must be performed in isolated laboratories, not against production Evulgare domains, customer systems, or public networks.

3. Threat Model and 45 Synthetic Scenarios

The threat model operates strictly within the paradigm of non-kinetic compromise, assuming that adversaries may attempt to clone identities, replay stale authority tokens, tamper with models, or partition networks.

3.1 Bounded Defensive Framework

The defensive engine receives bounded abstract fault injections (e.g., FORGED_IDENTITY, COMPARTMENT_BREACH) and must respond autonomously using only approved, non-destructive, reversible outputs. These bounded outputs include: ALLOW_OBSERVATION, DENY_REQUEST, REQUIRE_REAUTHENTICATION, REVOKE_AUTHORITY, ISOLATE_WORKLOAD, SEVER_COMPARTMENT, QUARANTINE_SERVICE, FREEZE_RELEASE_CHANNEL, COLLECT_MORE_EVIDENCE, REKEY, RECONCILE, RESTORE_ATTESTED_BASELINE, and ABSTAIN.

3.2 Threat Scenario Matrix

4. Zero-Trust Workload Identity

Traditional network security models implicitly trust entities residing within a physical or logical perimeter. The Evulgare architecture discards this approach, adopting a model where identity is the primary boundary, established through rigorous cryptographic proof.

4.1 SPIFFE, SPIRE, and mTLS

The architecture utilizes the Secure Production Identity Framework For Everyone (SPIFFE) and its reference implementation, SPIRE2. SPIFFE provides a specification for issuing short-lived, automatically rotating cryptographic identities to workloads, formatted as SPIFFE Verifiable Identity Documents (SVIDs) in either X.509 or JWT formats16. Because SVIDs are short-lived, the system inherently defends against credential theft; a stolen JWT is useless once its validity window (often measured in minutes) expires.
Workloads utilize these SVIDs to establish mutual TLS (mTLS) connections. Unlike standard TLS where only the server proves its identity, mTLS requires the client workload to present a valid X.509 SVID to the server. The server verifies this SVID against the SPIRE Server’s trusted root CA bundle9.

4.2 Hardware-Rooted Identity and TPM Attestation

A critical vulnerability in software-based identity is that a compromised host can lie about the software it is running. To counteract this, Evulgare anchors workload identity in the physical hardware using Trusted Platform Module (TPM) 2.0 attestation8.
The integration relies on the spire-tpm-plugin and concepts derived from IEEE 802.1AR Local Device Identity (LDevID)15. During node attestation, the SPIRE Server encrypts a challenge using the public Endorsement Key (EK) of the node’s TPM. Only the genuine, physical TPM possessing the corresponding private EK can decrypt this challenge9. Furthermore, the TPM provides a cryptographically signed “quote” of its Platform Configuration Registers (PCRs). These PCRs contain measurements of the bootloader, kernel, and critical system libraries, gathered by the Linux Integrity Measurement Architecture (IMA). If a rootkit has altered the kernel, the PCR quote will not match the expected reference values, and the SPIRE Server will deny the node entry into the trust domain8.
[Diagram 1: Identity and Attestation Flow]
+-------------------+ +--------------------+ +-------------------+
| Physical Node | | SPIRE Server | | Evulgare Workload | | (TPM 2.0 Chip) | | (Trust Root CA) | | (Application) | +--------+----------+ +---------+----------+ +---------+---------+
| | | | 1. Submit TPM Quote & EK Hash | | |------------------------------>| | | | | | 2. Verify PCRs against policy | | |\<------------------------------| | | | | | 3. Issue Node SVID | | |\<| | | | | | 4. Workload spins up, requests| identity from local agent | |-------------------------------------------------------------->| | | | | 5. Agent maps Linux Namespace / k8s selectors | |\<--------------------------------------------------------------| | | | | 6. Issue Short-Lived Workload SVID (mTLS Ready) | |================================>|

5. Software and Model Attestation

Securing the runtime identity is insufficient if the deployed software artifacts are compromised upstream. The architecture demands strict cryptographic provenance for all code, dependencies, and artificial intelligence models.

5.1 Comparing Supply Chain Standards

5.2 Attestation Lifecycle

When a workload is built, the CI/CD pipeline acts as an Attesting Environment18. It generates a source digest (the Git SHA), a build digest (the container image hash), and a dependency graph (SBOM). For machine learning components, it generates an AI-BOM capturing the model digest and dataset reference.
These records are signed and distributed via TUF. Upon deployment, the Evulgare admission controller acts as the Verifier1. It evaluates the runtime quote against the attestation expiry and revocation lists. If an adversary attempts to inject an unsigned update, the system executes a FREEZE_RELEASE_CHANNEL response27.

6. Evidence Integrity and Proof Engineering

Audit logs are traditionally mutable; a sophisticated adversary with root access can delete their tracks. To establish unforgeable evidence, this architecture implements tamper-evident logging based on RFC 69626.

6.1 Merkle Hash Trees and Domain Separation

The Event Ledger utilizes a binary Merkle Hash Tree. Every security event, containment action, or state change is serialized into canonical JSON and hashed to form a leaf node. To prevent second-preimage attacks (CVE-2012-2459 malleability), the architecture strictly enforces RFC 6962 domain separation: leaf nodes are prefixed with a 0x00 byte before hashing, while internal structural nodes are prefixed with 0x0113.

6.2 Evidence Independence vs. Correlation

A fundamental requirement of the defensive engine is to prevent alert fatigue and evidence poisoning. If a single source (e.g., one failing microservice) generates ten identical alert logs, the system must not treat this as ten independent sources confirming an attack.
The Evidence Schema mandates a correlation_id, a source_identity (tied to the SPIFFE ID), and a transformation_history. If multiple events arrive with identical correlation IDs or from the same identity within a narrow freshness window, the system groups them. If an upstream aggregator filters the alert, the transformation history records the actor and action (e.g., FILTER, TRANSLATE). If evidence is later found to be false, a supersession UUID is issued, marking the original state as WITHDRAWN or CONTRADICTED.

6.3 Verification without Trust

The system exposes an API to generate O(log n) Inclusion Proofs6. An independent auditor can request a proof for a specific event and reconstruct the cryptographic path up to the Signed Tree Head (STH). If the calculated root matches the published root, the evidence is mathematically proven to be untampered, enforcing a “Verify, Don’t Trust” paradigm29.

7. Autonomous Defensive Response and Containment

The autonomous system interprets synthetic faults and evidence, translating them into physical and logical containment boundaries.

7.1 Bounded Outputs

To prevent the autonomous defense from being weaponized into a denial-of-service tool, it cannot arbitrarily delete data or counterattack. It is restricted to the bounded outputs defined in Section 3.1.

7.2 Containment Dynamics

When a SEVER_COMPARTMENT or ISOLATE_WORKLOAD command is issued, containment affects multiple layers simultaneously:

• Network Reachability: Container Network Interface (CNI) policies and eBPF filters drop all ingress and egress packets. The target is restricted to DENY_ALL or ALLOW_METRICS_ONLY (to permit ongoing observation).
• Identity and Authority: The SPIRE Server revokes the workload’s SVID. Subsequent mTLS handshakes will fail globally.
• Data Access: Connections to databases or message queues are severed; existing long-lived connections are forcefully terminated.
• Evidence Custody: The state of the contained workload is frozen, preserving volatile memory and logs for forensic custody.
• Release Permission: Dependent software pipelines are flagged with FROZEN, preventing automated updates that might overwrite forensic evidence.

Containment is strictly reversible, but only after an evidence-supported review confirms that the fault condition has been resolved or reconciled.
[Diagram 2: Containment Execution Boundary]
+-------------------+ 1. Fault Injected +-------------------+
| Threat Sensor |-------------------------->| Defensive Engine | +-------------------+ +---------+---------+
| 2. Decide: SEVER_COMPARTMENT v +-------------------+ 4. Drop Packets +-------------------+
| eBPF / CNI |\<--------------------------| Containment Svc | | Network Filter | +---------+---------+ +---------+---------+ | 3. Revoke SVID
| v | 5. Traffic Blocked +-------------------+ +---------v---------+ | SPIRE Server |
| Compromised Pod | +-------------------+ +-------------------+

8. Rekeying, Authority, and Reconciliation

Cryptographic architectures are only as strong as their key management. Evulgare assumes that signing keys will eventually be compromised and implements a robust rekeying and epoch management system based on TUF4.

8.1 Key Epochs and Threshold Signatures

Time and authority are segmented into Key Epochs. A single key compromise must never grant an adversary total control4. Therefore, critical actions (such as authorizing a new epoch or pushing a global policy update) require a threshold signature—for example, M-of-N signatures from independent governors (e.g., 3 of 5).
If a signer is compromised, the remaining quorum members cryptographically vote to transition to the next epoch. The compromised signer is added to the revocation list, and a signer replacement is executed.

8.2 Partitioned Nodes and Reconciliation

In distributed systems, a communications partition (split-brain) may cause a node to miss an epoch transition. When the partition heals, the stale node presents authority artifacts from an outdated epoch. The system detects the mixed epoch state, denies standard requests, and forces the node into a RECONCILE workflow24. The node must fetch the consistency proofs from the Merkle tree, verify the threshold signatures of the missed epochs, and update its local state before returning to active duty.

9. Attested Recovery

Recovery from a non-kinetic compromise cannot rely on simply restoring the latest backup, as the backup itself may contain the adversary’s persistence mechanisms (COMPROMISED_RECOVERY_BASELINE).
The Attested Recovery process demands cryptographic verification of the restoration baseline. The system verifies the backup digest against the trusted root. It validates the software, model, policy, and configuration state against the immutable records stored in the remote attestation environment. It ensures the system boots into a valid key epoch and applies a revoked credential exclusion list to guarantee that compromised identities are purged.
If a residual unknown exists—a non-critical state item that cannot be cryptographically verified—the recovery process requires explicit sign-off from the review quorum before the environment is unsealed.

10. Architectural Schemas

The following YAML schemas define the strict data structures used by the defense architecture for serialization and validation.

10.1 Identity Schema

YAML
SchemaName: EvulgareWorkloadIdentity
Version: 1.0
Fields:
spiffe_id: “URI format (e.g., spiffe://evulgare.internal/ns/ai/sa/model-runner)”
svid_type: “Enum [X509, JWT]“
hardware_root:
tpm_ek_pub_hash: “SHA256 digest of Endorsement Key”
attestation_quote: “TPM2B_ATTEST struct”
namespace_binding: “String representing execution compartment”
key_epoch: “Integer (current rotation phase)”
expiry: “ISO8601 Timestamp”

10.2 Attestation Schema

YAML
SchemaName: EvulgareSoftwareAttestation
Version: 1.0
Fields:
_type: “https://in-toto.io/Statement/v1”
subject:
name: “Artifact URI”
digest: “SHA256 digest”
predicateType: “https://slsa.dev/provenance/v1”
predicate:
buildDefinition:
buildType: “https://evulgare.internal/build/v1”
externalParameters:
source_digest: “SHA256”
dependency_graph_ref: “URI to SBOM”
runDetails:
builder:
id: “spiffe://evulgare.internal/builder”
metadata:
invocationId: “UUID”
startedOn: “ISO8601”

10.3 Evidence Schema

YAML
SchemaName: EvulgareEvidenceRecord
Version: 1.0
Fields:
evidence_id: “UUID”
source_identity: “spiffe_id of generating workload”
correlation_id: “UUID (Groups identical underlying events)”
transformation_history:
- actor: “spiffe_id”
action: “Enum [FILTER, AGGREGATE, TRANSLATE]“
timestamp: “ISO8601”
freshness_marker: “Integer (Monotonic counter preventing replay)”
supersession_id: “UUID of evidence this replaces”
status: “Enum [VALID, WITHDRAWN, CONTRADICTED]“

10.4 Authority Schema

YAML
SchemaName: EvulgareAuthorityDelegation
Version: 1.0
Fields:
role: “Enum [ROOT, TARGETS, SNAPSHOT, TIMESTAMP, GOVERNOR]“
key_identifiers:
- “List of active public key fingerprints”
threshold: “Integer (Quorum requirement)”
current_epoch: “Integer”
expiry: “ISO8601”

10.5 Key-Epoch Schema

YAML
SchemaName: EvulgareKeyEpoch
Version: 1.0
Fields:
epoch_id: “Integer”
active_signers: “List of public key fingerprints”
revoked_signers: “List of public key fingerprints”
transition_quorum: “List of threshold signatures authorizing epoch”
reconciliation_hash: “SHA256 of system state at epoch boundary”

10.6 Containment Schema

YAML
SchemaName: EvulgareContainmentBoundary
Version: 1.0
Fields:
target_spiffe_id: “URI”
containment_level: “Enum [QUARANTINE, ISOLATE, SEVER]“
network_reachability: “Enum [DENY_ALL, ALLOW_METRICS_ONLY]“
data_access: “Enum [READ_ONLY, REVOKED]“
release_permission: “Enum [FROZEN]“
evidence_custody_ref: “UUID of triggering evidence”
reversibility_condition: “Enum [MANUAL_REVIEW, AUTOMATED_RECONCILIATION]“

10.7 Recovery Schema

YAML
SchemaName: EvulgareAttestedRecovery
Version: 1.0
Fields:
baseline_digest: “SHA256 of trusted immutable state”
trusted_root: “Root CA public key fingerprint”
valid_key_epoch: “Integer”
revoked_credential_exclusion: “List of SVIDs explicitly banned”
independent_governor_signatures: “List of threshold signatures”
residual_unknowns: “List of non-critical state items deferred”

10.8 Event Schema

YAML
SchemaName: EvulgareLedgerEvent
Version: 1.0
Fields:
timestamp: “ISO8601”
event_type: “String (Maps to synthetic faults)”
actor: “spiffe_id”
action: “Bounded Output Enum”
cryptographic_proof: “RFC 6962 Leaf Hash”

11. Python Module Architecture and Safe Pseudocode

The backend simulation and defensive operations are constructed from safe, tightly scoped Python modules utilizing tpm2_pytss for hardware bindings and standard cryptographic libraries for proof generation31.

11.1 Identity and Hardware Attestation

Python
“”“
identity_service.py
Provides secure workload identity fetching and hardware-rooted validation via TPM 2.0.
“”“
from tpm2_pytss import ESAPI, TPM2B_AUTH, ESYS_TR, TPMA_SESSION
import requests

class IdentityService:
def __init__(self, spire_socket_path=”/tmp/spire-agent/public/api.sock”):
self.spire_socket \= spire_socket_path
self.tpm \= ESAPI()

def fetch\_workload\_svid(self, spiffe\_id\_prefix):  
    """Fetches SVID via local SPIRE Agent Unix socket."""  
    \# Pseudocode for SPIRE Workload API HTTP wrapper  
    try:  
        response \= requests.get(  
            "http://localhost/svid",   
            params={"spiffe\_id": spiffe\_id\_prefix}  
        )  
        if response.status\_code \== 200:  
            return response.json().get("svid")  
    except Exception:  
        return None  
    return None

def attest\_hardware(self, expected\_ek\_hash):  
    """Uses tpm2\_pytss to verify physical TPM presence and read the EK."""  
    try:  
        \# 0x81010005 is the standard Endorsement Key persistent handle  
        ek\_handle \= self.tpm.tr\_from\_tpmpublic(0x81010005)  
        ek\_pub \= self.tpm.readpublic(ek\_handle)  
        \# Verify EK public area hash against expected allow-list  
        actual\_hash \= ek\_pub\[0\].get\_name().hex()  
        return actual\_hash \== expected\_ek\_hash  
    except Exception as e:  
        \# Synthetic response for testing: Hardware failure  
        return False

11.2 Authority and Rekeying

Python
“”“
authority_service.py & rekey_service.py
Manages TUF-style Key Epochs, thresholds, and revocation.
“”“
class RekeyService:
def __init__(self, current_epoch, current_signers, threshold=3):
self.epoch \= current_epoch
self.active_signers \= current_signers
self.threshold \= threshold

def transition\_epoch(self, new\_signer\_keys, quorum\_signatures):  
    """Transitions to the next epoch if quorum is met."""  
    if self.\_verify\_threshold(quorum\_signatures):  
        self.epoch \+= 1  
        self.active\_signers \= new\_signer\_keys  
        return True  
    return False

def \_verify\_threshold(self, signatures):  
    """Verifies M-of-N signatures from current epoch signers."""  
    valid\_count \= 0  
    for sig in signatures:  
        if self.\_verify\_sig(sig): \# Crypto validation stub  
            valid\_count \+= 1  
    return valid\_count \>= self.threshold

def \_verify\_sig(self, sig):  
    return True \# Placeholder for actual ed25519 verification

11.3 Event Ledger and Proof Engine (RFC 6962)

Python
“”“
event_ledger.py & proof_engine.py
Append-only verifiable Merkle tree log for tamper-evident evidence.
“”“
import hashlib
import json

class MerkleLedger:
def __init__(self):
self.leaves \= []
self.tree \= {}

def \_hash\_leaf(self, data: bytes) \-\> bytes:  
    """RFC 6962 Domain Separation: 0x00 prefix for leaves"""  
    return hashlib.sha256(b'\\x00' \+ data).digest()

def \_hash\_node(self, left: bytes, right: bytes) \-\> bytes:  
    """RFC 6962 Domain Separation: 0x01 prefix for internal nodes"""  
    return hashlib.sha256(b'\\x01' \+ left \+ right).digest()

def append\_event(self, event\_dict):  
    """Appends a canonical JSON event to the ledger."""  
    canonical\_data \= json.dumps(event\_dict, sort\_keys=True).encode('utf-8')  
    leaf\_hash \= self.\_hash\_leaf(canonical\_data)  
    self.leaves.append(leaf\_hash)  
    \# Note: Dynamic tree recalculation logic omitted for brevity  
    return leaf\_hash.hex()

def generate\_inclusion\_proof(self, index):  
    """Generates an O(log n) inclusion proof for a given leaf index."""  
    \# Simulated proof output  
    return {"leaf\_index": index, "audit\_path": \["hash1", "hash2"\]}

class ProofEngine:
def verify_inclusion(self, leaf_hash, audit_path, expected_root):
“”“Verifies the audit path mathematically reconstructs the root.”“”
current_hash \= leaf_hash
for sibling_hash in audit_path:
# Enforce canonical ordering for hashing
if current_hash \< sibling_hash:
current_hash \= MerkleLedger()._hash_node(current_hash, sibling_hash)
else:
current_hash \= MerkleLedger()._hash_node(sibling_hash, current_hash)
return current_hash \== expected_root

11.4 Containment and Reconciliation

Python
“”“
containment_service.py & reconciliation_service.py
Translates abstract defense decisions into network and identity boundaries.
“”“
class ContainmentService:
def execute_bounded_response(self, target_spiffe_id, response_enum):
“”“Executes bounded output. No offensive counterattacks permitted.”“”
if response_enum \== “DENY_REQUEST”:
return self._deny_api(target_spiffe_id)
elif response_enum \== “ISOLATE_WORKLOAD”:
return self._isolate(target_spiffe_id)
elif response_enum \== “SEVER_COMPARTMENT”:
return self._sever(target_spiffe_id)
elif response_enum \== “FREEZE_RELEASE_CHANNEL”:
return self._freeze_ci_cd()
elif response_enum \== “RECONCILE”:
return ReconciliationService().force_sync(target_spiffe_id)
else:
return self._abstain()

def \_isolate(self, spiffe\_id):  
    \# Simulated interaction: Instruct SPIRE to revoke SVID  
    \# Simulated interaction: Update CNI to drop packets  
    return True

def \_sever(self, namespace\_uri):  
    \# Simulated interaction: DENY\_ALL eBPF policy applied to namespace  
    return True

def \_freeze\_ci\_cd(self):  
    \# Simulated interaction: Halt pipelines  
    return True

def \_abstain(self):  
    \# Defer to human or secondary machine review  
    return False

class ReconciliationService:
def force_sync(self, spiffe_id):
“”“Forces a node out of a split-brain state to synchronize epochs.”“”
return True

11.5 Attestation and Recovery

Python
“”“
attestation_service.py & recovery_service.py
Handles SLSA verification and attested baseline restoration.
“”“
class AttestationService:
def verify_slsa_provenance(self, artifact_digest, provenance_envelope):
“”“Verifies DSSE envelope and SLSA v1.0 payload.”“”
# Simulated logic: Check signature, extract subject digest, compare.
return True

class RecoveryService:
def verify_baseline(self, proposed_state, trusted_root_hash):
“”“Ensures the system boots into a mathematically valid state.”“”
# Simulated logic: Compare state hash against immutable trusted root
actual_hash \= hashlib.sha256(proposed_state.encode()).hexdigest()
return actual_hash \== trusted_root_hash

11.6 Flask API Router (.uai endpoint)

Python
“”“
api_router.py
Flask API for Evulgare Defense Operations and Fault Injection.
“”“
from flask import Flask, request, jsonify
from containment_service import ContainmentService
import fault_injection

app \= Flask(__name__)
containment \= ContainmentService()

@app.route(‘/v1/inject_fault.uai’, methods=[‘POST’])
def handle_fault():
“”“Accepts abstract fault injections for synthetic range testing.”“”
data \= request.json
fault \= data.get(‘fault_type’)
target \= data.get(‘target_spiffe_id’)

\# Map injected faults to defined bounded responses  
if fault \== "FORGED\_IDENTITY":  
    containment.execute\_bounded\_response(target, "DENY\_REQUEST")  
    return jsonify({"status": "SUCCESS", "response": "DENY\_REQUEST"})

elif fault \== "COMPARTMENT\_BREACH":  
    containment.execute\_bounded\_response(target, "SEVER\_COMPARTMENT")  
    return jsonify({"status": "SUCCESS", "response": "SEVER\_COMPARTMENT"})

elif fault \== "EVIDENCE\_POISONING":  
    containment.execute\_bounded\_response(target, "COLLECT\_MORE\_EVIDENCE")  
    return jsonify({"status": "SUCCESS", "response": "COLLECT\_MORE\_EVIDENCE"})

return jsonify({"status": "DEFERRED", "response": "ABSTAIN"})

if __name__ \== ‘__main__‘:
app.run(port=8443, ssl_context=’adhoc’)

12. Operator and Machine Review

While the system executes containment autonomously in milliseconds, long-term governance and reversibility rely on comprehensive review mechanisms.

12.1 Procedural Confirmation vs. Merits Review

The architecture strictly delineates between a procedural confirmation and a merits review. When a human operator clicks an “Approve” button on a dashboard, the system records this as a procedural step. However, the system’s invariants state that a recorded click does not automatically equate to cognitive understanding or legal approval. A true merits review requires independent judgment, where the operator annotates the evidence package, confirms the correlation IDs, and signs the reversal command using their hardware token.

12.2 Independent Machine Review

To counter cognitive overload, the system supports Independent Machine Review. A secondary, isolated autonomous agent evaluates the primary system’s logic and evidence ledger. If the primary system isolates a workload based on a MODEL_DIGEST_MISMATCH, but the secondary machine review calculates that the drift was an artifact of authorized floating-point rounding, it issues an ABSTAIN or COLLECT_MORE_EVIDENCE report, forcing human arbitration.

13. Security Test Matrix

The system undergoes rigorous validation against boundary conditions and adversarial edge cases without executing live malware.

14. Synthetic Defense Range: Eight Site Demos

To validate the architecture safely in a simulated environment, eight synthetic demos represent the defensive boundary operations.

1. Workload Identity Defense Demo: Simulates the FORGED_IDENTITY fault. The user attempts to pass a cloned JWT-SVID to an API boundary. The API requests a hardware TPM quote, fails to match the hardware root, and outputs DENY_REQUEST followed by ISOLATE_WORKLOAD.
2. Authority Replay Detection Demo: Simulates REPLAYED_AUTHORITY. A user captures a mathematically valid API request from Key Epoch 1 and replays it during Key Epoch 2. The .uai router detects the epoch mismatch and issues REQUIRE_REAUTHENTICATION.
3. Software Supply-Chain Attestation Demo: Simulates UNSIGNED_UPDATE. A simulated CI/CD pipeline attempts to push a container image without an in-toto SLSA provenance record. The Kubernetes admission controller halts the pod creation and issues FREEZE_RELEASE_CHANNEL.
4. Model Integrity and Drift Demo: Simulates MODEL_DIGEST_MISMATCH. A synthetic AI model’s weight file is deliberately altered in memory via a hex editor script. The runtime watcher calculates the drift, compares it to the CycloneDX AI-BOM, and triggers SEVER_COMPARTMENT.
5. Evidence Poisoning and Correlation Demo: Simulates EVIDENCE_POISONING. 100 identical fault alerts are sent with manipulated headers to induce alert fatigue. The evidence service uses the correlation_id and transformation_history to deduplicate the alerts, outputting COLLECT_MORE_EVIDENCE instead of isolating the network.
6. Compartment Breach Containment Demo: Simulates COMPARTMENT_BREACH. A workload in Namespace A attempts to access an unauthorized database in Namespace B. Network policies detect the unauthorized SPIFFE ID and trigger SEVER_COMPARTMENT, restricting the pod to ALLOW_METRICS_ONLY reachability.
7. Key-Epoch Recovery Demo: Simulates a compromised signer. 3 of 5 quorum members cryptographically vote to ban the compromised key, generating the next epoch, updating the revocation list, and outputting REKEY.
8. Attested Reconstitution Demo: Simulates COMPROMISED_RECOVERY_BASELINE. After a severe simulated fault, the system attempts recovery. It checks the backup baseline against the immutable trusted root. Upon success, it outputs RESTORE_ATTESTED_BASELINE and unseals the data.

15. Visualization, Accessibility, and Performance Plans

15.1 Visualization Layers

The system generates discrete visual representations to assist human review:

• Trust Topology: Directed acyclic graphs (DAGs) representing SPIRE federation boundaries and active mTLS paths.
• Key-Epoch Map: Timeline visualization showing epoch boundaries, active threshold signers, and revoked keys over time.
• Evidence Graph: Node-link diagrams showing the chain of custody of log artifacts through various transformations.
• Containment Boundary: Real-time dashboards highlighting isolated or severed namespaces in high-contrast red, with normal operations in green.

15.2 Accessibility Plan

All dashboards and proof inspectors must adhere to WCAG 2.1 AA standards. Screen readers must be able to parse structural tables and form states accurately. Color is never used as the sole method of conveying operational status; an “Isolated” compartment includes a distinct geometric icon and a text label alongside the color shift, ensuring usability for visually impaired operators.

15.3 Performance and Scale Plan

• Merkle Tree Appends: Optimized to sub-millisecond latency using in-memory caching before batch flushing to persistent storage, preventing disk I/O bottlenecks.
• SVID Rotation: Expiration timers are staggered randomly across the fleet (jittering) to prevent thundering herd problems on the SPIRE server during mass rotations.
• API Rate Limiting: Flask .uai endpoints are protected by token-bucket algorithms, guaranteeing service availability even during synthetic API fuzzing or flooding attacks.
• Production Deployment: SPIRE servers operate in highly available clusters with distinct TPMs—an architecture known as “Bottom Turtle HA”9. They share no database or root signing keys, preventing a total collapse if one node physically fails.

16. Site-Ready Content (2,500 Words)

(The following section provides public-facing, educational, site-ready technical content suitable for publication on Evulgare’s documentation portals under the recommended path /docs/architecture/autonomous-defense-v1. It details the philosophy, implementation, and guarantees of the system for developers, engineers, and stakeholders.)

Welcome to the Evulgare Autonomous Cyber-Physical Defense Framework

In an era where digital ecosystems dictate the pace of global infrastructure, traditional security perimeters have evaporated. The modern threat landscape no longer consists merely of external actors attempting to breach firewalls by guessing passwords; it is defined by sophisticated, non-kinetic adversaries capable of subverting identities, manipulating complex software supply chains, and forging cryptographic evidence from within the perimeter. At Evulgare, we recognized that human-speed response is fundamentally inadequate against machine-speed compromise. We needed a paradigm shift.
We are proud to introduce the Evulgare Autonomous Cyber-Physical Defense Framework. This architecture is not an off-the-shelf product; it is a fundamental re-engineering of how trust is established, verified, and enforced across our distributed systems. By anchoring trust in hardware, managing identities dynamically, and empowering the system to autonomously contain faults in milliseconds, we have built a resilient, compromise-aware environment.

The Philosophy of Cryptographic Determinism

The core philosophy underlying our defensive architecture is “Cryptographic Determinism.” In traditional computing environments, security decisions are often based on heuristics, behavioral anomalies, or IP address reputations. A system might ask, “Does this IP address look suspicious?” or “Is this user downloading too many files?” These factors are highly mutable, subjective, and prone to massive false positives or adversarial evasion.
Cryptographic determinism removes this ambiguity entirely. An identity either possesses the private key corresponding to its hardware-bound certificate, or it does not. A software artifact either perfectly matches the SHA-256 digest recorded in its secure build provenance, or it does not. An event log either mathematically resolves to the public Merkle tree root hash, or it does not.
By demanding mathematical proof for every interaction, the system eliminates the concept of implicit trust. We do not trust you because you are inside the network. We do not trust you because you have a password. We trust the interaction only because it has been cryptographically proven at the exact millisecond of execution. This is the true definition of Zero Trust, brought to its logical, mathematical conclusion.

Pillar 1: Zero-Trust Workload Identity

At the foundation of our architecture is the concept of workload identity. Modern infrastructure is heavily automated; machines talk to machines far more frequently than humans talk to machines. Therefore, we do not just authenticate users—we authenticate the specific, running instances of code. To achieve this, we have deeply integrated SPIFFE (Secure Production Identity Framework For Everyone) and SPIRE (the SPIFFE Runtime Environment).
When a workload—a microservice, a database, or an AI inference engine—spins up in the Evulgare cloud, it does not carry static, long-lived API keys. Static keys are a catastrophic liability. They can be stolen, leaked in source code, accidentally pushed to public repositories, or left on forgotten hard drives. Instead, our workloads dynamically request a SPIFFE Verifiable Identity Document (SVID). This SVID is a short-lived cryptographic passport, often expiring in less than an hour.
But how does the system know the workload is safe to issue a passport to? This is where our hardware-rooted trust comes into play. We utilize TPM 2.0 (Trusted Platform Module) attestation. Before SPIRE issues an SVID, the underlying physical node hosting the workload must prove its identity using its indelible hardware Endorsement Key (EK). The node provides a cryptographically signed “quote” of its current state, proving that its boot sequence, kernel, and critical configurations have not been tampered with. If an adversary attempts to clone a workload and run it on an unauthorized, un-attested machine, the request for an SVID is mathematically denied.
Once the workload possesses its SVID, it uses it to establish Mutual TLS (mTLS) connections. The workload proves its identity to the database, and the database proves its identity to the workload. All data in transit is encrypted, and every connection is cryptographically authenticated.

Pillar 2: Software and Model Supply Chain Attestation

Securing the runtime environment is only half the battle. If the software being executed is compromised before it ever reaches the server, runtime defenses are fighting a lost cause. High-profile industry events have repeatedly demonstrated that the software supply chain is the soft underbelly of modern infrastructure. An adversary does not need to hack your production server if they can insert a backdoor into a library you download during the build process.
Evulgare implements a ruthless, uncompromising approach to software and model integrity based on the SLSA (Supply chain Levels for Software Artifacts) framework and in-toto attestations. Every piece of code, every container image, and every machine learning model deployed to our environment must carry a cryptographically signed provenance document.
This document—often wrapped in a standardized Dead Simple Signing Envelope (DSSE)—details exactly who built the software, what source code repository it came from, the specific commit hash, the compiler version, and the environment parameters. When a deployment is requested, our Kubernetes admission controllers do not just check if the software works; they verify the provenance signature. If the signature is missing or invalid, the deployment is blocked instantly.
For our Artificial Intelligence infrastructure, we utilize CycloneDX 1.6 AI-BOMs (Bill of Materials). AI models are essentially opaque blocks of mathematics, making them incredibly difficult to audit for tampering. The AI-BOM solves this by recording the lineage of the datasets used to train the models, the ethical parameters, and the precise cryptographic digests of the model weights and biases. If an adversary attempts to silently poison a model in memory, our continuous runtime watchers detect the digest mismatch and trigger immediate autonomous containment.

Pillar 3: Evidence Integrity and Tamper-Evident Ledgers

In the event of a system anomaly, the architecture generates evidence. However, smart adversaries know that the best way to hide an intrusion is to alter the logs. They gain root access and delete the records of their presence. To permanently prevent this, Evulgare relies on a cryptographically verifiable, append-only Merkle Hash Tree ledger, inspired by the IETF RFC 6962 Certificate Transparency specification.
Every critical event—every authentication success or failure, every containment action, every cryptographic key rotation—is hashed and appended to this tree as a leaf node. The system continually computes a single root hash that mathematically represents the entire history of the system. If an attacker attempts to alter a log entry from last week, the hash of that entry changes, which changes the hash of its parent node, cascading all the way to the root. The discrepancy is instantly detected.
Furthermore, we provide an “Inclusion Proof” API. External auditors, independent governance boards, or automated machine reviewers can request an O(log n) cryptographic proof that a specific event exists in the log. This allows us to say “Verify, Don’t Trust.” We do not ask you to simply believe our logs are intact; we provide the raw math so you can prove it yourself.

Pillar 4: Autonomous Bounded Responses and Containment

When the deterministic rules of the system are violated, response time is critical. Human operators cannot parse logs, analyze threats, manually log into firewalls, and formulate complex routing rules in the milliseconds required to stop a lateral movement attack. Therefore, our system is empowered to act autonomously.
However, to prevent the autonomous system from causing catastrophic self-denial-of-service, its actions are strictly bounded. The system cannot launch counterattacks, it cannot execute arbitrary code on external networks, and it cannot delete forensic data. It is restricted to a precise, predefined set of defensive actions:

• ALLOW_OBSERVATION: Monitor the event without interference, logging additional metadata.
• DENY_REQUEST: Block a specific transaction at the API gateway.
• REQUIRE_REAUTHENTICATION: Force the client to refresh its cryptographic credentials.
• REVOKE_AUTHORITY: Invalidate a specific identity across the entire trust domain.
• ISOLATE_WORKLOAD: Cut off a specific application instance from all peers.
• SEVER_COMPARTMENT: Cryptographically isolate an entire namespace or cluster segment.
• QUARANTINE_SERVICE: Suspend a microservice pending human review.
• FREEZE_RELEASE_CHANNEL: Halt automated deployments to prevent upstream compromise from spreading.
• COLLECT_MORE_EVIDENCE: Increase logging granularity and telemetry capture.
• REKEY: Initiate a cryptographic key rotation for compromised authorities.
• RECONCILE: Attempt to resolve state drift after a network partition.
• RESTORE_ATTESTED_BASELINE: Revert the system to a known-good, mathematically proven cryptographic state.
• ABSTAIN: Defer the decision to human operators when the confidence interval is low.

When a high-severity containment action is taken, such as severing a compartment, the system utilizes eBPF (Extended Berkeley Packet Filter) and advanced CNI (Container Network Interface) policies to drop network packets instantly. Simultaneously, the identity of the offending workload is revoked at the SPIRE server, meaning it can no longer authenticate to databases, queues, or other services. Crucially, all containment is designed to be fully reversible once a human operator or a secondary machine quorum reviews the evidence and confirms the threat is neutralized.

Pillar 5: Authority, Key Epochs, and Threshold Recovery

Cryptographic systems rely on keys, and history shows that keys can—and will—be compromised. If a single master key is lost or stolen, the entire system is at risk. To mitigate this systemic vulnerability, Evulgare utilizes The Update Framework (TUF) and principles adapted from the Uptane automotive security standard.
We distribute authority using threshold cryptography and strict role delegation. No single key possesses total control over the environment. To rotate the root keys, or to push a global policy update, a “quorum” of signers (for example, 3 out of 5 human or machine governors) must independently sign the request.
We manage these keys in distinct “Epochs.” An epoch is a defined period of time governed by a specific set of active, trusted keys. If a key is suspected of compromise, the quorum votes to transition the system to the next epoch. The compromised key is placed on a revocation list, new keys are generated, and the state of the system is cryptographically reconciled. Any node or workload attempting to use the old, compromised key is immediately isolated.
If a catastrophic fault occurs—such as a split-brain network partition where different datacenters lose connectivity—the system enters an Attested Recovery phase. It verifies its configuration against an immutable baseline, checks that all active identities belong to the current key epoch, applies a revoked credential exclusion list, and requires a quorum signature to resume normal operations.

Operator and Machine Review: The Human Element

While the system is highly autonomous, the ultimate accountability remains with human operators. We have designed a nuanced review system that understands the critical difference between a simple procedural confirmation and a full merits review.
When a containment action triggers, operators are presented with a rich visualization of the event ledger, the trust topology, and the cryptographic proofs. They can evaluate the incident and click to confirm the system’s actions or reverse them. However, we explicitly acknowledge in our architecture invariants that a recorded “click” in a graphical interface does not automatically equate to cognitive understanding or legal approval. It is merely a procedural step. True governance requires independent judgment, which is why we support Independent Machine Review—secondary, isolated AI systems that evaluate the primary system’s logic and can trigger an ABSTAIN vote if discrepancies are found, forcing human teams to arbitrate the dispute.

Building for Resilience

The Evulgare Autonomous Cyber-Physical Defense Framework represents the bleeding edge of defensive architecture. By combining hardware attestation, strict supply chain provenance, tamper-evident Merkle tree logs, and threshold authority, we have created an environment that is deeply hostile to compromise and immensely resilient to failure.
This is not just a theoretical model; it is the operational blueprint of the Evulgare ecosystem. We are committed to transparency, pushing the boundaries of zero-trust engineering, and ensuring that our infrastructure remains secure, mathematically verifiable, and continuously available for our users.
(End of Site-Ready Content)

17. Frequently Asked Questions (40 FAQs)

18. Glossary of 60 Terms

19. 40 Architecture Invariants

Invariants are mathematical and systemic truths that the architecture MUST enforce at all times without exception. If an invariant is violated, the system is designed to mathematically fail closed.

Works cited

1. RFC 9334 - Remote ATtestation procedureS (RATS) Architecture - IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc9334
2. Everyone Wants SPIFFE. Almost No One Can Afford to Build It Right. - Aembit, https://aembit.io/blog/everyone-wants-spiffe-almost-no-one-can-afford-to-build-it-right/
3. Solving-the-bottom-turtle-SPIFFE-SPIRE-Book.pdf, https://spiffe.io/pdf/Solving-the-bottom-turtle-SPIFFE-SPIRE-Book.pdf
4. IEEE-ISTO 6100.1.0.0 Uptane Standard for Design and Implementation, https://uptane.org/docs/1.0.0/standard/uptane-standard
5. Principles for secure software distribution: Lessons from leaked Android platform signing keys - Chainguard, https://www.chainguard.dev/unchained/principles-for-secure-software-distribution-lessons-from-leaked-android-platform-signing-keys
6. RFC 6962 - Certificate Transparency - IETF Datatracker, https://datatracker.ietf.org/doc/html/rfc6962
7. Building Cryptographic Audit Trails for AI Trading Systems: A Deep Dive into RFC 6962-Based Verification - DEV Community, https://dev.to/veritaschain/building-cryptographic-audit-trails-for-ai-trading-systems-a-deep-dive-into-rfc-6962-based-6aa
8. SPIFFE/SPIRE and Keylime: Software Identity based on Secure Machine State, https://next.redhat.com/2025/01/24/spiffe-spire-and-keylime-software-identity-based-on-secure-machine-state/
9. The Bottom Turtle That Heals Itself - Design - SPIFFE, https://spiffe.io/blog/2026-07-19-bottom-turtle-ha-architecture/
10. Provenance - SLSA.dev, https://slsa.dev/spec/v1.0/provenance
11. Snyk AI-BOM: How It Builds a CycloneDX v1.6 ML-BOM - Safeguard, https://safeguard.sh/resources/blog/how-snyk-ai-bom-generates-a-cyclonedx-v16-compliant-ml-bom
12. Uptane Standard for Design and Implementation 2.1.0, https://uptane.org/docs/latest/standard/uptane-standard
13. Merkle Vault — Interactive Merkle Tree & Inclusion Proof Lab, https://systemslibrarian.github.io/crypto-lab-merkle-vault/
14. transparency - Go Packages, https://pkg.go.dev/semp.dev/semp-go/transparency
15. A Path to Zero Trust Architecture in HPC and AI Using SPIFFE and Spire - CLSAC, https://www.clsac.org/uploads/5/0/6/3/50633811/clsac-2023-duckworth.pdf
16. SPIFFE Workload Identity Architecture: Device Fleets, TPM Attestation, and SPIRE at the Edge | AxelSpire, https://axelspire.com/business/device-identity-spiffe-workload/
17. What is SPIFFE? Universal Workload Identity Framework Guide - Palo Alto Networks, https://www.paloaltonetworks.com/cyberpedia/what-is-spiffe
18. RFC 9334: Remote ATtestation procedureS (RATS) Architecture, https://www.rfc-editor.org/info/rfc9334/
19. SLSA and Provenance: Your SBOM Says What’s Inside, This Says Where It Came From, https://www.ostering.com/slsa-and-provenance/
20. Provenance - SLSA.dev, https://slsa.dev/spec/v1.0-rc1/provenance
21. attestation/spec/v0.1.0/field_types.md at main · in-toto/attestation · GitHub, https://github.com/in-toto/attestation/blob/main/spec/v0.1.0/field_types.md
22. Scudo: Addressing Software Supply Chain Security in Uptane, https://uptane.org/enhancements/pures/pure3
23. The Update Framework - Wikipedia, https://en.wikipedia.org/wiki/The_Update_Framework
24. Speranza: Usable, privacy-friendly software signing - arXiv, https://arxiv.org/pdf/2305.06463
25. Trustworthy and Confidential SBOM Exchange - USENIX, https://www.usenix.org/system/files/conference/usenixsecurity26/sec26_prepub_ishgair.pdf
26. SBOM::CycloneDX - Raku Land, https://raku.land/zef:lizmat/SBOM::CycloneDX
27. (PDF) Formal Verification for Harness Engineering in Quantitative Finance - ResearchGate, https://www.researchgate.net/publication/410601276_Formal_Verification_for_Harness_Engineering_in_Quantitative_Finance
28. Don’t trust your logs! Implementing a Merkle tree for an Immutable Verifiable Log (in Go), https://arriqaaq.medium.com/dont-trust-your-logs-implementing-a-merkle-tree-for-an-immutable-verifiable-log-in-go-c242b558ae00
29. VCP Explorer API v1.1 - VeritasChain Standards Organization, https://veritaschain.org/vcp/explorer-api/
30. Exploring Longevity Challenges and Solutions for IoT Conner Bradley - Carleton Internet Security Lab (CISL), https://www.cisl.carleton.ca/\~cbradley/data/papers/MastersThesis.pdf
31. Esys — tpm2-pytss 0.1.dev50+gd462fb475 documentation, https://tpm2-pytss.readthedocs.io/en/latest/esys.html
32. GitHub - salrashid123/cloud_auth_tpm: Python auth library for GCP AWS Azure using Trusted Platform Module (TPM) based credentials, https://github.com/salrashid123/cloud_auth_tpm
33. Example for Making and Activating a Credential in tpm2-pytss · GitHub - Gist, https://gist.github.com/williamcroberts/ff5c97c136d14e48ddcb083c54616db4