Agent-access receipts for artificial intelligence-mediated content and application programming interface access: a reproducible synthetic security experiment

1 Introduction

AI agents increasingly cross operational boundaries that older bot-management vocabularies did not have to separate. A crawler may request content for search indexing, model training, retrieval-augmented answering, or user-directed fetching. A software agent may also call application programming interfaces (APIs) that return summaries, account attributes, subscriber profiles, or bulk exports. The same automated caller can therefore raise questions about bot identity, user delegation, declared purpose, resource authorization, response sensitivity, payment, policy freshness, and later review.

Existing web controls still matter. The Robots Exclusion Protocol gives site operators a conventional way to express crawler preferences (Koster et al., 2022). OAuth, JavaScript Object Notation (JSON) Web Tokens, Rich Authorization Requests, token exchange, and proof-of-possession mechanisms provide API systems with primitives for delegated authorization, token binding, and defense-in-depth token handling. Relevant specifications include the studies by Hardt (2012), Jones et al. (2015), Jones et al. (2020), Lodderstedt et al. (2023), Fett et al. (2023), and Lodderstedt et al. (2025).

Hypertext Transfer Protocol (HTTP) Message Signatures and emerging bot-authentication work move web automation away from plain user-agent assertion toward request-level cryptographic accountability (Backman et al., 2024; Cloudflare, 2025, 2026). At the same time, publisher-facing licensing protocols such as Really Simple Licensing (RSL) are trying to express machine-readable access and compensation terms for artificial intelligence (AI) systems (RSL Collective, 2025a; RSL Collective, 2025b).

The security gap is therefore not the absence of relevant primitives, but the difficulty of reconstructing how several primitives interacted at the instant of the access decision. A valid bot signature may not prove that the represented principal had the necessary delegated authority. A valid access token may not prove that the requested API surface was registered. A valid payment token may not prove that it covered the resource and sensitivity actually returned. A once-valid issuer endpoint may later be offline. A policy snapshot may be stale. The decision record must therefore preserve the evidence needed to reconstruct the decision, not only a binary label such as “verified bot” or “blocked crawler.”

This article studies that problem through a synthetic artifact called an agent-access receipt. The receipt is a structured record generated at a content/API boundary. It records the actor, principal, identity method, issuer, delegation, intent, resource/API surface, policy snapshot digest, economic rule, decision, reason codes, validation material, evidence hashes, and edge receipt signature. The receipt is not proposed as a final standard. It is a laboratory object for asking a security question—which fields become decision-relevant when agent-mediated access is later disputed? The study deliberately uses one receipt grammar across both content and API surfaces because both can be represented as policy-governed access decisions with identity, delegation, resource, declared purpose, and evidence-preservation fields.

The study makes the following three contributions:

• It carries into the AI-mediated content/API setting a framing that auditable access-control research has already established in other domains (Akhtar et al., 2024; Zhang et al., 2024)—access is treated as an auditable security decision, not only as a bot-classification event.
• It provides a reproducible synthetic corpus that tests 15 scenarios, 15 mutation/control cases, and three receipt-integrity controls.
• It identifies the receipt fields that change the verifier outcome under the synthetic policy—identity, issuer trust, delegation, intent, resource/API registration, response sensitivity, payment binding, policy freshness, archived validation, and receipt-signature integrity.

Authenticated delegation, persistent access logs, and auditable policy evaluation each already exist in peer-reviewed form, and Section 2.5 credits them. Deployed bot-authentication standards authenticate the calling agent while the request is in flight, through signed requests, verified-bot programs, and sender-constrained tokens (Backman et al., 2024; Cloudflare, 2025; Fett et al., 2023). Recent peer-reviewed work reaches further: authenticated-delegation frameworks establish and scope an agent’s authority with chains of accountability (South et al., 2025), encrypted access logs preserve attributed records of past account activity (Ortega Pérez et al., 2025), and blockchain-based schemes make policy evaluation auditable across organizational domains (Akhtar et al., 2024). To the author’s knowledge, what this study adds is the laboratory—a deterministic, rerunnable corpus in which a field-complete, individually signed record of single access decisions at the AI content/API boundary is subjected to field-by-field mutation, so that which evidence fields such a record must carry under the stated synthetic policy is demonstrated executably rather than asserted. The unit of analysis is the decision record rather than the caller. The arbiter inside the laboratory is a deterministic verifier, standing in for the human review a production dispute would trigger; the result is a field-level map of what an edge must preserve so that a completed decision to allow, deny, delay, or paywall an AI-mediated request can be re-verified afterward.

2 Related work

2.1 Web automation, bot authentication, and content access

Traditional web-crawler control depends heavily on declared user agents, Internet Protocol (IP)-based verification, allowlists, and robots.txt policy. The Robots Exclusion Protocol is deliberately advisory and does not authenticate the crawler (Koster et al., 2022). Recent AI-mediated access disputes place pressure on this model. Operators need to distinguish search indexing, training, user-directed fetch, summarization, scraping, and malicious automation, while callers need a way to prove which automated service made a request. Web Bot Auth and related work therefore use HTTP message signatures to authenticate bot or agent requests (Backman et al., 2024; Cloudflare, 2025, 2026). The present work does not implement Web Bot Auth; instead, it treats signed agent identity as one field in a broader access decision.

