Agent Unification, Runtime, and Operational Responsibility Attestation (AURORA)

Introduction As autonomous AI agents migrate from isolated testing environments to the public open web, network infrastructure must pivot to support workloads natively optimized for machine execution. While emerging standards address data semantic translation (e.g., Model Context Protocol), they rely entirely on legacy authentication frameworks such as static API keys or human-centric OAuth tokens. AURORA introduces a standardized architecture to secure agentic interactions by requiring parallel proofs of computational provenance and explicit operational mandate.

Conventions Used The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses the following terms:

Agent (or Connecting Agent): An autonomous AI software runtime that initiates network connections and executes transactions on behalf of a human principal without real-time human intervention.
Principal: The human individual or corporate legal entity that authorizes an agent's actions and is cryptographically attributed as the authorizing party for each transaction. Note: AURORA establishes attribution, not legal liability. Determination of legal liability from this attribution record is the domain of applicable law and courts, not the protocol.
Target Gateway: The network endpoint or host server that receives and validates AURORA protocol handshake payloads before granting access to resources or executing transactions.
Enclave (or Hardware Security Enclave): A physically isolated, tamper-resistant execution environment provided by hardware (e.g., Intel TDX, AMD SEV-SNP, ARM TrustZone) that generates cryptographically verifiable attestation reports.
Delegated Authority Token (DAT): An immutable, cryptographically signed token issued by a human principal that encodes the agent's operational scope, financial limits, and expiry.
Hardware-Anchored Proof Challenge for Autonomous Hosts (HAPCHA): The Layer 1 mechanism by which a gateway verifies that a response was generated by a software agent executing within a hardware-attested enclave, within a defined timing ceiling consistent with uninterrupted machine execution.
Attested Execution Duration (AED): The silicon-measured processing delta between nonce ingestion and payload generation, co-signed by the enclave chip into the attestation report.
Puppeteering: An attack where a human adversary injects manual steps or latency into a machine-to-machine interaction to manipulate the output of an agent while mimicking autonomous execution.
Trusted Computing Base (TCB): The set of hardware, firmware, and software components critical to the security of an enclave. A TCB downgrade indicates a known vulnerability in one of these layers.

Problem Statements The current internet fabric lacks native defenses against two critical structural vulnerabilities introduced by autonomous machine agents: The Puppet Problem and The Rogue Agent Problem.

Problem Statement 1: The Puppet Problem (Runtime Integrity Vulnerability) Current network endpoints cannot differentiate between a software agent executing within a verified hardware enclave and a human adversary utilizing automated scripts to mimic machine-originated traffic ("puppeteering"). Without a mechanism to attest the runtime environment of an endpoint, systems are exposed to Sybil attacks, data interception, and man-in-the-loop payload manipulation. Legacy CAPTCHAs stop uncoordinated bots from mimicking humans, but the internet lacks a standardized mechanism to attest that a payload originated from a specific, verified software stack --- rather than from a human operator proxying requests through automation scripts.

Problem Statement 2: The Rogue Agent Problem (Authority Vulnerability) AI agents operate as dynamic code runtimes capable of planning, invoking tools, and committing financial or computational assets. When a machine endpoint initiates a binding contract, a target server cannot verify under whose authorization the machine is acting, nor attribute the transaction to a specific human principal. If an agent suffers a logical loop or context injection and executes an unauthorized asset transfer, the receiving server cannot attribute the transaction to a specific authorizing human principal. The internet has no standardized, cryptographically attenuated authorization token designed for software-mediated delegation --- analogous to a scoped "Power of Attorney" --- that would allow post-incident attribution.

The AURORA Solution: Dual-Layer Protocol Specification AURORA addresses both problem vectors simultaneously using a unified, two-key cryptographic handshake. A request is explicitly rejected unless both the Runtime Integrity Layer (Layer 1) and the Mandate Layer (Layer 2) are verified concurrently.

Core Handshake Flow Overview The AURORA protocol execution sequence flows as follows:

