Pith. sign in

REVIEW 3 minor 1 cited by

A canonical signed decision envelope can stop stale, redirected, or hostile agentic-commerce actions before they take effect.

Reviewed by Pith at T0; open to challenge. T0 means a machine referee read the full paper against a public rubric. the ladder, T0–T4 →

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

T0 review · deepseek-v4-flash

2026-08-01 17:18 UTC pith:7HKDJXFI

load-bearing objection A clear-headed, honestly bounded design-science paper: the architecture and invariants are a useful gap-filler, but the evidence is all self-authored and the invariants remain unproven beyond eight synthetic scenarios.

arxiv 2607.18347 v1 pith:7HKDJXFI submitted 2026-07-20 cs.SE cs.CRcs.MA

A Decision-Centered Reference Architecture for Trustworthy Agentic Commerce

Dimitrios S. Sfiris This is my paper
classification cs.SE cs.CRcs.MA
keywords agentic commercecanonical decision envelopeprotected dependency hashesstale-decision preventionexecution-time revalidationgenerated-claim capabilityverified-state identitydecision invariants
verification ladder T0 review T1 audit T2 compute T3 formal T4 reserved

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper argues that the missing piece in agentic commerce is a merchant-owned decision layer that tells agents whether an action is commercially valid at the moment it is requested. It proposes a canonical envelope that hashes the decision's inputs, results, and identity, signs it, and requires recipients to verify it against the live request and current authoritative state before use. The evaluated reference implementation stopped all seven initially valid actions after price, promotion, inventory, mandate, evidence, delivery, or return-policy state changed, and also blocked a hostile accessor that tried to alter state after verification. If this holds in real deployments, merchants can rely on one authoritative decision representation across protocols and surfaces rather than letting each adapter interpret commercial meaning.

Core claim

On the paper's own terms, the discovery is that a merchant can express 'is this action valid now' as a single signed object whose meaning cannot drift: a canonical envelope containing protected input-dependency, result, and decision hashes, with a detached frozen snapshot projected only after live-request rebinding and execution-time comparison with current authoritative dependencies. The evaluation supports this for the tested classes: after any of seven protected state changes, earlier decisions became unusable and required fresh decisions; a caller-controlled accessor was read once and could not flip a blocked result; and five ablations produced predicted unsafe regressions only when safe

What carries the argument