Licensing protocols add another field family. RSL defines machine-readable licensing terms and a crawler authorization protocol in which a crawler can present a license token in an HTTP Authorization header (RSL Collective, 2025a; RSL Collective, 2025b). Akamai’s public reporting on AI bot activity in publishing similarly frames the access problem as broader than simple allow/block filtering (Akamai, 2026). This motivates including payment or licensing state inside the receipt rather than treating it as an external business note.

2.2 API authorization and sensitive response control

API security work emphasizes broken object-level authorization, broken authentication, unrestricted access to sensitive business flows, unsafe API consumption, and inventory failures identified by the Open Worldwide Application Security Project (OWASP, 2023). These risks are especially relevant when a human-facing agent interface hides downstream API complexity behind a single interaction. A system may appear to authorize an agent, while the actual security-relevant decision turns on which downstream API endpoint is reached and which sensitivity class is returned.

OAuth 2.0 and adjacent specifications provide mature primitives for grants, bearer tokens, proof-of-possession, rich authorization details, and token exchange. Relevant specifications include studies by Hardt (2012), Jones et al. (2015), Jones et al. (2020), Lodderstedt et al. (2023), Fett et al. (2023), and Lodderstedt et al. (2025). In the constrained-device profile of this family, peer-reviewed work places usage control under an ACE Authorization Server with notifications of revoked access rights (Rasori et al., 2024); Section 2.5 sets that enforcement-side design against the receipt model.

The receipt model in this study does not replace those primitives. It asks whether a compact decision record can preserve the evidence needed to reconstruct why an API call was allowed, denied, delayed, paywalled, or accepted under archived-validation conditions.

This framing also aligns with attribute-based access control (ABAC) and zero-trust security architecture. Those approaches treat identity, subject attributes, resource attributes, requested action, policy context, and environmental state as part of the decision. The decision is continuously evaluated rather than reduced to a one-time login event (Hu et al., 2014; Rose et al., 2020). The receipt studied here is narrower than either architecture—it records the evidence actually used for a specific agent-mediated content/API decision.

2.3 Evidence binding and validation survivability

Computer-security systems increasingly preserve structured evidence about artifacts, events, and provenance. Log-management guidance treats security records as infrastructure for later analysis and investigation, not merely as debugging exhaust (Kent and Souppaya, 2006). The World Wide Web Consortium (W3C) Provenance Data Model (PROV-DM) defines provenance as information about entities, activities, and responsible agents that can support assessments of reliability and trustworthiness (W3C Provenance Working Group, 2013). The in-toto framework models software supply chain steps and links them with signed metadata (Torres-Arias et al., 2019). Sigstore and Supply-chain Levels for Software Artifacts (SLSA) provide complementary evidence and verification patterns for software artifacts (Newman et al., 2022; SLSA, 2026). The Coalition for Content Provenance and Authenticity (C2PA) binds provenance metadata to digital content (C2PA, 2025). W3C Decentralized Identifiers (DIDs) and Verifiable Credentials define interoperable models for identifiers, issuers, credentials, and presentations (W3C DID Working Group, 2022; W3C Verifiable Credentials Working Group, 2025). Remote attestation architecture separates evidence, endorsements, appraisal policy, and attestation results (Birkholz et al., 2023). Policy-facing work reaches a similar conclusion from the demand side: a Royal Society and BBC workshop note on generative AI and digital content provenance identifies provenance recording as infrastructure that the online information environment will increasingly depend on as AI-mediated content grows (Royal Society, 2023).

This literature supplies a useful design lesson: an evidence object is valuable only if the relying party can later inspect the relevant bindings. In agent-access decisions, that means preserving not only identity evidence but also policy digests, payment/resource binding, API surface, response sensitivity, and archived validation material. This study isolates validation survivability as a variable: an issuer endpoint can be offline while archived validation material remains available, or offline with no preserved material. Those are different security states.

The receipt model can be located precisely against these adjacent evidence mechanisms. Conventional security logs are operator-scoped diagnostic streams: log-management guidance treats them as material for later analysis, but a log entry is typically neither field-complete for a named decision nor individually signed against the policy snapshot that governed it (Kent and Souppaya, 2006). Tamper-evident logging hardens that stream: Custos anchors cryptographic commitments over log events in trusted execution and audits them after the fact (Paccagnella et al., 2020), yet the hardened object is still the infrastructure log stream rather than a field-complete record of a named policy decision. The strongest peer-reviewed counterpoint on the log side, the encrypted per-access attributions of Ortega Pérez et al. (2025), is taken up in Section 2.5. PROV-DM and C2PA record the lineage of content and other entities rather than decisions about access to them (W3C Provenance Working Group, 2013; C2PA, 2025). The in-toto, Sigstore, and SLSA family is the closest structural analog because it binds signed attestations to defined steps, but the attested object is a software supply-chain step or artifact rather than a policy decision about a single request (Torres-Arias et al., 2019; Newman et al., 2022; SLSA, 2026). Remote attestation separates evidence from appraisal, a separation the receipt inherits, but its subject is platform trustworthiness rather than an individual access decision (Birkholz et al., 2023). The agent-access receipt therefore borrows the signing and evidence-binding patterns of these systems. It applies them to a different object: the single access-control decision, recorded with the fields a later reviewer needs to re-verify it.

2.4 Relation to deployed bot-authentication standards

