Attested Autonomous Agents: FUSE & CRANE Unleashed

March 12, 2025 • Software Development, Secure Messaging, Noise Protocol, Attestation, Trust, Cryptography, Encryption, Security, Privacy • 3115 words • about a 15 minute read

Imagine your fleet of autonomous agents as a team of secret agents—each sporting quirky gadgets and secret handshakes—but instead of fast cars and martinis, they use cutting‑edge cryptography. We’re pioneering two protocols that empower these agents to self-organize secure sessions even in untrusted environments. Meet FUSE and CRANE—our dynamic duo for ephemeral, encrypted communication.

Remember: FUSE is our “Fast Unattested Secure Ephemeral” Protocol – it’s all about speed and agility without the overhead of attestation.

By contrast, CRANE (Cryptographically Attested Remote Agent Noise Exchange Protocol) adds an extra layer of trust via attestation, ensuring that every agent proves its integrity.

The Foundation: Noise XX Handshakes & Secure Sessions

Our agents leverage the Noise Protocol Framework to quickly negotiate secure channels. One of the most versatile patterns is Noise XX—a handshake that doesn’t assume prior knowledge of each other’s keys. Think of it as a secret handshake that both parties develop on the spot.

How Noise XX Works

In a Noise XX handshake, both parties start with no pre‑shared static key information. The process unfolds in several rounds:

Initiator Sends Message A: The initiator generates an ephemeral key and sends its public portion.
Responder Sends Message B: The responder receives Message A, generates its own ephemeral key, and sends a message that includes its ephemeral public key and its static public key (encrypted under the ephemeral keys).
Initiator Sends Message C: The initiator, after receiving Message B, responds with a final message that completes the key agreement. Both parties now derive the same shared secret from the ephemeral Diffie-Hellman exchanges.

Below is a simplified flow chart for a Noise XX handshake:

flowchart TD
    A[Initiator generates ephemeral key, sends Message A]
    A --> B[Responder receives A, generates its ephemeral key, sends Message B-includes static public key, encrypted]
    B --> C[Initiator processes B, sends Message C]
    C --> D[Both compute shared secret and establish session keys]

During this handshake, both parties record every message in the exact order they are sent and received. This ordered collection forms the handshake transcript, which we later hash and use for attestation in CRANE.

Introducing Our Protocols

FUSE: Fast Unattested Secure Ephemeral Protocol

FUSE is designed for scenarios where speed is paramount and formal identity attestation isn’t required. It’s like sending a secret text that self-destructs moments after being read.

Key Features of FUSE:

Ephemeral & Lightweight: Sessions are created in a flash—perfect for dynamic environments where agents appear and disappear faster than you can say “encryption.”
Ad‑Hoc Operation: Agents autonomously set up secure channels using the Noise XX handshake, without the extra overhead of attestation.
Minimal Overhead: Without the attestation phase, FUSE minimizes latency and computational cost—ideal for sensor data aggregation on a TLS‑protected MQTT bus.
Basic Security Guarantees: Although endpoints aren’t formally vouched for, the Noise handshake guarantees confidentiality, integrity, and forward secrecy.

CRANE – Cryptographically Attested Remote Agent Noise Exchange Protocol

CRANE is for high‑trust environments. After establishing a secure channel with Noise XX, CRANE adds an attestation phase to prove that each agent is running trusted, approved software.

Unique Aspects of CRANE

Enhanced Trust via Attestation: Once the Noise handshake is complete, both parties record all messages to build an identical transcript. They compute a SHA‑256 hash of this transcript and then sign it with their attestation key. An attestation token (e.g., a JWT) is generated from a trusted authority and sent along with the signature.
Deterministic Transcript Agreement: Whether you’re the initiator or responder, every handshake message is recorded in a canonical order. This ensures both sides compute the exact same transcript hash.
Chain-of-Trust Enforcement: Verifying that the attestation token is valid and that the transcript hash (and its signature) match confirms that both endpoints are running trusted code.
Fine‑Grained Policy Control: Attestation tokens can carry extra claims (like agent identity or software version), enabling strict access control.

Transcript Agreement: How Both Parties See the Same Handshake

A critical innovation in CRANE is that both the initiator and responder maintain an identical view of the handshake transcript. Here’s how it works:

Message Recording

As soon as the initiator sends Message A, both parties record it. Then, when the responder sends Message B, it is also recorded identically on both sides.
Transcript Hashing: The recorded messages are concatenated in order to produce a transcript, and a cryptographic hash (e.g., SHA‑256) is computed over that transcript.
Signature and Attestation: Each agent signs its computed hash with its private attestation key and then sends an attestation message containing:
1. The attestation token (proving the integrity of its environment).
2. The signature over the transcript hash.