| | | + DAT attached | | | + aurora-accept: | | | [protobuf, json-rpc, | | | json] (Sec. 4.1) | | | | | |<-- 2. Time-Bound Nonce -----| | | | |--- 3. Ingest Nonce & Generate Output ---------------->| | | |<-- 4. Sign Payload + Attestation Report --------------| | | |--- 5. Return: Signed Output + Enclave Report + DAT -->| | | | | |-- [6a. LAYER 1 CHECK] | | | Runtime Integrity | | | - AED: timing verify | | | - Enclave key verify | | | - Nonce binding check | | | - RTT ceiling check | | | | | |-- [6b. LAYER 2 CHECK] | | | Authority Attestation | | | - DAT signature valid | | | - Principal identity | | | - Scope & spend limit | | | - Chronological ceil. | | | - Enclave key binding | | | | | [Both layers PASS?] | | / \ | |<-- 7a. ACCEPT --------- ------> 7b. REJECT | | + aurora-content-type: Layer fault | | negotiated format (Sec. 4.2) + reason code | | (or fallback: json) (Sec. 4.3) | | | | ]]>

Architecture Layer 1: Runtime Integrity Attestation (Mitigating Problem 1) To provide cryptographically verifiable evidence that a payload originated from a software agent executing within a hardware-attested runtime environment, the protocol MUST enforce a rigorous computational speed challenge designated the Hardware-Anchored Proof Challenge for Autonomous Hosts (HAPCHA). HAPCHA does not claim to prove machine consciousness or intent; it attests that the responding endpoint executed within a measurable timing envelope consistent with uninterrupted software execution inside a verified enclave. HAPCHA accounts natively for global network variances and is composed of three interlocking mechanisms: Attested Execution Duration (AED): Upon ingesting the gateway's time-bound cryptographic Nonce, the agent's Trusted Execution Environment (TEE) MUST use its internal, hardware-isolated secure clock to record the exact millisecond of nonce ingestion (T_start) and the exact millisecond of payload generation completion (T_end). The enclave MUST calculate the silicon processing delta:

The enclave MUST co-sign this processing delta directly into the hardware attestation report alongside the output payload. The Target Gateway MUST enforce an operator-configured AED ceiling (AED_max) and MUST reject any connection where:

AED_max ]]> The AED_max value is deployment-specific and MUST be configured by the gateway operator based on the agent's declared context window size and the measured baseline throughput of the target enclave hardware. As a non-normative reference point, a 4K-token inference task on current-generation TEE hardware typically completes within 15-50ms under unloaded conditions. Gateways MUST NOT apply a single universal ceiling across all agent types; doing so would generate false positives for agents processing large context windows (e.g., 128K tokens) or operating on resource-constrained silicon. Dynamic Round-Trip Time (RTT) Profiling: To prevent relay puppeteering attacks (where a remote human solves challenges and proxies them back to a local enclave), the gateway MUST measure the connection's actual propagation baseline (RTT_base) during the cryptographic handshake. The Target Gateway MUST set the per-connection network deadline as:

where epsilon is a configurable jitter tolerance buffer (RECOMMENDED default: 10ms) that accounts for sub-millisecond clock drift between the agent's TEE hardware clock and the gateway's NTP-synchronized clock , as well as transient network queuing variance. Operators MAY increase epsilon for high-jitter network paths (e.g., satellite links) but SHOULD NOT exceed 50ms to preserve the anti-puppeteering guarantee. This formula natively accommodates geographic propagation variances, high-latency satellite links (e.g., Starlink), and regional fiber congestion without sacrificing security. Hardware Enclave Co-Signing: The agent's runtime environment MUST execute within a physically isolated hardware security enclave (e.g., Intel TDX, AMD SEV-SNP, or ARM TrustZone). The enclave chip MUST sign the output payload and attestation report using a key that is generated and stored exclusively within the enclave boundary, anchoring the data directly to the enclave hardware. This signature provides evidence that the payload was generated by the declared software stack within the attested enclave boundary. Gateways MUST verify the enclave signature against the platform's attestation service before accepting any payload. Note: enclave attestation proves the integrity of the runtime environment, not the intent or autonomy of the executing agent.