The canonical decision envelope: one content-addressed object for one requested action in one context. It carries three protected hashes—an input dependency hash over normalized request and dependency state, a result hash over computed result state, and a decision hash over metadata plus the first two—authenticated by Ed25519 or HMAC. A trusted projection boundary deep-freezes a single detached JSON snapshot and projects only from that verified state, and execution-time dependency revalidation compares protected dependency identities and hashes with current authoritative snapshots. Eleven semantic invariants (including payment non-escalation, projection non-recomputation, generated-claim cap

Load-bearing premise

The guarantee presupposes that every commercially material input can be represented as a protected, content-addressable dependency from an authoritative source system that exposes stable identifiers, timestamps, revisions, or hashes; if a source lacks stable revisions or the authoritative store itself is wrong, revalidation compares only what the adapter exposed and the envelope preserves the wrong fact.

What would settle it

Run the reference implementation against a source system whose price changes but whose exposed revision identifier or hash remains unchanged; if the earlier allowed checkout decision still proceeds, the central claim fails. Equivalently, an independent harness can mutate a protected dependency's underlying content without changing its content-addressable reference and observe whether execution-time comparison catches it.

Watch this falsifier. Get emailed when new claim-graph text bears on it.

If this is right

  • Any change in a protected dependency—price, stock, policy, mandate, evidence, delivery promise—invalidates earlier decisions, so agents must obtain a fresh decision before acting.
  • The same action status can be projected consistently across feed, tool, checkout, protocol, and support surfaces without recomputing commercial meaning.
  • Generated product or policy language becomes unusable when its source evidence disappears, its freshness expires, or a parent claim is refused; rewriting cannot launder a refusal.
  • A merchant can adopt the pattern as a domain function without replacing its commerce platform, but must revalidate the owning aggregate immediately before any mutation.
  • Integrity verification alone is insufficient: target-surface binding and live action/actor/subject rebinding are necessary to prevent replay and redirection.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The architecture effectively relocates the trust bottleneck to the dependency-adapter layer: if a source system cannot expose stable revision identifiers, or the authoritative store itself is wrong, execution-time revalidation compares only what adapters exposed and the envelope will faithfully preserve the incorrect fact.
  • The same signed-envelope pattern could be applied beyond commerce—any domain where a decision about current state must be projected to multiple consumers and where stale decisions create liability, such as eligibility, entitlement, or compliance checks.
  • A natural testable extension is to measure stale-decision rates with real catalogs whose revision metadata is noisy, to see whether the protected-dependency comparison degrades gracefully or silently accepts unchanged revision IDs.
  • Because the trusted decision builder is assumed uncompromised, the architecture does not by itself defend against prompt injection in the agent's reasoning context; complementary controls at the model and tool layers remain necessary.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

0 major / 3 minor

Summary. The paper proposes a protocol-agnostic, merchant-side decision architecture for agentic commerce: a canonical decision envelope with protected dependency/result/decision hashes, detached Ed25519 or HMAC authentication, live-request rebinding, a seven-axis generated-claim capability gate, execution-time dependency revalidation, and eleven semantic invariants. It reports an open-source JavaScript reference implementation (v0.9.2) and evaluates it with eight deterministic scenarios and five controlled ablations. The reported results are that seven initially valid actions are permitted, all seven are stopped after a relevant state change, the hostile-accessor case remains blocked, surface-bound envelopes agree on action status in 8/8 scenarios, and each ablation produces the predicted unsafe regression when one safeguard is bypassed while the protected path contains the failure. The manuscript consistently and explicitly limits these findings to synthetic fixtures, and disclaims production security, performance, legal compliance, live interoperability, rule completeness, population error rates, and independent replication.

Significance. If the result holds, the paper makes a useful design-science contribution: it gives a concrete, testable articulation of what a merchant-side decision layer must enforce when agents transact under delegated authority. The main strengths are the machine-checked reproducibility of the artifact (66/66 tests, schema validation, committed examples), the frozen archive with checksums and logs, the explicit adversary model, and the transparent disclosure that the author designed the artifact, rules, scenarios, and pass criteria. The stress-test concern about universal invariant sufficiency is real, but the paper already bounds its claims in §3.6 and §7.4; it is a scoping question rather than a demonstrated internal inconsistency. The work does not provide formal verification or external validation, and its value is correspondingly an executable conformance contract for a proposed architecture, not an empirical or formal guarantee.

minor comments (3)
  1. [§4.3, Table 4] The invariants are introduced as conditions that must hold 'for every externally usable decision,' and §8 says they make semantic conformance testable. The evidence shows that the frozen implementation satisfies them on the eight scenarios and five ablations; it does not prove that I1–I11 are sufficient to exclude every stale or hostile decision, and §7.5 correctly lists formal verification as future work. Please add one sentence in §4.3 or §8 stating that the invariant set is proposed as a conformance contract and has been demonstrated on the tested fixtures, not claimed to be complete or formally verified. The abstract's caveat is appropriately narrow; the body should be aligned with it.
  2. [§4.2, Eq. (1)] The integrity model relies on a custom deterministic normalizer rather than RFC 8785/JCS, with only a one-sentence justification. Because invariant I6 (hash completeness) and all change-detection claims depend on canonicalization being stable and collision-safe, please add a short note explaining why the custom normalizer was preferred over JCS and which tests establish its equivalence properties (key sorting, unordered-collection normalization, number and string handling). If such tests are among the 66, name them explicitly; otherwise add targeted test vectors.
  3. [§4.4, §7.4] The trust boundary is clearly defined for snapshots, but the paper's own concession that an authenticated envelope can 'faithfully preserve a wrong price, biased rule, or legally incorrect policy' (§7.4) deserves a more prominent visual or structural place in §4.4. A small figure or explicit bullet list marking 'authoritative source correctness' and 'merchant rule correctness' as outside the verified-state boundary would prevent readers from conflating a verified decision with a commercially correct one.

Circularity Check

1 steps flagged

Ablation 'predictions' are constructed rather than derived: the unsafe variants and pass criteria guarantee the reported regressions, making part of the evidence self-fulfilling.

specific steps
  1. fitted input called prediction [Abstract; §3.4 Controlled ablation results; §7.4 Limitations]
    "Each ablation produced the predicted unsafe regression when one safeguard was bypassed, while the protected path contained the same failure. ... An ablation passed when the protected path rejected or contained the demonstrated failure and the unsafe variant exhibited the predicted regression. ... the domain rules, ablation mechanisms, and expected outcomes were specified by the architecture’s author."

    The ablation 'prediction' is not an independent implication of the architecture; it is the expected behavior of a variant intentionally built by removing exactly the safeguard under test, with the pass criterion defined as the appearance of that expected failure. The outcome is therefore entailed by the experimental construction rather than providing independent evidence for the safeguard's necessity. Because the abstract's headline support for refusal propagation, detached verified-state identity, and dependency-revalidation necessity rests in part on these purpose-built ablations, the reported predictions reduce, by construction, to the author's own design choices.

full rationale

The eight-scenario corpus is a bona fide executable conformance check of the reference implementation against the paper's own stated invariants, and the manuscript is unusually explicit that results are limited to synthetic fixtures and do not establish rule completeness, production security, or independent replication. The self-citation to the earlier WebDigestPro article is used only for provenance and novelty disclaimers, not as load-bearing support, and no uniqueness theorem or ansatz is imported from the authors' prior work. The main circular element is the ablation reporting: the unsafe variants are purpose-built to fail, the pass criteria are the predicted failures themselves, and §7.4 concedes that the rules, ablations, and expected outcomes were all author-specified. Those five 'predictions' therefore reduce by construction and cannot, on their own, confirm the safeguards. This is partial rather than total circularity: the scenario corpus and the explicit interpretation boundary preserve some independent content, which is why the score is 6 rather than 8-10.

Axiom & Free-Parameter Ledger

3 free parameters · 6 axioms · 3 invented entities

No numerical parameters are fitted to data in the statistical sense; instead, the evaluation outcomes are determined by hand-authored rules, fixtures, and freshness horizons, which behave as free parameters (their values fully control which scenarios pass). The load-bearing axioms are the deployment-environment assumptions of §3.2-§3.3 (stable content-addressed sources; uncompromised trusted components) plus the untested generality of the detached-snapshot and generated-claim-axis models. The invented entities are design constructs whose only evidence is the author's own implementation; none has an independent falsifiable handle outside this paper.

free parameters (3)
  • Seven synthetic raw-fact domain rules (R1-R7) = encoded in evaluated package v0.9.2 (rule-set id agent-commerce-decision-rules-v4)
    Hand-authored by the architect (§3.4). Every scenario outcome — allowed, blocked, requires_revalidation — is an output of these rules, so the headline '7/7 derived non-allowed' result is conditional on the author's choice of rule semantics and thresholds.
  • Freshness/stale horizons for evidence and delivery-promise fixtures = per-fixture values; delivery rule produced requires_revalidation
    Chosen by the author rather than derived; the horizon values determine whether a scenario lands on blocked versus requires_revalidation (Table 6) and drive the freshness tests in the 66-test suite (§5.1, §6.2).
  • Scenario fixture values (prices, inventory counts, mandate limits) = synthetic values in committed scenario modules
    Commercial-representative but synthetic (§3.4). Boundaries such as 'checkout total exceeds delegated spending cap' depend on the chosen numbers; different fixtures would produce a different locus of the demonstrated failures.
axioms (6)
  • domain assumption Source systems can expose stable identifiers, timestamps, revisions, or hashes; merchant can define action rules
    Stated in §3.2 as an explicit artifact assumption. Without stable content-addressed dependencies, execution-time revalidation cannot be populated from real catalog, policy, or mandate stores, so the architecture's central guarantee silently degrades to whatever each adapter exposes.
  • domain assumption Trusted decision builder, trusted key material, and authoritative domain stores are uncompromised
    Threat-model boundary in §3.3. Compromise of any of these components invalidates every envelope guarantee; the paper offers no mechanism to detect such compromise.
  • standard math SHA-256, JSON canonicalization (RFC 8785-style), Ed25519, and HMAC-SHA-256 behave as specified
    Invoked in Eq. (1) and §4.2; standard cryptographic assumptions the paper relies on without proof. Note the artifact uses its own deterministic normalizer rather than RFC 8785 itself (§4.2).
  • domain assumption A detached, deeply frozen JSON snapshot preserves all decision-relevant semantics of the envelope across the projection boundary
    Invariant I11 (§4.4, §6.5). Tested for exactly one accessor pattern (a single-read hostile accessor); the paper itself notes mutable aliases, proxies, callbacks, and non-JSON transport may reproduce the identity problem, so the general claim is asserted, not established.
  • ad hoc to paper The seven generated-claim axes (source, freshness, scope, surface, use, payload, taint) span the ways a claim can become unsupported
    §4.5 defines the axes as the architecture's model of generated-language governance. No evidence that this axis set covers production claim-failure modes; the paper lists claim-governance completeness as outside the evaluation boundary (§3.6, §6.6).
  • ad hoc to paper The artifact's custom deterministic normalizer is collision-safe for semantically identical objects
    §4.2 states the artifact 'defines its own deterministic normalizer' rather than using RFC 8785. If two semantically different states canonicalize identically, the hash-protected identity claims (I6, I11) break; this is not tested.
invented entities (3)
  • Canonical decision envelope (agent-commerce-decision-envelope-v4) no independent evidence
    purpose: Single protected representation of eligibility, authority, checkout, payment, generated-claim state, and evidence for one requested action across all surfaces
    The paper's central construct. Its validity is shown only through the author's own implementation and fixtures; there is no external benchmark, independent implementation, or third-party evaluation that confirms the envelope semantics (§7.4).
  • Seven-axis generated-claim capability (source, freshness, scope, surface, use, payload, taint) no independent evidence
    purpose: Govern generated commerce language as a bounded, revocable capability rather than source truth, preventing refusal laundering
    Introduced in §4.5; exercised by two scenarios and one ablation. The axis space itself is unevaluated externally; the paper excludes claim-governance completeness from what it establishes (§3.6, §6.6).
  • Verified-state identity (invariant I11) no independent evidence
    purpose: Guarantee that projection uses exactly the detached state that passed integrity, authenticator, freshness, and live-binding verification
    Added after an earlier verified-state defect was found (§3.1). Demonstrated against a single hostile-accessor fixture (§6.5); the paper explicitly leaves mutable aliases, proxies, and non-JSON boundaries unevaluated.

pith-pipeline@v1.3.0-alltime-deepseek · 16146 in / 28170 out tokens · 272095 ms · 2026-08-01T17:18:32.650741+00:00 · methodology

0 comments
read the original abstract

Agentic commerce extends agentic shopping into software agents that interpret policy, prepare checkout, generate transaction-facing language, and act under delegated payment authority. Protocols standardize external exchanges, but merchants still need one authoritative representation of commercial eligibility, actor authority, checkout validity, payment dispatch, generated claims, and evidence. This design-science study presents a protocol-agnostic architecture built around a canonical envelope, protected dependency and result hashes, Ed25519 or HMAC authentication, live-request rebinding, a seven-axis generated-claim gate, execution-time dependency revalidation, and eleven semantic invariants. Evaluation used an open-source JavaScript implementation, eight deterministic ecommerce scenarios, and five controlled ablations. Seven initially valid actions were permitted. After protected state changed, none could proceed without a fresh decision; a hostile-accessor case also remained blocked. Action status was consistent across configured surface-bound envelopes, and each scenario contained the three protected hashes and its targeted dependency reference. Each ablation produced the predicted unsafe regression when one safeguard was bypassed, while the protected path contained the same failure. The hostile accessor was read once, and the suite passed 66/66 tests, schema validation, and committed examples. Results support protected-dependency change detection, bounded outcome derivation, stale-decision prevention, surface-bound status consistency, refusal propagation, and verified-state identity under synthetic fixtures, but do not establish rule completeness, production security, performance, legal compliance, live interoperability, population error rates, or independent replication.

Figures

Figures reproduced from arXiv: 2607.18347 by Dimitrios S. Sfiris.

Figure 1
Figure 1. Figure 1: Protocols standardize external exchange; the merchant decision layer owns action-specific commercial meaning. reports machine-readable outcomes and a reproducible repository-bounded test protocol while stating the boundaries that remain untested. Eighth, it uses controlled ablation experiments to demonstrate the predicted failure when dependency revalidation, detached capture, surface or live-request bindi… view at source ↗
Figure 2
Figure 2. Figure 2: Design-science process used to formalize and evaluate the reference artifact. secure practices and verification throughout development [21]. OWASP’ s agentic guidance emphasizes excessive agency, tool misuse, identity, memory, and cascading failures [22]. The architecture presented here operationalizes a narrow subset of these concerns at the commerce decision boundary. 3 Research method 3.1 Design-science… view at source ↗
Figure 3
Figure 3. Figure 3: Decision construction, trusted-boundary verification and live-request rebinding, surface projection, and final aggregate revalidation. beside eligibility.result=blocked, or paymentDispatchAttempted=true beside an invalid check￾out. Conformance therefore requires both structural validation and domain coherence. 4.4 Trusted projection boundary The highest-risk point is not envelope construction but recipient… view at source ↗

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score.

  1. Agentic Commerce World: An Auditable and Verifiable Environment for Vibe Commerce

    cs.AI 2026-08 conditional novelty 6.0

    ACWorld provides an auditable two-sided commerce benchmark in which process-level traces, not final states, are required to detect LLM agent errors (65.9–85.6% on the capability track; 56.1–91.4% on the large-catalog track).

Reference graph

Works this paper leans on

39 extracted references · 3 canonical work pages · cited by 1 Pith paper · 1 internal anchor

  1. [1]

    AgenticShop: benchmarking agentic product curation for personalized web shopping

    Kim S, Heo R, Seo Y, Yeo J, Lee D. AgenticShop: benchmarking agentic product curation for personalized web shopping. In: Proceedings of the ACM Web Conference 2026. New York: ACM

    2026

  2. [2]

    What is your AI agent buying? Evaluation, biases, model dependence, and emerging implications of agentic e-commerce

    Allouah A, Besbes O, Figueroa JD, Kanoria Y, Kumar A. What is your AI agent buying? Evaluation, biases, model dependence, and emerging implications of agentic e-commerce. In: Proceedings of the ACM Web Conference 2026. New York: ACM; 2026. p. 8697-8700. doi:10.1145/3774904.3792943

    arXiv 2026

  3. [3]

    Iterating Toward Better Search: A Two-Agent Simulation Framework for Evaluating Agentic Search Architectures in E-Commerce

    Duraj J, Yetukuri J, Zhou S, Varma D, Kong R, Khan I, et al. Iterating toward better search: a two-agent simulation framework for evaluating agentic search architectures in e-commerce. arXiv:2606.12924. doi:10.48550/arXiv.2606.12924

    work page internal anchor Pith review Pith/arXiv arXiv doi:10.48550/arxiv.2606.12924

  4. [4]

    Introduction and technical documentation [Internet]

    Agentic Commerce Protocol. Introduction and technical documentation [Internet]. 2026 [cited 2026 Jul 14]. Available from: https://www.agenticcommerce.dev/docs

    2026

  5. [5]

    Stripe powers Instant Checkout in ChatGPT and releases Agentic Commerce Protocol co-developed with OpenAI [Internet]

    Stripe. Stripe powers Instant Checkout in ChatGPT and releases Agentic Commerce Protocol co-developed with OpenAI [Internet]. 2025 Sep 29 [cited 2026 Jul 14]. Available from: https: //stripe.com/newsroom/news/stripe-openai-instant-checkout 21

    2025

  6. [6]

    Powering AI commerce with the new Agent Payments Protocol (AP2) [Internet]

    Parikh S, Surapaneni R. Powering AI commerce with the new Agent Payments Protocol (AP2) [Internet]. Google Cloud Blog. 2025 Sep 16 [cited 2026 Jul 14]. Available from: https://cloud.google .com/blog/products/ai-machine-learning/announcing-agents-to-payments-ap2-protocol

    2025

  7. [7]

    Technical specification and documentation [Internet]

    Universal Commerce Protocol. Technical specification and documentation [Internet]. 2026 [cited 2026 Jul 14]. Available from: https://ucp.dev/

    2026

  8. [8]

    Building the Universal Commerce Protocol [Internet]

    Grigorik I. Building the Universal Commerce Protocol [Internet]. Shopify Engineering. 2026 Jan 11 [cited 2026 Jul 14]. Available from: https://shopify.engineering/UCP

    2026

  9. [9]

    Tools specification, version 2025-11-25 [Internet]

    Model Context Protocol. Tools specification, version 2025-11-25 [Internet]. 2025 Nov 25 [cited 2026 Jul 14]. Available from: https://modelcontextprotocol.io/specification/2025-11-25/server/tools

    2025

  10. [10]

    The Agentic Commerce Blueprint: orchestrating the e-commerce stack for AI agents [Internet]

    Sfyris DS. The Agentic Commerce Blueprint: orchestrating the e-commerce stack for AI agents [Internet]. WebDigestPro; 2026 Jul 13; updated 2026 Jul 15 [cited 2026 Jul 15]. Available from: https://www.webdigestpro.com/the-agentic-commerce-blueprint/

    2026

  11. [11]

    Enabling AI agents to buy securely and seamlessly: Visa Intelligent Commerce [Internet]

    Visa. Enabling AI agents to buy securely and seamlessly: Visa Intelligent Commerce [Internet]. 2026 [cited 2026 Jul 14]. Available from: https://www.visa.com/en-us/solutions/intelligent-commerce

    2026

  12. [12]

    Mastercard unveils Agent Pay, pioneering agentic payments technology to power commerce in the age of AI [Internet]

    Mastercard. Mastercard unveils Agent Pay, pioneering agentic payments technology to power commerce in the age of AI [Internet]. 2025 Apr 29 [cited 2026 Jul 14]. Available from: https: //www.mastercard.com/global/en/news-and-trends/press/2025/april/mastercard-unveils-agent-p ay-pioneering-agentic-payments-technology-to-power-commerce-in-the-age-of-ai.html

    2025

  13. [13]

    PayPal launches Agentic Commerce Services to power AI-driven shopping [Internet]

    PayPal. PayPal launches Agentic Commerce Services to power AI-driven shopping [Internet]. 2025 Oct 28 [cited 2026 Jul 14]. Available from: https://newsroom.paypal-corp.com/2025-10-28-PayPa l-Launches-Agentic-Commerce-Services-to-Power-AI-Driven-Shopping

    2025

  14. [14]

    Whispers of wealth: red-teaming Google’s Agent Payments Protocol via prompt injection

    Debi T, Zhu W, Sen Gupta P. Whispers of wealth: red-teaming Google’s Agent Payments Protocol via prompt injection. arXiv:2601.22569. doi:10.48550/arXiv.2601.22569

    Pith/arXiv arXiv doi:10.48550/arxiv.2601.22569

  15. [15]

    Zero-trust runtime verification for agentic pay- ment protocols: mitigating replay and context-binding failures in AP2

    Lan Q, Kaul A, Jones S, Westrum S. Zero-trust runtime verification for agentic pay- ment protocols: mitigating replay and context-binding failures in AP2. arXiv:2602.06345. doi:10.48550/arXiv.2602.06345

    doi:10.48550/arxiv.2602.06345

  16. [16]

    SoK: security of autonomous LLM agents in agentic commerce

    Mao Q, Wang J, Liu Y, Zhu L, Ma C, Yan J. SoK: security of autonomous LLM agents in agentic commerce. arXiv:2604.15367. doi:10.48550/arXiv.2604.15367

    Pith/arXiv arXiv doi:10.48550/arxiv.2604.15367

  17. [17]

    AgentRFC: security design principles and conformance testing for agent protocols

    Zheng S, Zhang Q. AgentRFC: security design principles and conformance testing for agent protocols. arXiv:2603.23801. doi:10.48550/arXiv.2603.23801

    doi:10.48550/arxiv.2603.23801

  18. [18]

    Securing the Model Context Protocol (MCP): risks, controls, and governance

    Errico H, Ngiam J, Sojan S. Securing the Model Context Protocol (MCP): risks, controls, and governance. arXiv:2511.20920. doi:10.48550/arXiv.2511.20920

    doi:10.48550/arxiv.2511.20920

  19. [19]

    Artificial Intelligence Risk Management Framework (AI RMF 1.0)

    National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). Gaithersburg (MD): NIST; 2023. doi:10.6028/NIST.AI.100-1

    doi:10.6028/nist.ai.100-1 2023

  20. [20]

    Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile

    Autio C, Schwartz R, Dunietz J, Jain S, Stanley M, Venkatesh A, et al. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. Gaithersburg (MD): NIST; 2024. doi:10.6028/NIST.AI.600-1

    doi:10.6028/nist.ai.600-1 2024

  21. [21]

    Secure Software Development Framework (SSDF) Version 1.1

    Souppaya M, Scarfone K, Dodson D. Secure Software Development Framework (SSDF) Version 1.1. Gaithersburg (MD): NIST; 2022. doi:10.6028/NIST.SP.800-218

    doi:10.6028/nist.sp.800-218 2022

  22. [22]

    OWASP Top 10 for Agentic Applications 2026 [Internet]

    OWASP GenAI Security Project. OWASP Top 10 for Agentic Applications 2026 [Internet]. 2025 Dec 9 [cited 2026 Jul 14]. Available from: https://genai.owasp.org/resource/owasp-top-10-for-agent ic-applications-for-2026/

    2026

  23. [23]

    Design science in information systems research

    Hevner AR, March ST, Park J, Ram S. Design science in information systems research. MIS Q. 2004;28(1):75-105. doi:10.2307/25148625. 22

    doi:10.2307/25148625 2004

  24. [24]

    A design science research methodology for information systems research

    Peffers K, Tuunanen T, Rothenberger MA, Chatterjee S. A design science research methodology for information systems research. J Manag Inf Syst. 2007;24(3):45-77. doi:10.2753/MIS0742-1222240302

    doi:10.2753/mis0742-1222240302 2007

  25. [25]

    JSON Canonicalization Scheme (JCS)

    Rundgren A, Jordan B, Erdtman S. JSON Canonicalization Scheme (JCS). RFC 8785. Internet Engineering Task Force; 2020. doi:10.17487/RFC8785

    doi:10.17487/rfc8785 2020

  26. [26]

    Secure Hash Standard (SHS)

    National Institute of Standards and Technology. Secure Hash Standard (SHS). FIPS PUB 180-4. Gaithersburg (MD): NIST; 2015. doi:10.6028/NIST.FIPS.180-4

    doi:10.6028/nist.fips.180-4 2015

  27. [27]

    Edwards-Curve Digital Signature Algorithm (EdDSA)

    Josefsson S, Liusvaara I. Edwards-Curve Digital Signature Algorithm (EdDSA). RFC 8032. Internet Engineering Task Force; 2017. doi:10.17487/RFC8032

    doi:10.17487/rfc8032 2017

  28. [28]

    HMAC: keyed-hashing for message authentication

    Krawczyk H, Bellare M, Canetti R. HMAC: keyed-hashing for message authentication. RFC 2104. Internet Engineering Task Force; 1997. doi:10.17487/RFC2104

    doi:10.17487/rfc2104 1997

  29. [29]

    Best Current Practice for OAuth 2.0 Security

    Lodderstedt T, Bradley J, Labunets A, Fett D. Best Current Practice for OAuth 2.0 Security. RFC

  30. [30]

    Agentic Commerce Blueprint reference implementation, version 0.9.2 [software]

    Sfyris DS. Agentic Commerce Blueprint reference implementation, version 0.9.2 [software]. MIT License. GitHub; 2026 Jul 16 [cited 2026 Jul 16]. Evaluated commit:f81d464c18d237cba16b c5e77534a64dc2eae1b2 . Frozen evaluated archive included as ancillary file S4. Available from: https://github.com/dmsfiris/agentic-commerce-blueprint/releases/tag/v0.9.2

    2026

  31. [31]

    Date and time on the Internet: timestamps

    Klyne G, Newman C. Date and time on the Internet: timestamps. RFC 3339. Internet Engineering Task Force; 2002. doi:10.17487/RFC3339

    work page doi:10.17487/rfc3339 2002

  32. [32]

    Draft 2020-12 specification [Internet]

    JSON Schema. Draft 2020-12 specification [Internet]. 2020 [cited 2026 Jul 14]. Available from: https://json-schema.org/draft/2020-12

    2020

  33. [33]

    Guide to Attribute Based Access Control (ABAC) Definition and Considerations

    Hu VC, Ferraiolo D, Kuhn R, Schnitzer A, Sandlin K, Miller R, et al. Guide to Attribute Based Access Control (ABAC) Definition and Considerations. NIST Special Publication 800-162. Gaithersburg (MD): National Institute of Standards and Technology; 2014, updated 2019. doi:10.6028/NIST.SP.800- 162

    doi:10.6028/nist.sp.800- 2014

  34. [34]

    eXtensible Access Control Markup Language (XACML) Version 3.0 [Internet]

    OASIS. eXtensible Access Control Markup Language (XACML) Version 3.0 [Internet]. OASIS Standard. 2013 Jan 23; approved errata 2017 Jul 12 [cited 2026 Jul 15]. Available from: https: //docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html

    2013

  35. [35]

    Macaroons: cookies with contextual caveats for decentralized authorization in the cloud

    Birgisson A, Politz JG, Erlingsson U, Taly A, Vrable M, Lentczner M. Macaroons: cookies with contextual caveats for decentralized authorization in the cloud. In: Proceedings of the 21st Annual Network and Distributed System Security Symposium (NDSS 2014). San Diego (CA): Internet Society; 2014. doi:10.14722/ndss.2014.23212

    arXiv 2014

  36. [36]

    PROV-O: The PROV Ontology

    Lebo T, Sahoo S, McGuinness D, editors. PROV-O: The PROV Ontology. W3C Recommendation [Internet]. 2013 Apr 30 [cited 2026 Jul 14]. Available from: https://www.w3.org/TR/prov-o/

    2013

  37. [37]

    in-toto: providing farm-to-table guarantees for bits and bytes

    Torres-Arias S, Afzali H, Kuppusamy TK, Curtmola R, Cappos J. in-toto: providing farm-to-table guarantees for bits and bytes. In: 28th USENIX Security Symposium. Santa Clara (CA): USENIX Association; 2019. p. 1393-1410. 23

    2019

  38. [2026]

    2489-2500

    p. 2489-2500. doi:10.1145/3774904.3792724

    arXiv

  39. [9700]

    doi:10.17487/RFC9700

    Internet Engineering Task Force; 2025. doi:10.17487/RFC9700

    work page doi:10.17487/rfc9700 2025