The evidence-binding lesson in Section 2.3 also frames how the receipt model relates to mechanisms already deployed on the web. Because several deployed mechanisms already sign or constrain agent requests, it is worth stating precisely how the receipt model relates to them. Three mechanisms are the closest comparison points. HTTP Message Signatures (Backman et al., 2024) lets a sender sign selected HTTP message components so that a receiver can verify who constructed the message and that covered components were not altered in transit. Cloudflare’s Web Bot Auth profile applies HTTP Message Signatures to automated traffic, adding a Signature-Agent header and a public-key discovery mechanism so that an edge can verify a crawler or agent against a published key directory (Cloudflare, 2025, 2026). OAuth 2.0 Demonstrating Proof of Possession (DPoP) sender-constrains OAuth access tokens by requiring the client to prove possession of a private key at request time, which prevents a stolen bearer token from being used by another party (Fett et al., 2023).

All three mechanisms answer a question about the request while it is in flight: Is this caller who it claims to be, and is this token bound to this caller? The agent-access receipt answers a different question after the request has been decided: What evidence supported the decision, and can that decision be reconstructed and re-verified later? A signed request proves authenticity at the time of receipt. It does not record the policy snapshot in force, the delegation scope evaluated, the payment state consulted, the sensitivity boundary applied, or the validation material that a later reviewer would need. Conversely, the receipt does not contribute to caller authentication; it presumes some authentication mechanism supplied the identity evidence it records.

The two layers are therefore complementary and integrable. The receipt model does not replace bot-authentication protocols; it consumes their outputs as identity evidence and adds a durable decision record on top. Concretely, a receipt can countersign an exchange authenticated with HTTP Message Signatures: the edge records the covered components and signature parameters of the verified request among the receipt evidence hashes. Hence, the receipt binds the authenticated exchange to the decision made about it. A DPoP proof or a Web Bot Auth verification result can similarly appear in the receipt as the identity-evidence family, with issuer trust and validity evaluated by the verifier exactly as the synthetic identity tokens are evaluated in this laboratory. In the terms of this experiment, deployed standards strengthen one evidence family (identity), while the receipt preserves that family together with the other families the decision depends on.

This division of labor states one part of the gap this article addresses: the three request-time mechanisms above authenticate, and none of the three binds evidence of the access decision itself for post-hoc audit. Recent peer-reviewed research approaches the same territory from other directions, and Section 2.5 completes the discussion by comparing these approaches before restating the residual gap.

2.5 Peer-reviewed work on auditable access control, delegation, and access records

The deployed standards in Section 2.4 are one comparison surface. Recent peer-reviewed research supplies another across the properties this article claims for the receipt model: post hoc auditability, evidence binding, delegated authorization, policy changes, and persistent access-decision records. The studies below mark the nearest positions; the comparison is organized by property rather than by article.

Before the systems, an accountability strand names the requirement the receipt operationalizes. Cobbe et al. (2021) argue that meaningful accountability for automated decision-making requires contextually appropriate record-keeping that facilitates review of individual decisions and of the process as a whole; Chan et al. (2024) assess agent identifiers, real-time monitoring, and activity logs as visibility measures for AI agents, and argue that such information is critical for accountability as activities are delegated to agents. Neither study specifies what a per-decision record must contain for re-verification to succeed. The receipt model is one concrete answer to that question, and the corpus in Section 3 measures it.

On post-hoc auditability, auditable access control is an established goal in other settings. Akhtar et al. (2024) provide blockchain-based auditable access control for business processes whose resources fall under the policies of different organizational domains, contributing an automata-theoretic method that composes local policies into one cost-efficient composite policy evaluated over the blockchain. Zhang et al. (2024) attach a different meaning to auditability in a ciphertext-policy attribute-based encryption scheme: blockchain storage together with the InterPlanetary File System (IPFS) protects ciphertext, policy, and public keys against tampering, a white-box tracing algorithm traces leaked decryption keys, and an auditable smart contract records user behavior so that a user cannot deny a past action. Auditability in these systems concerns the integrity of enforcement artifacts and, in the second case, non-repudiation of the fact that a user acted: policy evaluation over the blockchain in the first, and stored policy material, key custody, and behavior tracing in the second. The claim in this article is narrower: the reconstructability of one named decision from a field-complete record, tested by mutating the record’s evidence fields and observing whether the verifier outcome changes.

On delegated authorization, South et al. (2025) make the position-track argument that agents acting on a person’s behalf need delegation that is itself authenticated. Their route stays inside deployed identity rails: OAuth 2.0 and OpenID Connect are extended so that an agent presents credentials and descriptive metadata of its own, the delegating person can bound what the agent may do and at what scope, accountability can be traced along the chain from action back to principal, and permissions expressed in natural language are turned into configurations an access-control system can enforce. That proposal supplies the mechanism side of the Section 1 concern that a valid bot signature may not prove delegated authority: it establishes and scopes the authority before the agent acts. Rasori et al. (2024) occupy the same axis in the OAuth sense: their Authorization Server is a trusted third party that evaluates requests against policies pre-established by the resource owner and issues an Access Token as evidence of the granted authorization, which the Resource Server verifies. The receipt model proposes no delegation mechanism. It consumes the delegation evidence such a framework would present, records it in the delegated_user_or_mandate field, and asks whether that evidence survives so that a later review can establish which authority governed a completed decision.