Architecture Layer 2: Authority Attestation (Mitigating Problem 2) Once runtime integrity is attested by Layer 1, the agent MUST present its Delegated Authority Token (DAT) to cryptographically attribute the session to an authorizing human principal and bind explicit operational scope. The DAT establishes who authorized this agent to act and within what boundaries --- providing an attribution record from which legal accountability may subsequently be determined by the appropriate authority. Gateways MUST reject any connection that passes Layer 1 but omits a valid DAT. The Delegated Authority Token (DAT): The agent MUST transmit an immutable, cryptographically signed token originated directly by its human principal or corporate entity. The DAT MUST be signed using the principal's private key and MUST be bound to the agent's Enclave Public Key hash to prevent cross-machine token reuse (see Section 5.6). The DAT cryptographically attributes the session to the signing principal; it does not constitute legal proof of liability, which is determined by applicable law. Scope Attenuation Claims: The DAT payload MUST enforce rigid operational boundaries that the gateway acts upon to restrict usage: Principal Identifier: The verifiable identity of the entity cryptographically attributed as the authorizing party for this transaction, expressed as one of: an X.509 Distinguished Name (DN) bound to a TLS client certificate , a corporate public key registered with a recognized Certificate Authority (CA), or a decentralized identifier (DID) for deployments operating within blockchain-native infrastructure. Financial Allocation Limit: The maximum capital allocation (e.g., expressed in micro-denominations of currency or gas units) the machine is authorized to spend per transaction or session window. Gateways MUST reject transactions that would cause cumulative spend to exceed this limit within the session window. Functional Permitted Contexts: An immutable array restricting allowed API calls or tool pathways (e.g., Read_Data, Execute_Trade). Gateways MUST reject any request invoking a pathway not present in this array. Chronological Ceiling: A hard expiry timestamp after which the DAT MUST be considered invalid. Gateways MUST reject expired tokens and MUST NOT accept token re-use across separate session windows. A new DAT MUST be issued by the human principal upon expiration.

Interoperability & System Optimization Upon successful dual-layer verification, gateways SHOULD switch the active session to a machine-optimized serialization format to eliminate unnecessary presentation-layer overhead (e.g., CSS rendering hints, HTML template wrappers, and visual tracking payloads). This section defines the protocol mechanism by which this capability is negotiated.

Agent Capability Declaration During session initiation (Step 1 of the handshake defined in Section 3.1), the connecting agent MUST include an "aurora-accept" header field declaring its supported machine-optimized serialization formats in descending order of preference:

Gateways MUST parse this field before initiating the HAPCHA challenge. If the field is absent, the gateway MUST assume the client requires standard HTTP/HTML responses and MUST NOT attempt a format switch.

Gateway Format Switch Signal Upon completing successful dual-layer verification (Steps 6a and 6b), the gateway MUST include an "aurora-content-type" header in the ACCEPT response (Step 7a) to signal the negotiated format for all subsequent communication within the session:

The gateway MUST select the highest-preference format from the agent's declared "aurora-accept" list that the gateway itself supports. If no mutually supported format exists, the gateway MUST fall back to standard JSON (application/json) and MUST NOT terminate the session.

Fallback Behavior Gateways that do not implement machine-optimized format switching MUST continue to serve standard HTTP responses and MUST NOT penalize or reject agents that include the "aurora-accept" header. Format optimization is OPTIONAL for gateway implementors; dual-layer security verification (Sections 3.2 and 3.3) remains REQUIRED regardless of whether format negotiation is supported.

Security Considerations

Network Latency & Clock Drift Mitigation The Hardware-Anchored Proof Challenge for Autonomous Hosts (HAPCHA) relies heavily on sub-millisecond precision. On global networks, legitimate connections may fail due to Network Time Protocol (NTP) asymmetry or geographic routing paths. Gateways MUST implement dynamic round-trip time (RTT) profiling as specified in Section 3.2 to prevent false-positive fault generation across satellite, mobile, and inter-continental network segments.

Trusted Computing Base (TCB) Degradation & Enclave Recovery Hardware-level vulnerabilities discovered in legacy architectural enclaves (e.g., side-channel speculation leaks) could compromise local keys. AURORA enforces a strict validation requirement matching the TCB security level against real-time hardware status providers. Outdated or unpatched silicon firmware layers MUST trigger an immediate, graceful connection step-down.

