Cedulon Threat Narratives
draft-dogru-cedulon-threats-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Emek Can Doğru | ||
| Last updated | 2026-09-17 | ||
| Replaces | draft-dogru-cedulon | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
companion implementation and test vectors
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-dogru-cedulon-threats-00
Network Working Group E. C. Dogru
Internet-Draft VERAX TEKNOLOJI LIMITED SIRKETI
Intended status: Informational 17 September 2026
Expires: 21 March 2027
Cedulon Threat Narratives
draft-dogru-cedulon-threats-00
Abstract
This document records the threat narratives and attack paths that sit
behind the Cedulon core requirements. It does not define those
requirements. T11 (checkpoint suppression) is recorded in the
checkpoint companion, not here.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 21 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Dogru Expires 21 March 2027 [Page 1]
Internet-Draft Cedulon Threats September 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. T1: Prompt injection leads to unauthorized spend . . . . . . 2
3. T2: Runaway agent (loop spend) . . . . . . . . . . . . . . . 3
4. T3: Replay of payment authority . . . . . . . . . . . . . . . 3
5. T4: Receipt forgery or repudiation . . . . . . . . . . . . . 3
6. T5: Policy bypass via direct rail access . . . . . . . . . . 3
7. T6: TOCTOU between policy check and payment . . . . . . . . . 3
8. T7: Signing-key leakage . . . . . . . . . . . . . . . . . . . 4
9. T8: Counterparty price gouging or defective delivery . . . . 4
10. T9: PII leakage into the transparency log . . . . . . . . . . 4
11. T10: Secret spend via rail bypass . . . . . . . . . . . . . . 4
12. T12: Settlement without a recorded receipt . . . . . . . . . 4
13. Security Considerations . . . . . . . . . . . . . . . . . . . 5
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
15.1. Normative References . . . . . . . . . . . . . . . . . . 5
15.2. Informative References . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
The core document [CEDULON-CORE] is authoritative for protocol
requirements. This document is informational. A requirement
identifier that appears here is a citation, not a definition. The
texts below are the narratives for T1 to T10 and T12. T11 lives in
[CEDULON-CHECKPOINT], not here.
2. T1: Prompt injection leads to unauthorized spend
An attacker plants instructions in tool output, a web page, or a
retrieved document. The agent then calls a spend tool outside the
principal's intent.
Policy is not derived from model text. The PDP evaluates structured
fields only. A spend tool call that presents no Trade Manifest MAY
proceed only as noManifest and MUST still pass limit, velocity, and
scope checks; a manifest the PDP cannot verify against a key supplied
out of band is refused, and an expired one is denied. Defined in
[CEDULON-CORE]: MUST-T1-1, MUST-T1-2, MUST-T3-3, MUST-T4-16.
Dogru Expires 21 March 2027 [Page 2]
Internet-Draft Cedulon Threats September 2026
3. T2: Runaway agent (loop spend)
A stuck tool loop or recursive planner issues many payments.
Velocity and cumulative-limit counters live in the PDP. Fail-closed:
if the engine is missing or throws, the result is deny. Defined in
[CEDULON-CORE]: MUST-T2-1, MUST-T2-2, MUST-T2-3, MUST-T2-4.
4. T3: Replay of payment authority
An observer replays a signed payment payload, mandate, or Cedulon
decision token.
Every gated spend carries a unique nonce. The nonce store rejects a
second use. Manifests expire. Decision tokens are single-use and
bound to request bytes. Defined in [CEDULON-CORE]: MUST-T3-1, MUST-
T3-2, MUST-T3-3, MUST-T3-4.
5. T4: Receipt forgery or repudiation
A party alters a receipt, invents a receipt, or denies a real spend.
Receipts are signed. Verification covers the signed bytes. A hash
chain links receipts. Tamper of one byte fails verify. Defined in
[CEDULON-CORE]: MUST-T4-1 through MUST-T4-21 as the core table lists.
6. T5: Policy bypass via direct rail access
The agent or an attacker calls the rail (x402 facilitator, wallet,
card API) without the PDP.
The only payment function is the adapter that calls the PDP first.
Deployments must make ungated rail credentials unavailable to the
model. Defined in [CEDULON-CORE]: MUST-T5-1, MUST-T5-2.
7. T6: TOCTOU between policy check and payment
An allow is computed; the request is then swapped (payee, amount)
before the rail sees it; or a second payment uses the same allow.
The adapter pays only the exact fields hashed into the single-use
decision, and the settlement it records cannot be stamped after the
authority it was recorded under expired. Defined in [CEDULON-CORE]:
MUST-T6-1, MUST-T6-2, MUST-T6-4, MUST-T6-5, MUST-T6-6, MUST-T6-7.
Dogru Expires 21 March 2027 [Page 3]
Internet-Draft Cedulon Threats September 2026
8. T7: Signing-key leakage
Keys leak from disk, logs, or a prompt. Forged manifests or receipts
follow.
The companion implementation ships mock keys only. The requirements
still constrain any later real key. MUST-T7-2, MUST-T7-5 and MUST-
T7-6 are defined in [CEDULON-CORE], including the measured-protection
and symlink refusals; this document does not redefine them.
9. T8: Counterparty price gouging or defective delivery
The payee ships a different artifact, or the price exceeds the signed
offer.
The Trade Manifest binds price and an acceptance-criteria hash before
payment. After delivery, a Dispute Evidence Bundle packages
manifest, receipt, and delivery hash. Cedulon does not adjudicate
and MUST NOT take custody. MUST-T8-custody is defined in
[CEDULON-CORE].
10. T9: PII leakage into the transparency log
A SCITT statement or public receipt carries names, addresses, or full
amounts that should stay private.
Log-facing encodings offer redaction. Anchors store hashes when the
operator chooses privacy mode. Defined in [CEDULON-CORE]: MUST-T9-1,
MUST-T9-2, MUST-T9-5.
11. T10: Secret spend via rail bypass
An operator, leaked credential, or a second binary can still settle
on the rail and omit the Receipt Issuer. Validity checks on the
receipts that do exist stay green.
Completeness, not validity: reconcile the rail extract to Spend
Receipt payment refs. A settlement without a receipt is a finding
identified by the settlement ref. The audit fails closed. Defined
in [CEDULON-CORE]: MUST-T10-1 through MUST-T10-20 as the core table
lists.
12. T12: Settlement without a recorded receipt
The threats above are about a counterparty, a rail or an attacker.
This one is about the issuer's own implementation, and it produces
exactly the condition the rest of this document exists to make
detectable.
Dogru Expires 21 March 2027 [Page 4]
Internet-Draft Cedulon Threats September 2026
An issuer that settles a payment, appends the receipt in memory and
then persists its state has three steps where it could have two
outcomes. If the write fails, the rail holds a settlement and the
receipt exists nowhere durable. The next start reads a state that
does not contain it, and the audit reports settlement-without-receipt
against an honest issuer that did everything its own policy asked.
The evidence is missing because the issuer lost it, not because
anyone hid it, and nothing in the report can tell those apart.
MUST-T12-1, MUST-T12-2, MUST-T12-3 and MUST-T12-4 are defined in
[CEDULON-CORE]. The measured runs sit on the in-process RailLedger
and the session tests.
Ordering: Settle-then-record is the natural order to write and the
wrong one to ship. The record is what makes the settlement
accountable, so the record is what has to be secured first (MUST-
T12-1), and a settlement that cannot be recorded has to be undone
everywhere the issuer still controls, including the nonce and the
allowance it never used (MUST-T12-2). Once value has entered a
rail the issuer does not control, a local snapshot cannot retract
it. Persistence failing after that point leaves the outcome
indeterminate (MUST-T12-4).
Recovery: A durable-state conflict is not necessarily fatal, but it
MUST NOT be silent. The reason reported has to separate the cases
an operator would act on differently (MUST-T12-3): a write that
conflicted with another writer, a write that failed, and a state
another process is holding.
Observability: A violation of this threat is not visible in the
evidence a verifier receives. The audit sees a settlement with no
receipt and reports settlement-without-receipt, which is the same
finding an adversary would produce. That is why the requirements
fall on the issuer rather than on the verifier.
13. Security Considerations
This document is informational. It restates attack paths already
named in the core and checkpoint companions. It defines no new
protocol requirements and introduces no new wire formats.
14. IANA Considerations
This document has no IANA actions.
15. References
15.1. Normative References
Dogru Expires 21 March 2027 [Page 5]
Internet-Draft Cedulon Threats September 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
15.2. Informative References
[CEDULON-CHECKPOINT]
Dogru, E. C., "Cedulon Checkpoints: Epoch Witnesses and
Transparency", 2026, <https://github.com/dogrucanemek-
alt/cedulon/blob/master/spec/draft-dogru-cedulon-
checkpoint-00.md>.
[CEDULON-CORE]
Dogru, E. C., "Spend Receipts and Payment Rail
Reconciliation for AI Agents", 2026, <https://github.com/
dogrucanemek-alt/cedulon/blob/master/spec/draft-dogru-
cedulon-core-00.md>.
Author's Address
Emek Can Dogru
VERAX TEKNOLOJI LIMITED SIRKETI
Email: e.dogru@cedulon.com
Dogru Expires 21 March 2027 [Page 6]