On policy changes, the peer-reviewed line enforces change while access is live. Rasori et al. (2024) place a usage-control framework under the Authorization Server of the Authentication and Authorization for Constrained Environments (ACE) framework, an OAuth 2.0-based framework for Internet-of-Things settings using the Constrained Application Protocol (CoAP), Concise Binary Object Representation (CBOR), and CBOR Object Signing and Encryption (COSE), and use the CoAP Observe extension to notify Clients and Resource Servers about revoked access tokens, evaluated on a real testbed. Zhang et al. (2024) similarly revoke a malicious user’s permission immediately while updating keys for unrevoked users. The event-driven policies of Akhtar et al. (2024) sit on this axis at evaluation time: the same policy may yield a different authorization at each evaluation depending on which runtime events have occurred, though the policies themselves are not rewritten in flight. The receipt model enforces nothing in flight. It records which policy version governed a past decision through the policy snapshot digest checked for equality in Section 3.5, and treats revocation after issuance as a change in the appraisal a later reviewer attaches to the record (Section 5.6). Enforcement mechanisms change what an agent may do next; the receipt preserves which policy governed a decision already made.

On persistent access-decision records, Ortega Pérez et al. (2025) come closest among the five. Their client-side encrypted access logging adds end-to-end encrypted device identification information to account activity logs, leveraging operating-system support and Fast IDentity Online 2 (FIDO2)-style attestations, so that past accesses can be attributed to devices without service-side device tracking. The protocol works alongside existing authentication, with a formal analysis of integrity, privacy, and unlinkability against honest-but-curious adversaries, along with a proof-of-concept implementation. Akhtar et al. (2024) also reach this axis from the blockchain side: their condition evaluations execute as blockchain transactions whose encrypted inputs and signed results persist as an immutable log, validated afterward by sampling; the final composite decision, however, is assembled off the chain by the process manager, so the durable object is the per-condition evaluation rather than a signed record of the completed decision. The anti-denial smart contract of Zhang et al. (2024) similarly leaves an on-chain record that a user acted, though not of the evidence behind an access decision. Persistent, attributable records of past access have therefore already been proposed, and this article claims no priority on the idea of such records. The recorded object differs. The log entry of Ortega Pérez et al. attributes an account access to a device for user-facing compromise detection. The receipt records the access decision itself and binds the policy snapshot, delegation, declared purpose, economic authorization, sensitivity class, and validation material into one individually signed record for later re-verification.

The comparison should also record where these systems are stronger than the receipt model. Ortega Pérez et al. (2025) carry a formal analysis and a proof-of-concept implementation; Rasori et al. (2024) evaluate on a real Internet-of-Things testbed; Akhtar et al. (2024) contribute an automata-theoretic composition method with a cost evaluation; Zhang et al. (2024) enforce immediate revocation with key updates for unrevoked users; South et al. (2025) chart a deployment path through standards already in production. The receipt model is exercised only in a deterministic synthetic corpus with fixture keys, and Section 6 states that boundary in full.

On evidence binding, each system above binds evidence to a different object. South et al. (2025) bind credentials and metadata to the agent, Ortega Pérez et al. (2025) bind encrypted device identity to log entries, Zhang et al. (2024) bind stored policy material to tamper-protected storage and user behavior to an on-chain audit record, and Akhtar et al. (2024) bind composite policy evaluation to the blockchain; the contribution of Rasori et al. (2024) concerns token issuance, revocation, and notification, and every artifact their design stores about an access is live authorization state with a deletion path: revoked token hashes leave the revocation list once the token expires. Usage-control sessions are deleted when access ends, so no persisted decision record remains. None of the systems surveyed in this section, across the auditable-access-control, authenticated-delegation, access-logging, and usage-control literature, was found to bind identity, delegation, declared purpose, policy snapshot, economic authorization, sensitivity class, and archived validation material for a single access decision into one individually signed record at the AI content/API boundary, and none reports a field-mutation experiment measuring which of those evidence fields change the verifier outcome for a completed decision. The contribution this article defends is therefore concrete: the record format that binds those fields, and the deterministic corpus in which removing or corrupting each field shows its effect on re-verification. That restates the gap of Section 2.4 across both comparison surfaces and is the object of study here.

3 Materials and methods

3.1 Study design

The study is a synthetic, reproducible laboratory experiment. It does not use real traffic, real publisher logs, real API telemetry, production credentials, human-subject data, or private operational data. All inputs are generated from a deterministic Python script using public fixture Hash-based Message Authentication Code (HMAC) keys. The HMAC keys are non-secret test fixtures for reproducibility and are not presented as a deployable cryptographic design.

The artifact contains the following:

• One synthetic publisher/API policy snapshot;
• One synthetic trust registry;
• A total of 15 scenario requests;
• A total of 15 mutation/control requests;
• A total of 30 generated receipts for scenarios and mutations;
• A total of three post-issue receipt-integrity controls;
• A JSON Schema for the receipt envelope;
• CSV/JSON result tables;
• A self-contained Python reproduction script.

The artifact is deposited on Zenodo (Sokolov, 2026). The reproduction command inside the package is python3 scripts/run_agent_access_receipt_lab.py.

The objective is to test whether removing, corrupting, or changing specific receipt field families changes the verifier outcome under the synthetic policy, and whether retained validation material changes post-decision inspectability when live validation endpoints are unavailable.

3.2 Receipt fields

Each receipt records the following field families:

• Receipt metadata: receipt_id, profile, issued_at, case_id, and synthetic, a field marking the record as synthetic test data;
• request_actor: the automated caller observed at the edge;
• principal_or_owner: the organization, account, or owner represented by the caller;
• identity_method and identity_issuer: how the caller identity was asserted and which issuer provided the assertion;
• delegated_user_or_mandate: any user or mandate scope presented for API access;
• intent_claim: the stated purpose, such as fetch, indexing, assistant action, or training;
• resource: the content or API resource and requested response sensitivity;
• policy_snapshot_digest: the policy digest presented or bound at decision time;
• current_policy_digest: the verifier’s current policy digest;
• economic_rule: payment-required and payment-token-present state;
• decision: the observed access decision;
• reasons: the verifier reason-code vector;
• validation_material: token digests, archive state, archive digest, and endpoint status;
• evidence_hashes: request, policy, and trust-registry digests;
• edge_receipt_signature: the synthetic edge signature over the receipt.

