The Internet Wasn't Built for AI Agents. AURORA Fixes That

Introducing the AURORA Protocol — a new IETF Internet-Draft for securing the Agentic Web

The One-Sentence Version

AURORA is a next-generation, dual-layer network security protocol designed for the Agentic Web. While existing frameworks handle basic communication and semantic translation, they fail to prove that a payload originated from an attested software stack executing inside a trusted runtime environment, or cryptographically attribute which human principal authorized that machine's actions.

AURORA solves both The Puppet Problem and The Rogue Agent Problem simultaneously by unifying hardware-isolated machine attestation with cryptographically bound human delegation.

Why I Wrote This Protocol

We're watching something remarkable happen on the internet right now. AI agents — autonomous software systems that can browse, negotiate, purchase, and transact — are stepping out of sandboxed labs and onto the open web. They're booking flights. They're executing trades. They're signing contracts on our behalf.

And the internet has absolutely no idea how to handle them.

Think about it. When an API request arrives at a financial gateway carrying a valid key and asking to move $10,000, the server today can answer exactly two questions:

1. Who owns this key? (Identity)

2. Is this valid JSON? (Syntax)

That's it. It can't tell you whether a human is secretly pulling the strings behind that "autonomous" agent. It can't tell you which person authorized the agent to spend that money, or whether the agent's software has been tampered with mid-flight. It's cryptographically blind to everything that actually matters.

I built AURORA because the Agentic Web needs a trust layer that legacy security was never designed to provide.

The Two Problems Nobody Is Solving

Every conversation about "AI security" eventually lands on prompt injection or model alignment. Those matter. But there are two structural vulnerabilities baked into the internet's architecture itself that no one is addressing with a standardized protocol:

Problem 1: The Puppet Problem

"Is this really a machine talking, or is a human hiding behind one?"

CAPTCHAs were built to stop bots from pretending to be humans. But we have no equivalent mechanism to stop humans from pretending to be trusted bots.

Picture this: an attacker sets up a script that mimics an AI trading agent. It presents valid API credentials and speaks fluent JSON. From the server's perspective, it looks identical to a legitimate autonomous system — but behind the curtain, a human adversary is intercepting requests, manipulating payloads, and proxying them back. The server literally cannot tell the difference.

This is what I call puppeteering: a man-in-the-loop attack on machine-to-machine infrastructure. And it's invisible to every authentication protocol deployed today.

Problem 2: The Rogue Agent Problem

"The machine made the decision. Who's accountable?"

AI agents are dynamic code runtimes. They plan, they reason, they invoke tools, they spend money. But when an agent executes a binding financial transaction, there is no standardized way to answer a deceptively simple question: who authorized this?

Imagine an agent suffers a context injection, enters a logical loop, and executes a $50,000 asset transfer that nobody asked for. The receiving server holds a valid transaction — but it has no cryptographic record linking that transaction back to a specific human principal. No chain of accountability. No scoped authorization boundary. No "Power of Attorney" that defines what this machine was actually allowed to do.

The internet's plumbing simply doesn't have a pipe for that kind of attribution.

How AURORA Solves Both — Simultaneously

AURORA's core architectural mandate can be stated plainly:

An agent should be able to prove its authority, its scope, and its runtime integrity.

The protocol achieves this through a dual-layer handshake — a unified cryptographic exchange where both layers must pass for a connection to be accepted. Fail either one, and the request is rejected. No exceptions.

Layer 1: "Prove You're Real Silicon" — Runtime Integrity Attestation

This is the anti-puppeteering layer. Its job is to provide cryptographically verifiable evidence that a payload was generated by software executing inside a hardware-attested enclave — not by a human spoofing automation from a coffee shop.

The mechanism is called HAPCHA (Hardware-Anchored Proof Challenge for Autonomous Hosts), and it works through three interlocking components:

Attested Execution Duration (AED)

