Protocol-C is an open-source Python library (pip install aether-protocol-c) that adds a cryptographic authentication layer between an AI decision and its execution. Each decision is signed with a single-use secp256k1 key derived from CSPRNG entropy and destroyed immediately after one signature; execution layers verify the signature before acting, and every accepted decision becomes a tamper-evident, independently verifiable record.

How does Protocol-C relate to CVE-2025-59536?

CVE-2025-59536 (CVSS 8.7), disclosed by Check Point Research, let attacker-controlled project files execute in Claude Code because there was no authentication between instruction and execution. Anthropic patched the specific defect in 1.0.111. Protocol-C does not patch that bug; it is defense-in-depth for the broader class — it authenticates AI decisions you route through it so injected or unsigned instructions are rejected before execution.

Is Protocol-C quantum-safe or post-quantum?

Protocol-C is classical cryptography (secp256k1 ECDSA), not post-quantum and not quantum-sourced. Its resistance to a future quantum attack is a temporal argument: the private key is destroyed within about an hour of creation, long before any Shor's-algorithm attack could complete, so there is no key left to recover. If you need standardized post-quantum signatures (ML-DSA, SLH-DSA), Protocol-C is not a drop-in for that.

What does Protocol-C cost to run?

It is free and open-source under Apache-2.0, with zero mandatory dependencies (Python standard library only). It sources entropy from the OS kernel (CSPRNG), so there is no per-operation entropy cost — unlike quantum-hardware entropy, which can cost on the order of $100 per minute of QPU time.

How do I install and use Protocol-C?

Run pip install aether-protocol-c. Then: from aether_protocol_c import commit, verify, get_seed; result = commit(get_seed(), order_id='decision_001', trade_details={...}, account_state={...}, log_path='audit/audit.jsonl'); assert result['verified']. A CLI is included: aether-protocol-c info | init | demo | commit | verify | logs --verify.

← aethersystems.net
Whitepaper · Aether AI

Protocol-C: A Free, Auditable Authentication Layer for AI Decisions

Closing the instruction-to-execution gap that CVE-2025-59536 exposed — with classical, dependency-free cryptography. Sign each AI decision with a key that exists for one signature and then is gone.

By Brandon Barrante, Aether AI · Published June 3, 2026 · Open-source, Apache-2.0 · Part of the Aether Protocol Family

What it is, in one paragraph. Protocol-C is an open-source Python library — aether-protocol-c — that adds the cryptographic authentication layer missing between an AI's decision and its execution. Every decision is signed with a single-use secp256k1 key derived from fresh CSPRNG entropy, used exactly once, and zeroed from memory immediately after signing. Execution layers verify the signature before acting; unsigned or tampered instructions are rejected. What remains is a tamper-evident, append-only record anyone can verify and no party can forge or back-date — with zero mandatory dependencies and zero per-operation entropy cost.

⭐ Star on GitHub pip install aether-protocol-c

Honest scope, up front. Protocol-C is classical cryptography — not post-quantum and not quantum-sourced. Its resistance to a future quantum attack is a temporal argument, not a hardness claim: the key is destroyed before any such attack could run. The quantum-entropy variant is Protocol-L; this paper is about Protocol-C only.

The problem: a missing layer, not a reasoning bug

On disclosure by Check Point Research, CVE-2025-59536 (CVSS 8.7) allowed attacker-authored project configuration — Hooks, .mcp.json, settings.json, environment variables — to execute arbitrary shell commands and exfiltrate API keys when a developer merely opened an untrusted repository in Claude Code [1]. Anthropic patched the specific defect in Claude Code 1.0.111.

The patch closed that door. It did not close the class of door. The root cause was not a flaw in the model's reasoning; it was the absence of a cryptographic authentication boundary between an AI instruction and its execution. That boundary is missing almost everywhere autonomous AI is deployed: a config file carries instructions to a runtime with no signature; a tool or MCP call carries an action to an executor with no signature; a queue carries a decision to a worker with no signature; a log claims "the agent did X" but is mutable and unprovable. When anyone in the path can write to the channel, anyone can inject.

Anthropic's own Frontier Safety roadmap names "cryptographically verified short-lived identities" as a priority. Protocol-C is one concrete, free, auditable way to build them.

Honest scope. Protocol-C does not patch CVE-2025-59536 — Anthropic did, in 1.0.111. Protocol-C is defense-in-depth for the broader vulnerability class: it authenticates the AI decisions you route through it, so injected or unsigned instructions are rejected before execution. It protects the pipelines you instrument; it is not a drop-in shield for software you do not control.

Why the usual answers fall short

Long-lived signing keys move the risk rather than removing it. One key that signs everything is a single point of catastrophe: steal it once and every past and future record is forgeable.
Application logs are circumstantial — editable, truncatable, and carrying no proof they were not changed. "Trust our logs" is not an authentication model.
Post-quantum signatures (ML-DSA, SLH-DSA) raise the mathematical bar but still rest on a long-lived secret. Valuable, but a different tool than forward-secret, one-shot authentication.

The design: commit, sign once, destroy

Protocol-C signs each decision with its own ephemeral key and destroys the private half immediately after a single signature.