Because the generated receipt stores token digests rather than full token claims, later inspection of identity or payment-token details depends on retaining the corresponding archived or original validation material. The issued_at timestamp is recorded for reproducibility and receipt context, but the study does not evaluate trusted timestamping, clock synchronization, or time-source compromise.

The JSON Schema constrains required fields, enumerated decisions, digest shapes, and receipt structure. The schema is included to support reproducibility, not to claim a standard profile or certification target.

3.3 Synthetic policy and trust registry

The policy models four resources: one paywalled article, a summary API, a subscriber-profile API, and an unregistered bulk-export API. The policy records registered status, allowed intents, required scopes, sensitivity limits, delegation requirements, payment requirements, and a non-final delay action for public excerpt indexing.

The trust registry contains five synthetic issuers: one trusted agent identity issuer, one trusted payment issuer, one trusted edge receipt issuer, one untrusted broker identity issuer, and one untrusted scraper identity issuer. The identifiers are neutral synthetic labels. No real issuer, publisher, payment network, bot operator, or protocol provider is represented.

The configuration is deliberately minimal. The four resources are a compact set chosen so that every policy contrast the verifier must exercise is instantiated at least once: paywalled against free access, registered against unregistered surfaces, delegation-required against delegation-free access, sensitivity classes up to personal data and bulk export, and one resource carrying a non-final delay action. The five issuers give the verifier the issuer-trust contrasts the corpus exercises: trusted issuers for identity, payment, and edge receipt signing, and two untrusted identity issuers representing distinct untrusted-caller populations. Minimality is a design instrument rather than a simplification of convenience. With one policy clause behind each contrast, every verifier decision in Section 4 can be traced to the clause that produced it. The configuration is therefore a coverage instrument for the decision space of the synthetic policy, and it makes no claim to represent the size or structure of production policy sets.

3.4 Threat model and assumptions

The experiment is limited to field-level access-control failures and post-issue receipt tampering in a synthetic environment. It assumes a correctly operating receipt-generating edge, verifier, policy source, and trust registry. It does not evaluate compromised infrastructure, compromised or colluding issuers, key-management failures, malicious policy authorship, replay or double-spend behavior, privacy leakage from receipt contents, retention/redaction governance, or adversarial attempts to misstate declared intent. It also does not evaluate clock synchronization, trusted timestamping, time-source compromise, archive-store compromise, archive access-control failure, or evidentiary chain-of-custody for retained validation material.

Two of these excluded concerns deserve fuller design-level treatment, because they describe how receipts themselves would be attacked in practice: replay of receipts, and the privacy of the metadata a receipt stores. The experiment does not evaluate either concern empirically, but the receipt model constrains both by construction.

Receipt replay. An adversary might resubmit a previously issued valid receipt in an attempt to obtain unauthorized access. In this model, that attack fails by construction, because a receipt is evidence of a past decision and is never an access credential. Presenting a receipt confers no authorization; the access path runs through the live evidence families evaluated by the verifier (Section 3.5), and the receipt is only emitted after that evaluation. A replayed receipt therefore yields no access. The residual replay concern is evidentiary: an adversary could present an old receipt as if it documented a different or later request. Re-verification defeats this because the edge signature covers the request binding, the resource, the decision, and the policy snapshot digest, so a replayed receipt re-verifies only as a record of its original event and fails any freshness or binding check against the request it is claimed to document. A production profile should additionally bind a per-request nonce and an explicit issuance timestamp with a defined validity window for evidentiary use, so that duplicate submissions of the same receipt are detectable at the receipt store. The receipt-integrity controls in this laboratory already demonstrate the underlying mechanism: any change to signed decision fields, including the substitution of another request’s context, fails signature verification.

Privacy of receipt metadata. Because receipts persist after the interaction, they can outlive the consent and retention assumptions of the request itself, and stored identifiers or payment references would become an attractive secondary target. The receipt model therefore treats data minimization as a per-field design question. Principal and delegated-user identifiers can be carried as pseudonymous or salted-hash values that the operator can link to accounts only through a separate lookup under access control, so that a leaked receipt store does not directly expose user identity. Payment instruments are never stored in the receipt; the schema records the economic rule, the payment state, and issuer-trust outcomes rather than the payment token itself, and the same one-way treatment applies to validation material through the archive digest. Each remaining field should carry the minimum granularity that later review requires, with retention limits set by the dispute window rather than by default indefinite storage. These controls are design requirements for any deployment of the receipt concept; the synthetic laboratory uses fictitious actors and fixture tokens, so no real personal or payment data arises here.

3.5 Verifier logic

The verifier evaluates the following eight access-control evidence families:

• Identity token presence, issuer trust, signature, status, expiry, actor, and principal binding;
• Policy snapshot equality;
• Resource registration and API inventory status;
• Intent allowed for the target resource;
• Requested response sensitivity against policy;
• Required identity and delegation scopes;
• Payment token presence, issuer trust, signature, status, expiry, principal, resource, and sensitivity binding;
• Validation endpoint status and archived validation availability.