When the target gateway sends a time-bound cryptographic nonce to the agent, the agent's Trusted Execution Environment (TEE) — think Intel TDX, AMD SEV-SNP, or ARM TrustZone — records the exact millisecond it received that nonce and the exact millisecond it finished generating the response. This silicon-measured processing delta is called the Attested Execution Duration.

The enclave chip itself co-signs this timing measurement directly into the attestation report. You can't fake it from userspace. The hardware is the witness.

The gateway enforces a ceiling: if the processing time exceeds the maximum expected for that agent's workload, the connection is rejected. A human intercepting, reading, modifying, and forwarding a payload would blow the timing budget. Machines are fast. Humans in the loop are not.

Dynamic Round-Trip Time Profiling

But what about relay attacks — where an attacker proxies the nonce to a remote enclave and pipes the answer back? AURORA handles this by measuring the connection's actual network propagation baseline during the handshake:

RTT_allowed = RTT_base + Delta_T_exec + epsilon

The epsilon jitter buffer (default: 10ms) accounts for NTP clock drift and transient network variance. This formula natively accommodates geographic differences — a connection from Mumbai and a connection from Sydney will have different RTT baselines, and the protocol adjusts automatically. Satellite links, mobile networks, inter-continental fiber — all accounted for.

Hardware Enclave Co-Signing

The agent's output payload and the full attestation report must be signed by a key that was generated and stored exclusively inside the enclave boundary. This signature is anchored directly to the physical chip. The gateway verifies it against the platform's attestation service before accepting anything.

To be precise about what this does and does not prove: enclave attestation proves the integrity of the runtime environment. It does not prove intent, consciousness, or autonomy. It proves that the declared software stack ran inside verified hardware within a measurable timing envelope. That's a very specific — and very useful — guarantee.

Layer 2: "Prove You Have Permission" — Authority Attestation

Once Layer 1 confirms what is running and where, Layer 2 answers who authorized it and what it's allowed to do.

The mechanism here is the Delegated Authority Token (DAT) — an immutable, cryptographically signed token issued directly by a human principal or corporate entity. Think of it as a machine-readable Power of Attorney, but with hard cryptographic enforcement.

What's Inside a DAT?

Every DAT carries four mandatory scope-attenuation claims:

The gateway enforces every one of these boundaries. Try to invoke an API not in your permitted contexts? Rejected. Exceed your spend limit? Rejected. Token expired? Rejected. And critically — the DAT doesn't exist in isolation.

The Cross-Layer Lock

Here's the design detail I'm most proud of: the DAT is cryptographically bound to the enclave's hardware key. The human principal signs the token explicitly locking it to the SHA-256 hash of the Enclave Public Key that was generated inside the physical silicon chip.

What does this prevent? If an attacker extracts a DAT from memory and tries to use it on a different machine — even an identical one — the hardware key hash won't match. The token is physically pinned to one specific piece of silicon. You can't peel the authorization off one machine and paste it onto another.

The Full Handshake — How It All Flows

Here's the complete protocol exchange, step by step:

Both layers must pass. There is no "Layer 1 only" mode. The protocol was designed this way deliberately: proving your runtime is clean but having no authority mandate is just as dangerous as having a signed mandate running on compromised hardware.

Interoperability: Speaking the Machine's Language

Here's a bonus that AURORA builds into the handshake: format negotiation.

When an agent connects, it declares its preferred serialization formats via an aurora-accept header — Protocol Buffers, JSON-RPC, plain JSON, etc. If the gateway supports a more efficient format, it signals back via aurora-content-type and the entire session switches to machine-optimized serialization.

Why does this matter? Because today, when AI agents browse the web, they receive full HTML pages complete with CSS rendering hints, JavaScript tracking payloads, cookie banners, and visual layout templates. All of that is dead weight for a machine. AURORA lets authenticated agents negotiate a lean, structured data channel — cutting latency and bandwidth while keeping the security guarantees intact.

Gateways that don't support format switching simply continue serving standard HTTP responses. No penalty for either side.