Transcript Flow Diagram

flowchart TD
    A[Initiator sends Message 1]
    A --> B[Both record Message 1]
    B --> C[Responder sends Message 2]
    C --> D[Both record Message B]
    D --> E[Concatenate AB into Transcript]
    E --> F[Compute SHA256 Hash of Transcript]
    F --> G[Both compute identical transcript hash]

By exchanging and comparing these values, each party can verify that their handshake view is identical and that no tampering occurred.

Attestation Phase: The CRANE Approach

Once the Noise XX handshake is complete, CRANE initiates the attestation phase. Here’s the step-by-step process:

Below is an expanded explanation of the attestation phase steps, with clear details on why each step is necessary, how it improves security, and what organizations can expect from the system.

Record & Compute

What It Does: During the Noise XX handshake, every exchanged message is recorded in the order it is sent and received. Both the initiator and the responder then concatenate these messages to form a complete transcript of the handshake. A deterministic hash algorithm (e.g., SHA‑256) is applied to this transcript, producing a unique “fingerprint” of the session.

Why It’s Necessary:
- Integrity Check: By computing a transcript hash, both parties independently arrive at the same value. If even one message were missing or altered, the computed hash would differ, signaling potential tampering.
- Basis for Attestation: The transcript hash becomes the data over which a digital signature is later created. It essentially “binds” the secure session to the specific sequence of messages exchanged.
- Reduction of Ambiguity: A deterministic algorithm ensures that both agents will always generate an identical hash, removing any uncertainty about whether they “saw” the same handshake.
Benefits:
- Enhanced Security: Guarantees that no man‑in‑the‑middle modified the handshake.
- Trust Assurance: Both agents can be sure that they share the same view of the handshake, which is critical when later verifying attestation evidence.
Sign the Hash

What It Does: Each agent uses its private attestation key to sign the computed transcript hash. The resulting signature is a cryptographic proof that the agent has generated that specific hash and that it is using a trusted, secure attestation key.

Why It’s Necessary:
- Authentication: The signature provides proof that the party sending the attestation message actually generated the transcript hash. Only the holder of the private key (i.e., a trusted attestation key) can produce a valid signature.
- Non-Repudiation: Once the hash is signed, the agent cannot later deny having participated in the session, which can be important for audit trails or forensic investigations.
- Linking Session to Identity: The signature ties the ephemeral session to the agent’s attestation identity, reinforcing the idea that the agent is running trusted code.
Benefits:
- Enhanced Trust: Verifiers can use the sender’s public key to check that the signature is valid. This confirms the authenticity of the session transcript.
- Tamper Detection: Any change in the transcript would cause the signature verification to fail, alerting both parties to potential attacks.
Generate an Attestation Token

What It Does:

Optionally, each agent obtains or generates an attestation token from a trusted authority. This token (often in the form of a JWT) includes additional claims about the agent’s runtime environment, such as software version, hardware integrity, or secure boot status.

Why It’s Necessary:
- Remote Verification: The attestation token provides external proof that the agent’s environment is genuine and secure. It is typically signed by a trusted authority (e.g., a hardware manufacturer or a corporate attestation service).
- Policy Enforcement: Organizations can define policies based on the token’s claims (e.g., only allowing agents running version 2.0 or higher of a particular software, or that are hosted on certified hardware).
- Supplementing the Signature: While signing the transcript hash confirms that the session data is intact, the attestation token confirms that the agent itself is running in a secure and trusted environment.
Benefits:
- Organizational Trust: Companies can be confident that even if the session is ephemeral, the endpoints meet their strict security standards.
- Flexibility: The token can be tailored to include any necessary information and can be verified by any party that trusts the issuing authority.
Compose Attestation Message

What It Does:

The attestation message is assembled to include the attestation token, the transcript signature, and the transcript hash. This message encapsulates all the evidence that the session was established properly and that the agent’s environment is trusted.

Why It’s Necessary:
- Consolidation of Evidence: By packaging the token, signature, and transcript hash together, the attestation message provides a comprehensive snapshot of both the session’s integrity and the agent’s trustworthiness.
- Standardization: A structured attestation message allows for uniform processing on the receiving side, making verification straightforward.
- Linking the Two Worlds: This message effectively binds the ephemeral cryptographic session (the Noise handshake) to the agent’s trusted state (the attestation token and signature).
Benefits:
- Streamlined Verification: The receiving agent can extract all necessary data from one message, reducing complexity and potential errors.
- Enhanced Accountability: Every attestation message serves as a record that the session was established and validated in accordance with the organization’s security policies.
Exchange & Verify