The verifier then emits one of five decisions: allow, allow_archived, delay, deny, or paywall. A separate receipt-integrity check verifies the synthetic edge signature over the generated receipt and detects post-issue changes to signed fields.

The following pseudocode summarizes the deterministic evaluation order that the deposited verifier script implements before it signs each receipt.FUNCTION evaluate(request, policy, trust registry): reasons := empty list verify identity token: presence, known and trusted issuer, valid signature, active status, not expired IF policy snapshot digest != current policy digest THEN record reason look up requested resource in policy IF resource unknown THEN record reason ELSE check: resource registered; declared intent allowed; requested response sensitivity within policy maximum; required scopes present in identity token; IF delegation required THEN delegation present, unexpired, covering required scopes IF identity token invalid THEN record its reasons ELSE require principal and actor claims to match the request IF requested sensitivity requires payment THEN verify payment token: trusted issuer, valid signature, settled, unexpired, bound to principal, resource, and sensitivity IF the only failure is a missing token THEN mark provisional paywall ELSE IF invalid THEN record payment reasons IF validation endpoint offline AND no archive THEN record reason ELSE IF offline AND archive digest != expected THEN record reason IF any reasons recorded THEN decision := deny ELSE IF offline with valid archive THEN decision := allow_archived ELSE IF provisional paywall THEN decision := paywall ELSE IF resource recommends non-final action AND requested sensitivity is public excerpt THEN decision := delay ELSE decision := allow assemble receipt field families; compute evidence hashes over request, policy, and trust registry; sign receipt with edge receipt key.

This pseudocode is a summary; the deposited script is normative, and the post-issue receipt-integrity check runs separately after the receipt is signed.

3.6 Scenario matrix

The scenario suite tests content and API decisions under one receipt grammar (Table 1). Unlike the mutation/control suite, scenario cases are not all single-factor controls. The final column lists illustrative decision-relevant variable families, and some scenarios produce multiple verifier reason codes.

Table 1. Synthetic scenario cases and expected verifier decisions.

The scenario set was constructed rather than sampled. Cases were selected so that every evidence family in Section 3.5 is exercised at least once, every decision in the five-decision vocabulary appears at least once, both content and API surfaces are represented, and the boundary conditions the study isolates are present in matched pairs: offline validation with an archive (C12) against offline validation without one (C13), and a missing payment token (C14) against an expired one (C08). Representativeness in this design means coverage of the decision space reachable under the synthetic policy rather than statistical representativeness of production traffic; the corpus exists to isolate field-to-decision dependencies, and Section 6 discusses how far such results generalize.

3.7 Mutation and integrity controls

The mutation/control suite mostly begins from the positive paid-fetcher case and changes one field family at a time (Table 2). M14 is an API-context delegation-expiry control, included because delegation expiry is meaningful on the API surface. This design makes the controlled field inventory testable: the expected outcome changes only when the changed field is decision-relevant under the synthetic policy.

Table 2. Mutation/control cases and expected verifier decisions.

The three receipt-integrity controls evaluate a valid generated receipt, a receipt with corrupted signature bytes, and a receipt with post-issue modification of signed decision fields. The last control models a plausible evidence-integrity risk: retrospective alteration of fields that should remain bound to the signed decision record.

4 Results

The result tables in this section are descriptive. The corpus is a fixed, enumerated case matrix, and the reported counts summarize exact expected-versus-observed matching over that matrix; no inferential statistical methods are used and no inferential claims are made.

The deposited v0.1.6 artifact reports deterministic reproduction results for the scenario, mutation, schema-shape, and receipt-integrity checks, with detailed per-case outcomes in Tables 1, 2 and the deposited CSV files. These aggregate checks establish internal consistency among the scenario fixtures, generated receipts, the required-field/schema-shape guard, and verifier output; they do not estimate performance on live traffic.

All 15 scenario outcomes matched their expected decisions. All 15 mutation/control outcomes matched their expected decisions. The decision-irrelevant observer-note mutation remained allow, providing a negative control against a verifier that rejects any receipt change regardless of policy relevance. The archived-validation cases remained inspectable as allow_archived; cases without an archive were denied (Table 3).

Table 3. Baseline reproduction results for the v0.1.6 artifact.

The distribution in Table 4 is skewed toward deny (21 of 30 receipts), and that skew is a designed property of the corpus rather than an empirical finding. The synthetic policy matrix is deliberately strict, and the mutation suite is constructed to fail: it mostly starts from the positive paid-fetcher case and invalidates one decision-relevant field family at a time, so the majority of the mutations must produce a denial for the harness to demonstrate that the field is decision-relevant. The scenario corpus similarly oversamples negative evidence conditions because each negative case exists to isolate one evidence family. The 21/30 figure therefore says nothing about deny rates in production traffic, where the decision mix depends on the caller population and the operator’s policy, and it should not be read as an estimate of any real-world quantity.

Table 4. Decision distribution across scenario and mutation receipts.

The two allow_archived receipts carry a different message. The scenario case C12 and its mutation counterpart M12 are the only conditions in the corpus where an otherwise degraded situation, a validation endpoint that is offline at decision time, still yields an acceptable outcome, and they do so only because archived validation material remains available and its digest still verifies. Every other degradation in the corpus is terminal for the decision. This supports reading validation survivability as the highest-value single field for auditability in this policy: it is the one evidence family whose presence converts an evidence outage from an audit dead end into a reviewable event, and whose absence (C13 and M09) is unrecoverable at review time. As with the decision skew above, this pattern reflects the recovery semantics the synthetic policy assigns to archived validation, the only evidence family given a non-terminal degraded state, rather than an empirically discovered ranking. If an operator can afford to strengthen only one receipt field beyond identity, this experiment suggests it should be the archived validation material and its digest binding.