Security: The Attack Vectors We Thought About

An IETF draft isn't worth much if it only works in the happy path. Here are the adversarial scenarios AURORA explicitly addresses:

Relay Puppeteering

An attacker intercepts the nonce, ships it to a remote enclave, and pipes the answer back. Defeated by: Dynamic RTT profiling — the relay adds measurable network latency that exceeds the per-connection deadline.

Token Theft & Cross-Machine Reuse

An attacker extracts a DAT from memory and loads it onto different hardware. Defeated by: Cross-layer cryptographic binding — the DAT is locked to the SHA-256 hash of the original enclave's public key.

Replay Attacks Across Gateways

A network observer captures a valid signed payload and replays it to a different gateway. Defeated by: All session nonces are bound to the host gateway's domain identifier. A valid payload for Gateway A is cryptographically invalid for Gateway B.

Prompt Injection & Model Jailbreaks

Even a secure enclave faithfully signs malicious output if the agent's reasoning system has been compromised. Mitigated by: Semantic Attestation — the enclave cryptographically measures and appends the agent's base system prompt hash and parameter hashes alongside the payload execution trace.

TCB Degradation

A side-channel vulnerability is discovered in the enclave hardware itself. Handled by: AURORA enforces real-time TCB security level validation. Outdated or unpatched firmware triggers an immediate graceful connection step-down.

Token Revocation

A principal needs to kill an agent's authorization mid-session. Supported by: Out-of-band revocation channels. Gateways must check the DAT against a high-availability revocation index (Bloom filter or distributed revocation list) before every transaction, not just at session initiation.

Privacy: What We're Careful About

The DAT carries identity-linked data, so AURORA specifies explicit privacy constraints:

• Principal Identity Exposure: Gateways must not log or retain raw DAT payloads beyond what's needed for verification and audit

• Enclave Fingerprinting: Attestation reports contain platform identifiers that could track a device across sessions — implementations should rotate enclave signing keys at defined intervals

• Financial Metadata: The DAT's spending limit is confidential commercial data — gateways must not disclose it to third parties

What Exists Today (and What Needs Building)

Let me be upfront: as of this writing, no production implementation exists. This is an alpha draft — draft-khera-aurora-00 — published as an IETF Internet-Draft. Here's what's in progress:

ComponentStatusReference Gateway Validator (Layer 1 + Layer 2 checks)Pre-AlphaDAT Issuance Library (generate, sign, revoke tokens)Specification PhaseTEE Integration Layer (Intel TDX / AMD SEV-SNP adapters)Research Phase

This is intentionally early. The protocol needs scrutiny from cryptographers, systems architects, TEE implementors, and security researchers before it hardens into something production-ready.

Why This Matters Now

We're at an inflection point. AI agents are no longer theoretical — they're transacting on real infrastructure with real money. Every major cloud provider is racing to build agent frameworks. MCP is standardizing how agents talk to tools. But the trust layer underneath all of this is still duct-taped together from static API keys and OAuth tokens that were designed for humans clicking through browser flows.

AURORA doesn't replace those systems. It adds a layer that they fundamentally cannot provide: cryptographic proof of computational provenance and human-principal attribution.

The architectural mandate is simple:

"An agent should be able to prove its authority, scope, and runtime integrity."

If the Agentic Web is going to handle high-value commerce, legal agreements, and financial transactions at machine speed, that proof can't be optional. It has to be the protocol.

Get Involved

AURORA is open source (MIT licensed) and actively seeking contributors:

• Read the full spec: draft-khera-aurora-00 on IETF Datatracker

• Contribute on GitHub: mastermindankur/aurora-protocol

• File issues: Edge cases, cryptographic concerns, implementation questions — all welcome

• Contact: ankurkhera@iitdalumni.com

If you're building agent infrastructure, deploying TEE-backed workloads, or thinking about how machine commerce should work at scale — I'd love your input. Open a PR, file an issue, or just email me. Let's build the trust layer the Agentic Web deserves.