Authority Token Revocation Lifecycle A human principal MUST retain out-of-band revocation capabilities to invalidate a Delegated Authority Token (DAT) at any time. Concrete revocation triggers include: Unauthorized Scope Breach: The agent invokes an API call or tool pathway not listed in the DAT's Functional Permitted Contexts field. Financial Threshold Violation: Cumulative transaction spend within a session window approaches or exceeds the DAT's Financial Allocation Limit, triggering a mandatory principal re-authorization. Enclave Integrity Failure: The hardware enclave reports a Trusted Computing Base (TCB) status downgrade or attestation key compromise during an active session. Principal-Initiated Signal: The human principal transmits an explicit revocation command via an authenticated out-of-band channel (e.g., a signed revocation payload referencing the DAT's unique identifier). Gateways MUST cross-check the DAT identifier against a centralized, high-availability revocation index (e.g., a Bloom filter or distributed revocation list) before every transaction execution, not only at session initiation.

Replay Attack Vectors on Multi-Gateway Environs A compromised network observer could intercept a valid Layer 1 co-signed payload and attempt a parallel execution replay against an alternative gateway within the expiration window. To mathematically block this, all gateway session nonces MUST bind cryptographically to the host gateway's domain identifier.

Cognitive Puppeteering Vulnerabilities (Prompt Injection) Even if an agent executes securely within hardware enclaves, it remains vulnerable to prompt injection or model alignment jailbreaks that override its reasoning system. In this scenario, the hardware enclave faithfully signs malicious output logic. To mitigate this cross-layer threat, Layer 1 MUST implement Semantic Attestation, requiring the enclave to cryptographically measure and append the agent's immutable base system prompt and system parameter hashes directly alongside the payload execution trace.

Cryptographic Cross-Layer Token Binding If a Delegated Authority Token (DAT) is decoupled from its original machine context, an attacker could extract it from memory and pass it to an un-attested machine. AURORA fully neutralizes this attack vector by forcing Layer 2 to cryptographically bind to Layer 1: the human principal signs the DAT explicitly locking it to the SHA-256 hash of the unique Enclave Public Key generated inside the physical chip. The DAT cannot be validated on any other piece of physical silicon.

Privacy Considerations The AURORA protocol processes and transmits identity-linked data that carries significant privacy implications. Implementors MUST account for the following:

Principal Identity Exposure The Delegated Authority Token (DAT) contains a Principal Identifier (e.g., an X.509 Distinguished Name or corporate public key) that is transmitted to the Target Gateway on every session initiation. Gateways MUST NOT log or retain raw DAT payloads beyond the minimum duration required for transaction verification and audit trail purposes.

Enclave Attestation Report Linkability Hardware attestation reports contain platform-specific identifiers (e.g., enclave measurement values) that could be used to fingerprint a specific physical device across sessions. Implementations SHOULD rotate enclave signing keys at defined intervals to limit long-term cross-session correlation of a single agent's hardware identity.

Financial Metadata Minimization The DAT's Financial Allocation Limit field exposes agent spending capacity to the Target Gateway. Gateways MUST treat this field as confidential commercial data and MUST NOT disclose it to third parties outside the scope of the verified transaction.

Implementation Status This section records the implementation status of the AURORA protocol in accordance with . As of the date of this Internet-Draft, no production implementations of the full AURORA dual-layer handshake exist. The following components are under active development: Reference Gateway Validator: A prototype Target Gateway validator implementing Layer 1 (HAPCHA/AED timing checks) and Layer 2 (DAT signature and scope verification) is planned as an open-source reference implementation. Status: Pre-Alpha. DAT Issuance Library: A library for human principals to generate, sign, and revoke Delegated Authority Tokens is under design. Status: Specification phase. TEE Integration Layer: Adapter libraries for Intel TDX and AMD SEV-SNP to produce AURORA-compatible attestation reports are planned. Status: Research phase. Contributions and early implementations are welcomed via the project repository at: https://github.com/mastermindankur/aurora-protocol

IANA Considerations This document does not currently request any registry actions from IANA. Future revisions defining specific JSON Web Token (JWT) claim registrations for the Delegated Authority Token (DAT) will utilize the parameters established in .