The receipt-integrity controls also matched expectations. The baseline receipt signature verified; corrupted signature bytes failed; and post-issue changes to signed decision fields failed. The integrity controls therefore demonstrate that the synthetic receipt object can distinguish a valid generated record from a modified one within the simplified cryptographic environment. These results should be read as a controlled field-coverage and reconstructability test, not as a live-traffic performance benchmark.

5 Discussion

5.1 Bot identity is necessary but insufficient

The central result is structural: bot identity alone does not carry enough evidence for later review. The scenario and mutation matrices show that the decision can also depend on delegated authority, declared purpose, resource/API registration, sensitivity class, policy freshness, economic authorization, and validation survivability. A cryptographically authenticated agent can still be unauthorized for a sensitive API response. A trusted payment token can still be expired or bound to the wrong resource. A signed identity can still rely on an untrusted issuer.

This is not an argument against bot authentication. It is an argument against collapsing authentication into authorization, licensing, and forensic reviewability. Nor is it an argument against delegation infrastructure: an authenticated-delegation framework, in the sense of South et al. (2025), would supply exactly the delegation evidence whose survival the mutation matrix tests. A receipt model lets those dimensions remain separate while preserving them in one decision record.

5.2 Content access and API access share an evidence grammar

The same receipt envelope can represent a paywalled article request, a summary API call, an unregistered export endpoint, and a subscriber-profile request. The policies differ, but the evidence families recur: actor, principal, intent, resource, policy snapshot, scopes, payment state, sensitivity, and validation material. This supports the article’s main claim: publisher content access and API access by AI applications are not identical, but they are adjacent instances of an access-control evidence problem.

This matters for security review. A system that records only the visible web request may miss a downstream API overreach. A system that records only API authorization may miss content licensing or payment state. In this laboratory model, a receipt crossing both surfaces gives reviewers a single place to inspect the recorded decision, provided the relevant policy and validation material have also been retained.

5.3 Inventory and response sensitivity belong in the receipt

Cases C05 and C06 highlight the role of API inventory and sensitivity. In C05, the relevant failure is not caller identity, but an unregistered shadow export API. In C06, the summary API exists, and the caller has a relevant scope, but the requested response sensitivity exceeds policy. Following OWASP (2023), these cases treat incomplete inventory and authorization gaps as risks to sensitive business data.

In AI-mediated systems, the front-end interaction can obscure downstream API selection. A user may see one chat or agent interface, while the system invokes multiple APIs. The receipt therefore records the actual resource and sensitivity class, not merely the front-end interaction label.

5.4 Economic authorization is a security-relevant field

The payment cases show that economic authorization can materially affect a technical access decision. C01 succeeds because the verifier accepts a payment token as present, fresh, and bound to the resource and its sensitivity. C08 fails because the verifier rejects the payment token as expired. C14 returns paywall rather than deny because the request might proceed after economic authorization. M10 fails because the verifier rejects a token bound to a different resource.

The point is not that security systems should implement licensing policy directly. The point is that later dispute resolution may need to know whether a payment or license signal existed and how the verifier evaluated it. In this artifact, the receipt records payment requirement, token presence, verifier reason codes, and a token digest. Those fields do not reveal issuer, status, expiry, resource binding, or sensitivity binding unless the relying party also has archived or original validation material. If the record omits even this evidence, later review must infer intent and authorization from incomplete surrounding context.

5.5 Validation survivability is distinct from validation success

The archived-validation cases separate two states that are often conflated: “the live endpoint is reachable now” and “the evidence needed for validation survives.” C12 and M12 allow the request under archived-validation conditions: the endpoint is offline, but preserved validation material is available. C13 and M09 deny the request when no archive remains. M13 denies the request when the archive digest is tampered.

This mirrors a broader lesson from attestation and provenance systems: validation is not only a live network event. It is also a preservation problem. If the evidence needed to evaluate a decision disappears, later review becomes weaker even if the original decision was correct.

5.6 From synthetic laboratory to production

The synthetic design buys reproducibility at the cost of distance from production conditions, and it is fair to ask how the receipt model would behave under two conditions the laboratory does not exercise: dynamic policy and industrial scale.

Dynamic policy updates. Production edges change policy continuously through real-time rate limiting, key and issuer revocation, and rolling licensing terms, whereas the laboratory evaluates a single policy snapshot. The receipt model accommodates this because the receipt does not bind to “the policy” in the abstract; it binds to a policy-version identifier, here the policy snapshot digest that the verifier checks for equality. Under dynamic policy, each decision cites the exact snapshot in force at decision time, and a later reviewer evaluates the decision against that snapshot rather than against whatever policy is current at review time; the enforcement-side counterpart, notifying clients and resource servers of revoked rights so that behavior changes in flight, is the design of Rasori et al. (2024) discussed in Section 2.5. Rate-limit state would enter the model as one more evidence family recorded per decision, alongside payment state; Section 6 already lists rate limits among the boundaries of the compact policy model. Revocation after issuance is the more interesting case, and the laboratory already contains its shape: revocation of an issuer, key, or credential surfaces at re-verification as a validation-survivability question. A receipt whose live validation endpoint no longer vouches for the original material is exactly the C12/C13 condition, and the archived validation digest determines whether the decision remains reviewable. Revocation therefore does not invalidate the receipt as a record; it changes the appraisal a later reviewer attaches to it, consistent with the preservation lesson in Section 5.5 and the separation of evidence from appraisal noted in Section 2.3.