Seed. secrets.token_bytes(32) — 256 bits of OS-CSPRNG entropy. Only the SHA-256 hash of the seed is ever recorded; the raw seed is never stored.
Key. A secp256k1 private key is derived from the seed via HMAC-SHA256, reduced mod the curve order. The implementation is pure Python — no third-party crypto dependency — so the whole signing path is auditable.
Sign once. The decision dict is canonicalized and SHA-256-hashed, then signed with ECDSA using RFC 6979 deterministic-k (eliminates nonce-reuse key recovery) and low-s normalization.
Destroy. The private key integer is zeroed in place the instant the signature is produced. A second signing attempt raises. The key exists for milliseconds.
Record. The commitment is appended to an append-only JSONL log (the source of truth) with a companion SQLite index for fast lookups and rotation.
Verify. Verification needs only the public key embedded in the signature — no secret, no server, no trust in storage. Changing one byte of the committed data breaks verification.

For decide → act → settle workflows, Protocol-C provides a three-phase chain — DECISION_COMMITMENT, EXECUTION_ATTESTATION, SETTLEMENT_FINALITY — each independently keyed, so the whole chain is tamper-evident end to end.

Security properties

	Property	What backs it
P1	Seed unpredictability	OS CSPRNG (`secrets`) entropy is computationally unpredictable
P2	Unforgeability	secp256k1 ECDSA; forging a signature means solving the ECDLP
P3	Temporal safety	key lifetime ≪ any near-term quantum attack window; the key is destroyed before an attack could complete
P4	Perfect forward secrecy	each decision/phase uses an independent seed + key pair
P5	Tamper detection	any change to the committed bytes invalidates the signature

How this maps to the CVE

The CVE's root cause was unauthenticated instruction → execution. Protocol-C inserts a verifiable checkpoint:

Sign before dispatch — the component that decides signs the decision with a one-shot key.
Verify before execute — the component that acts checks the signature and refuses unsigned or altered instructions.
Prove after the fact — every accepted decision is an independently verifiable record, not a log you have to trust.

An attacker who injects instructions into a config file, queue, or tool channel cannot produce a valid signature, because the signing key existed only inside the deciding component and was destroyed after use. The injected instruction fails verification and is dropped. This works only for the boundaries you instrument — Protocol-C is a primitive for building authenticated AI pipelines, not a perimeter around software you do not control.

Economics: $0 entropy at scale

Quantum entropy is expensive — on the order of $100 per minute of QPU time. For commitment workloads that do not require physical non-determinism, that cost is pure overhead. Protocol-C sources entropy from the OS kernel (CSPRNG): same chain format, same verification path, zero QPU cost, zero mandatory dependencies. Systems that later need quantum-sourced entropy can adopt the separate Protocol-L without changing the commitment or verification model.

Honest about "quantum-safe"

secp256k1 ECDSA is classical and is not post-quantum. A large fault-tolerant quantum computer running Shor's algorithm could recover a private key from its public key.
Protocol-C's mitigation is temporal, not mathematical: the private key is destroyed within ~1 hour (default, configurable) of creation — far inside any plausible attack window. A zeroed key cannot be recovered. The defense is the key's absence, not the algorithm's strength.
If your threat model requires standardized post-quantum signatures, Protocol-C is not a drop-in for that. No physical-unpredictability or quantum-hardware claims are made for Protocol-C; hardware entropy sources are out of scope for this library.

Quickstart

pip install aether-protocol-c     # zero mandatory dependencies
aether-protocol-c info            # version, Python, entropy source, key lifetime
aether-protocol-c demo            # sample commit -> verify, end to end

from aether_protocol_c import commit, verify, get_seed

result = commit(
    get_seed(),
    order_id="decision_001",
    trade_details={"action": "deploy", "target": "prod"},
    account_state={"capital": 0, "equity": 0, "open_positions": [],
                   "risk_used": 0.0, "risk_limit": 1.0, "nonce": 1, "timestamp": 0},
    log_path="audit/audit.jsonl",
)
assert result["verified"]                                   # signed + verified
assert verify(result["commitment"], result["signature"])    # anyone can re-check

Audit a log at any time, with tamper detection: aether-protocol-c logs --log audit/audit.jsonl --verify.

Frequently asked questions

What is Protocol-C?

An open-source Python library (aether-protocol-c) that signs each AI decision with a single-use secp256k1 key destroyed after one signature, verifies before execution, and keeps a tamper-evident audit log.

How does it relate to CVE-2025-59536?

The CVE exposed the missing authentication layer between AI instruction and execution. Anthropic patched the specific Claude Code defect; Protocol-C is defense-in-depth for the broader class, authenticating the decisions you route through it.

Is it quantum-safe or post-quantum?

Classical, with a temporal safety margin — not post-quantum and not quantum-sourced. The key is destroyed before any quantum attack could complete.

What does it cost?

Free and open-source under Apache-2.0, zero mandatory dependencies, zero per-operation entropy cost.

About the authors

Aether AI, founded by Brandon Barrante, builds verifiable AI infrastructure. Protocol-C is the open, free tier of the Aether Protocol Family (C / L / T). Source, tests, and CLI are released under Apache-2.0 at github.com/DBarr3/protocol-c.

References

Check Point Research (2026). RCE and API Token Exfiltration Through Claude Code Project Files (CVE-2025-59536 / CVE-2026-21852). research.checkpoint.com.
Tenable. CVE-2025-59536. tenable.com/cve/CVE-2025-59536.
Pornin, T. (2013). RFC 6979: Deterministic Usage of DSA and ECDSA. IETF.
Adams, C. et al. (2001). RFC 3161: Time-Stamp Protocol (TSP). IETF.