What It Does:

The attestation message is encrypted using the established session key and transmitted over the secure channel to the peer. Upon receipt, the peer decrypts the message and performs several checks:
- Transcript Hash Comparison: It compares the received transcript hash to its locally computed hash.
- Signature Verification: It uses the sender’s public attestation key to verify the transcript signature.
- Token Validation: It validates the attestation token against trusted authorities.
Why It’s Necessary:
- Integrity and Authenticity: Verifying that the transcript hash matches confirms that the handshake hasn’t been tampered with. Validating the signature and token ensures that the sender is both genuine and operating in a secure state.
- Mutual Trust Establishment: Both agents must successfully verify the attestation data before the session is fully considered trusted. This mutual verification reduces the risk of a compromised or rogue party participating.
- End-to-End Security: By encrypting the attestation message with the session key, the exchange is protected from eavesdropping or tampering, even on untrusted networks.
Benefits:
- Assurance of Trust: Organizations can trust that the communication session not only has strong encryption but also involves endpoints that have proven their integrity in real time.
- Reduction of Attack Surface: Any discrepancies in the transcript hash, signature, or token cause the verification to fail, immediately flagging a potential attack. This minimizes the window during which an attacker could exploit a compromised session.
- Robustness Against MITM Attacks: An attacker would need to forge both a valid attestation token and a matching signature for the altered transcript hash – a feat that is computationally infeasible without the appropriate private keys.

What Organizations Can Expect

Enhanced Trust and Security: Organizations benefit from a dynamic, zero‑trust system where each session is cryptographically verified from the ground up. Even if endpoints (or brokers) are untrusted by default, the attestation phase ensures that only secure, approved environments participate.
Operational Agility: FUSE allows rapid session creation with minimal overhead when speed is crucial, while CRANE provides an extra layer of attestation for high‑security contexts. This dual approach lets organizations deploy a mix of agents, choosing the protocol that best fits the situation.
Future-Proof Flexibility: Thanks to a pluggable and extensible architecture, these protocols can evolve. New cryptographic primitives, attestation methods, or additional security layers can be integrated without a complete overhaul of the system.
Reduced Long‑Term Exposure: By rotating keys and expiring sessions regularly, even if a session key is compromised, the risk is limited to a very short time window. This dynamic nature is especially valuable in environments with untrusted brokers or transient connections.

In our approach, every step of the attestation phase is carefully designed to increase trust and reduce vulnerability:

Record & Compute: Ensures both agents agree on the exact sequence of messages, forming a reliable basis for attestation.
Sign the Hash: Authenticates the session transcript, providing non-repudiation and tamper detection.
Generate an Attestation Token: Offers external proof that the agent’s environment is secure, adding an additional layer of verification.
Compose Attestation Message: Consolidates all necessary evidence into a standardized, easy-to-process format.
Exchange & Verify: Confirms that both endpoints are secure and operating in a trusted state before the session is fully activated.

By integrating these steps, our protocols enable organizations to trust untrusted brokers and dynamic networks—delivering secure, ephemeral, and verified communication sessions that meet the highest standards of modern cybersecurity.

Attestation Flow Diagram

flowchart TD
    Start((Handshake Complete)):::start
    Start --> Transcript((Record & Compute Transcript Hash)):::process
    Transcript --> Sign[/Sign Transcript Hash/]:::process
    Sign --> Token:::decision
    Token --> AttestMsg["Compose Attestation Message"]:::process
    AttestMsg --> Send{"Encrypt & Send Message"}:::process
    Send --> Receive["Receive & Decrypt Attestation Message"]:::process
    Receive --> VerifyHash{Compare Transcript Hashes}:::decision
    VerifyHash --> VerifySig[/Verify Signature Using Public Key/]:::process
    VerifySig --> VerifyToken[(Validate Attestation Token)]:::decision
    VerifyToken --> Accept(("Mark Session as Attested")):::stop
    Accept --> End(("Secure, Trusted Session Established")):::stop

Session Expiration & Key Rotation: Keeping Things Fresh

Even the snazziest secret handshake shouldn’t last forever. In both FUSE and CRANE, session expiration and key rotation limit exposure and maintain forward secrecy. Handshaking and session management is critical. If you want to know more check out my primer on that topic: When Secure Handshakes Collide

Session Expiration: Sessions have a predefined lifetime or expire after a certain number of messages. When a session expires, the agent automatically initiates a new Noise handshake, generating fresh keys. This limits the window during which any one key is valid.
Key Rotation: Even within an active session, keys can be periodically rotated. Frequent rotation means that if a key is compromised, it only affects a small amount of data.