Industrial-scale deployments. For high-throughput API gateways, the relevant properties are per-decision cost and coupling. Receipt emission is constant time per decision: the edge assembles fields it already evaluated to make the decision, hashes the evidence, and signs once, so the marginal work does not grow with traffic beyond the per-request constant. Emission is also naturally asynchronous and batchable; because a receipt is evidence and never an access credential, it does not sit on the request’s critical path and can be flushed to an evidence pipeline in batches, in the same way high-volume access logs are shipped today. The schema is deterministic JSON and transport-agnostic, so gateways can carry receipts over whatever logging or streaming substrate they already operate, and a compact binary encoding of the same fields would be a straightforward engineering variant. What this experiment cannot supply is empirical throughput, latency, or storage figures; consistent with the limitations in Section 6, those require measurement on real gateway traffic, together with engineering decisions the laboratory does not model, such as sampling strategies for very high volumes, retention tiering, and key management for edge signing at fleet scale. The claim defended here is architectural: nothing in the receipt design couples its cost to policy complexity or traffic volume beyond a per-decision constant, and nothing in it requires synchronous emission.

6 Limitations

The study is a synthetic laboratory, not a production measurement campaign. It tests whether a compact receipt vocabulary can preserve the evidence needed to reconstruct AI-mediated content and API access decisions after the fact. That controlled setting directly instantiates the claim advanced here: missing receipt fields should be visible as decision failures, integrity failures, or materially weaker audit records.

Four boundaries remain. First, the public HMAC fixtures are reproducible test keys, not a deployment design for key management, revocation, hardware-backed signing, multi-issuer governance, or resistance to downgraded profiles. Second, the policy model is intentionally compact: it covers identity, delegation, intent, freshness, payment state, sensitivity, archived validation, and receipt integrity, but not settlement, appeals, rate limits, latency, privacy-preserving disclosure, or production traffic behavior. Third, declared intent is treated as evidence to preserve, not as proof of the caller’s later data use.

A fourth boundary concerns external validity. The synthetic corpus is built from deployed primitive classes rather than from invented mechanisms: scopes and delegation follow the OAuth family, payment and licensing state mirrors paywalled publishing, policy snapshots and crawler intents mirror robots-style governance, and issuer trust and archived validation follow the attestation and provenance patterns of Section 2.3. Each scenario mirrors a recognizable operational dispute, such as a paywalled fetch, a shadow export API, a stale policy snapshot, or an offline validation endpoint. What transfers to production is therefore the mechanism claim: a missing or corrupted decision-relevant field changes the outcome or removes later reviewability. What does not transfer is any frequency or magnitude claim; deny rates, decision mixes, throughput, and adversary populations are properties of real deployments, which is why Section 4 declines to read Table 4 as a production distribution. The open transfer question is whether a given production policy preserves the same field-to-decision dependencies, and it is testable with the method used here: rerun the verifier against an operator’s real policy snapshot and scenario set, consistent with the production path discussed in Section 5.6.

These limits narrow the claim without weakening its practical motivation. The result is not that a laboratory verifier is itself a product. The result is that receipt-level evidence is a useful substrate for evaluating systems that need later audit, dispute handling, policy debugging, or trustworthy access accounting.

7 Conclusion

AI-mediated content and API access is better understood as an auditable access-control evidence problem than as bot classification alone. The synthetic agent-access receipt studied here preserves verifier outcomes and evidence fields for identity, delegation, declared intent, resource or API surface, policy freshness, payment state, response sensitivity, archived validation material, evidence hashes, and receipt integrity. The v0.1.6 laboratory is intentionally small, but the mutation results show why those fields matter: changing one decision-relevant field changes the decision or integrity outcome under the synthetic policy.

Several extensions would test how far the mechanism generalizes. The most direct is replaying the verifier over production traces or operator logs, which would test whether real policies preserve the field-to-decision dependencies observed here. A second is systematic variation of the policy configuration beyond the single strict snapshot, including permissive profiles, rate-limit families, and alternative sensitivity orderings, to map how the set of decision-relevant fields shifts with policy. A third is operational assessment in a deployment: measuring throughput, latency, and storage at a real gateway, engineering key management for edge signing at fleet scale, and defining retention governance for receipt stores, all deferred by Sections 5.6 and 6. Integration work could then consume verification outputs from deployed bot-authentication mechanisms as the identity-evidence family of the receipt, following Section 2.4.

The broader implication is practical. As bot authentication, licensing protocols, API authorization, and provenance systems evolve, many operators may need records that explain access decisions after the fact. A receipt does not make a decision correct. When paired with retained policy and validation material, it can make the decision reconstructable later.

Author’s note

The author declares that this study was conducted independently using synthetic data and public sources. It did not use confidential information, client data, private telemetry, production systems, or third-party proprietary materials.

Generative AI statement

The author(s) declared that Generative AI was used in the creation of this manuscript. The author used OpenAI Codex with GPT-5 to polish the final draft. The author reviewed and takes responsibility for all claims, citations, artifact contents, and final text.

Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.

Publisher’s note

All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.

Footnotes

Edited by: Tanja Pavleska, Institut Jožef Stefan (IJS), Slovenia

Reviewed by: Jon Crowcroft, University of Cambridge, United Kingdom

Ibrahim Adabara, Kampala International University, Uganda