Key Rotation Flow Diagram

flowchart TD
    subgraph Establishment
        A(["fa:fa-cogs Session Established"]):::start --> B(["fa:fa-clock Start Timer"]):::process
    end

    subgraph Messaging
        C(["fa:fa-comments Session Active"]):::process --> D{fa:fa-bell TimerCounter Expires?}:::decision
    end

    subgraph Rotate
        G(["fa:fa-sync Rotate Keys & Expire Session"]):::process --fa:fa-arrow-right--> C
    end

    D -->|Yes| E(["New fa:fa-handshake Handshake"]):::process
    D -->|No| C
    E --> F(["Complete Handshake"]):::process
    F --> G

This cyclic flow ensures that keys are always fresh and that even if an attacker were to intercept a session key, its usability would be severely limited.

Pluggable and Extensible Architecture

One of the most exciting aspects of FUSE and CRANE is their modular design. FUSE and CRANE are built on top of our system of cartridges that our agents can load and automatically gain new abilities.

This pluggable architecture means that as new cryptographic primitives and attestation methods emerge, you can easily integrate them without overhauling the entire protocol.

Alternative Attestation Mechanisms: Today, CRANE might use a simple dummy token or a basic JWT for attestation. Tomorrow, you could integrate TPM-based attestation, Intel SGX quotes, or even blockchain-backed logs. The attestation module is designed to be interchangeable.
Agile Cipher Suite Selection: Since the protocols are built on the Noise framework, you can swap out key exchange algorithms or symmetric ciphers as needed. For example, you might choose to integrate post‑quantum algorithms when they become standardized.
Extensible Trust Policies: With attestation tokens that can embed additional claims (such as software version, operating system state, or expiration dates), organizations can plug in policy engines that enforce fine‑grained trust. If a token fails these checks, the session can be downgraded or terminated.
Interoperability with Traditional Approaches: While FUSE eschews formal attestation for speed, CRANE can be deployed in environments where both attestation and fast key exchange are necessary. The protocols can even interoperate with legacy systems, falling back on a standard Noise handshake if the peer doesn’t support attestation.

This modularity not only future-proofs the system but also allows organizations to tailor the security posture to their needs.

Why Attestation Matters in Our Environment

Even when your communication channels are encrypted with Noise and the messaging bus is protected by TLS, attestation adds a critical layer of security:

Trust Beyond Encryption: Encryption ensures data remains confidential, but attestation verifies that the endpoint is running the expected software in a secure environment. This is crucial when interacting with untrusted brokers.
Dynamic Trust in Decentralized Networks: In environments where agents and brokers are ad‑hoc and transient, traditional PKI may be impractical. Attestation provides on‑demand verification, ensuring that even newly discovered entities are secure.
Limited Exposure via Ephemeral Keys: With session expiration and key rotation, even if an attacker compromises a session key, it’s only valid for a short period. Attestation ensures that every session begins on a secure, verified footing.
Policy-Driven Security: Attestation tokens can carry metadata—like agent identity, software version, or expiration details—which enables organizations to enforce strict access controls.

In short, while ad‑hoc encrypted sessions and TLS protect your data in transit, attestation ensures that each agent is trustworthy at the moment of communication.

Supporting References & Further Reading

Noise Protocol Framework: noiseprotocol.org. Learn about the underlying handshake patterns at Noise Explorer
JWT for Attestation: JWT.io

Explore how tokens are used for secure attestation.

IETF EDHOC: A lightweight authenticated key exchange for IoT devices that incorporates transcript hashing.
NIST SP 800-57 & SP 800-63: Guidelines on key management, rotation, and forward secrecy.
IETF RATS Working Group: Standardizing remote attestation for IoT and other constrained environments.
Uber’s SPIFFE/SPIRE: An example of ephemeral, automatically rotated service identities.
Academic Research on OTR & Double Ratchet: Explore how ephemeral keys and transcript hashing enable forward secrecy.

Final Thoughts

FUSE delivers rapid, ephemeral sessions perfect for fast interactions in untrusted environments, while CRANE adds a robust attestation layer for when trust is paramount.

With deterministic transcript hashing, session expiration, key rotation, and a pluggable architecture, our protocols provide a flexible, future‑proof solution for autonomous agents.

Whether you’re deploying a fleet of IoT devices, coordinating cloud micro-services, or enabling secure brokered communications, FUSE and CRANE empower you to operate in a zero‑trust world with confidence and agility.