{ "domains": [ "identity", "authz", "discovery", "protocols", "netmgmt", "attestation", "iot", "other" ], "count": 65, "candidates": [ { "name": "draft-zambo-aer1", "title": "AER-1: A Portable Execution Receipt for AI Agent Tool Calls", "abstract": "This document specifies AER-1, a small vocabulary for recording one AI agent tool call as a portable, independently checkable execution receipt. A receipt identifies the execution, records when it happened, preserves the canonical bytes used for the output commitment, names the tool and caller scope, carries a provenance class, and resolves at a stable public URL. The format separates what the system observed from claims about the outside world, and it separates provenance (who ran or reported the action) from the record itself. A reference implementation is deployed, and its receipts are publicly verifiable without an account or token. The specification also defines workflow receipts, which bind an ordered sequence of step receipts to a single goal with a Merkle root over the step sequence, and hash-chained job timelines for tamper-evident sequencing of executions. This revision is editorial only: it adds the missing Table of Contents entry for the Acknowledgments section, rewraps example lines that exceeded the 72-character limit, and shortens this abstract. It changes no receipt field, procedure, verification rule, or conformance vector.", "full": true, "rev": "11", "time": "2026-10-05T23:06:34Z", "group": "individual", "pages": 12, "relevant": 0.92, "domain": "attestation", "domain_conf": 1, "centrality": 1.96, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-06T00:17:27.868Z" }, { "name": "draft-gilda-wimse-agent-audit-record", "title": "An Audit Record Format for AI Agent Authorization Decisions", "abstract": "This document defines a record format for AI agent authorization decisions. The format is one in-toto predicate type, signed inside a DSSE envelope. It carries the seven minimum audit fields that the WIMSE AI Identity Management System framework requires, and two properties that make those fields checkable: a canonicalization contract, and both the authorization decision and the observed effect with a derived three-valued agreement between them. That framework places the record format out of scope and takes no IANA action. This document supplies the format. It defines no policy.", "full": true, "rev": "02", "time": "2026-10-05T15:54:35Z", "group": "individual", "pages": 31, "relevant": 0.92, "domain": "attestation", "domain_conf": 0.6, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-05T18:17:28.439Z", "evaluated": "2026-10-05T18:17:28.439Z" }, { "name": "draft-mo-cats-agent-state-affinity", "title": "State, Storage, and Compute Affinity for AI Agent Service Selection in Computing-Aware Traffic Steering", "abstract": "AI agent services are stateful and long-running: the speed with which a step can be served depends on whether the session's context, retrieved data, tool results, and model-side state such as a key-value (KV) cache are already available at, or near, the selected service contact instance, and on whether the computation that the step needs is ready there. Computing-Aware Traffic Steering (CATS) exposes computing and network metrics and defines service contact instance affinity, but it does not expose the availability of reusable state, does not distinguish a hard locality constraint on state from a preference for reusing it, does not provide a way to compare the cost of moving state with the cost of recomputing it, and does not represent the readiness of a specific computation. This document describes affinity in three coupled dimensions -- state, storage, and compute -- for agent service selection. It states the motivation and the goals of introducing affinity, the requirements and constraints that affinity places on the mapping of an agent workload onto storage and compute resources, the metrics and measurement methods by which affinity is observed, the mechanisms and the procedure by which affinity is assured, and two cases in detail: a long-horizon session that passes through several stages, and a group of similar agents or of tenants served by shared reusable state. This document defines no wire protocol, no encoding, and no data model, and it does not define the transfer mechanisms themselves.", "full": true, "rev": "00", "time": "2026-10-05T15:52:37Z", "group": "individual", "pages": 48, "relevant": 0.88, "domain": "other", "domain_conf": 0.58, "centrality": 1.93, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-05T18:17:28.439Z", "evaluated": "2026-10-05T18:17:28.439Z" }, { "name": "draft-alla-agent-identity-document", "title": "The Agent Identity Document: A Hosted, Accountable Public Record for AI Agents", "abstract": "Autonomous software agents increasingly act on the public internet with no name that a counterparty can check, no published party that answers for them, and no way to learn that an operator has withdrawn an agent. This document specifies the Agent Identity Document, a small JSON document served at a well-known URI on a hostname assigned to one agent, and the practices an identity provider follows when it hosts such names for operators who do not run their own domain. The document records what the provider knows to be true (the hostname, its service endpoints and the identity's lifecycle status) separately from what the operator asserts (a description, a contact, a homepage, a public key), and publishes the provider's dated, expiring checks on the operator rather than a single trust level. Lifecycle status is distinct from availability. A suspended identity publishes a deliberately minimal document. Every identity is held by an accountable person or organisation; an agent is never itself an account holder, and agents are never given authority over DNS. This document describes a practice in production at one provider. It is published so that the format can be reviewed, implemented by others and mapped onto related work, and it requests registration of a well-known URI suffix.", "full": true, "rev": "00", "time": "2026-10-05T15:41:32Z", "group": "individual", "pages": 15, "relevant": 0.89, "domain": "identity", "domain_conf": 0.98, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-05T18:17:28.439Z", "evaluated": "2026-10-05T18:17:28.439Z" }, { "name": "draft-arsentev-llm-context-discovery", "title": "Discovery and Retrieval of Publisher-Curated Context Files for Large Language Model Consumers", "abstract": "Publishers have begun to serve a curated, plain-text summary of a web origin intended for consumption by large language models and by the crawlers that feed them, most visibly under the de facto file name \"llms.txt\". The practice is described by an informal proposal which, in its current version, recommends existing link relations from individual pages to the file. It has no media type, no rules that bound the cost of retrieval, and no way for a consumer that starts from an origin's robots.txt or from a fixed well-known location to learn that such a file exists. This document specifies discovery and retrieval for publisher-curated context files. It defines the well-known URI \"llm-context\", the link relation type \"llm-context\", and an extension record for the robots exclusion protocol, so that a publisher may advertise a context file by three independent paths and a consumer may find it without guessing. It specifies a two-tier arrangement of an index resource and optional detail resources, states conditional-request and size requirements that keep retrieval affordable for both parties, and describes the relationship of this mechanism to the robots exclusion protocol, to sitemaps, to the llms.txt proposal itself, and to work in the IETF on AI usage preferences, agent communication and the discovery of AI agents. This document also reports measurements from an operational deployment in which requests presenting twenty crawler tokens of search and language-model providers numbered 46,155 over fifteen days at one origin server, without once retrieving the context file the origin was serving, while the same crawler tokens retrieved robots.txt 698 times in the three days after the context file was deployed. The measurement figures in revision -00 were computed on an incomplete log and are corrected here. The absence of a discovery mechanism, rather than the absence of interest, is the hypothesis this document acts upon.", "full": true, "rev": "01", "time": "2026-10-05T13:41:56Z", "group": "individual", "pages": 22, "relevant": 0.91, "domain": "discovery", "domain_conf": 0.94, "centrality": 1.02, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-05T18:17:28.439Z", "evaluated": "2026-10-05T18:17:28.439Z" }, { "name": "draft-arsentev-agent-run-metrics", "title": "Agent Run Metrics: A JSON Interchange Format for Resource Accounting of Language-Model Agent Runs", "abstract": "Autonomous software agents driven by large language models execute multi-step runs in which the same conversational context is retransmitted to a model on every step. The resulting resource consumption is dominated by repeated input rather than by generated output, and it is reported today in mutually incompatible, vendor- specific shapes. This document defines Agent Run Metrics, a JSON interchange format that describes the resource consumption of a single agent run and of its constituent steps, together with a small set of derived quantities whose computation is specified exactly. It states normatively that one reported step corresponds to one completed model invocation, so that the several records a runtime may write while a single response is produced are not mistaken for several invocations, and it defines how the consumption of delegated sub-runs is attributed without being counted twice. The format carries counters, timing and cost attribution only; it deliberately excludes prompt and completion content. This document defines the initial values of two extensible enumerations and the rule by which they are extended; it requests no IANA action.", "full": true, "rev": "01", "time": "2026-10-05T13:32:28Z", "group": "individual", "pages": 39, "relevant": 0.63, "domain": "other", "domain_conf": 0.96, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-05T18:17:28.439Z", "evaluated": "2026-10-05T18:17:28.439Z" }, { "name": "draft-prabhu-nmrg-prompt-schema-llm", "title": "Framework for Normalizing Multi-Vendor Network Inputs for LLM-Assisted Network Management", "abstract": "Large Language Models (LLMs) are increasingly used to assist network management tasks such as troubleshooting, intent translation, and automation. Network operations, however, rely on data from many vendors and sources: CLI output, configuration snippets, telemetry, alarms, and vendor-specific APIs. These inputs differ in format, structure, and semantics, which makes it difficult to present a consistent interface to an LLM. This document describes a framework for standardizing such multi-vendor inputs for LLM-assisted network management. Incoming messages from multi-vendor network elements are first handled by an Input Classifier, which determines the nature of each input and assigns it to one of three categories: performance, configuration, or response, using a hybrid approach (rule-based classification first, with escalation to a Small Language Model (SLM) when rules are insufficient). The classified input is then passed to the corresponding Structurer among the Performance Structurer, Configuration Structurer, and Response Structurer, each of which produces a normalized, structured representation (typically with SLM assistance and optional confidence scoring). That structured output is fed to a Prompt Schema Generator, which creates a structured, vendor-agnostic schema and supplies schema-aligned prompts to the central LLM. This document specifies the architecture and component roles for use in design and implementation. It does not define a wire protocol; it is published for informational purposes.", "full": true, "rev": "01", "time": "2026-10-05T10:08:25Z", "group": "individual", "pages": 15, "relevant": 0.74, "domain": "netmgmt", "domain_conf": 1, "centrality": 1.59, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-05T12:17:30.759Z", "evaluated": "2026-10-05T12:17:30.759Z" }, { "name": "draft-embesozzi-oauth-agent-native-authorization", "title": "OAuth 2.0 Agents Native Authorization via Structured Elicitation", "abstract": "This document defines a Structured Elicitation extension to the OAuth 2.0 First-Party Applications (FiPA) specification [FiPA], establishing a standard metadata format for FiPA authorization challenge responses. FiPA leaves the format for advertising available authenticators and their required inputs undefined, preventing interoperable implementation by AI Agents and other non- browser clients. This extension adds an elicitations array to the FiPA Authorization Challenge Response, providing a standard metadata format for authenticator challenges. Model Context Protocol (MCP) Elicitation [MCP-Elicitation] is the normative reference binding. This specification covers the just-in-time (JIT) authorization for AI Agents executing on behalf of users in Human-to-Agent (H2A) flows.", "full": true, "rev": "00", "time": "2026-10-05T07:09:05Z", "group": "individual", "pages": 17, "relevant": 0.94, "domain": "authz", "domain_conf": 1, "centrality": 1.88, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-05T12:17:30.759Z", "evaluated": "2026-10-05T12:17:30.759Z" }, { "name": "draft-veridom-omp-euaia", "title": "OMP Domain Profile: EU AI Act Article 12 Logging and Traceability Requirements for High-Risk AI System Operators", "abstract": "This document defines a domain profile of the Operating Model Protocol (OMP) for high-risk AI system operators subject to Article 12 of Regulation (EU) 2024/1689 (the EU AI Act). Article 12 requires that high-risk AI systems automatically generate tamper- resistant logs capable of ensuring traceability throughout the system's lifetime. This profile specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture (SHA-256, RFC 3161, institution signature) satisfy the Article 12 requirements, and defines the domain-specific Watchtower configurations and Audit Trace schema extensions applicable to EU high-risk AI deployments under Annex III of the Regulation. The core OMP specification is defined in a separate Internet-Draft (\\\"Operating Model Protocol (OMP): A Deterministic Decision-Enforcement Protocol with Externalized Proof-of-Integrity\\\").", "full": true, "rev": "00", "time": "2026-10-05T07:09:05Z", "group": "individual", "pages": 13, "relevant": 0.62, "domain": "attestation", "domain_conf": 0.97, "centrality": 1.58, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-05T12:17:30.759Z", "evaluated": "2026-10-05T12:17:30.759Z" }, { "name": "draft-wang-lisp-ai-agent", "title": "Using LISP as a Network Substrate for AI Agent Communication", "abstract": "The emergence of distributed artificial intelligence (AI) systems, particularly those composed of autonomous agents operating across cloud, edge, and endpoint environments, introduces new networking requirements. These include location transparency, seamless mobility, multi-homing, and logical isolation at scale. This document explores how the Locator/ID Separation Protocol (LISP) can serve as a robust network substrate to meet these requirements. The document outlines use cases, design considerations, and minimal extensions to the existing LISP framework to support context-aware mapping and AI agent-centric communication.", "full": true, "rev": "01", "time": "2026-10-05T07:09:03Z", "group": "individual", "pages": 11, "relevant": 0.75, "domain": "protocols", "domain_conf": 0.85, "centrality": 1.55, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-05T12:17:30.759Z", "evaluated": "2026-10-05T12:17:30.759Z" }, { "name": "draft-c4tz-marc", "title": "MARC: A Control and Uncertainty Disclosure Profile for Generative Models and Agents", "abstract": "This document specifies MARC, an experimental, vendor-neutral profile for control and uncertainty-disclosure metadata in generative models and agentic systems. MARC separates pre-decision capability assessment from post-decision answer confidence, identifies uncertainty sources and confidence targets, and defines a bounded set of primary actions and a minimal disclosure object. The experiment evaluates whether independently developed components can exchange and interpret these metadata consistently across implementation and protocol boundaries. It also supports evaluation of action selection, uncertainty attribution, confidence calibration, and downstream presentation. MARC specifies externally observable semantics. It does not define model internals, transport, authentication, authorization, agent discovery, tool schemas, or task execution, and it does not require disclosure of internal reasoning. The intended users are implementers of agent runtimes, orchestration layers, model gateways, evaluation systems, and user interfaces. This document does not define an Internet Standard.", "full": true, "rev": "03", "time": "2026-10-04T22:21:01Z", "group": "individual", "pages": 55, "relevant": 0.7, "domain": "other", "domain_conf": 0.5, "centrality": 1.84, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-05T00:17:31.083Z", "evaluated": "2026-10-05T00:17:31.083Z" }, { "name": "draft-newton-agreement-evidence", "title": "Agreement Evidence for Multi-Party Agent Negotiation", "abstract": "Autonomous agents can exchange offers and signatures without producing an artifact that records which parties reached which outcome, over which transcript digest and message count, and for how long that record may be relied upon. This document defines JSON agreement-evidence objects for structured, multi-attribute negotiation. The core object is an agreement attestation. A verified attestation establishes one thing: that a named set of parties jointly countersigned a stated outcome over a stated transcript digest and message count, together with behavioral counters each of them accepted. It does not establish that the outcome matches what the transcript says, that any statement a party made is true, or that the parties are anonymous. The format provides no member for a negotiated price, quantity, date, or principal identity. A producer is obligated not to place those values in the free-text members the format does provide, and a verifier cannot detect a violation of that obligation, so the absence of term values from a received object is a producer's obligation rather than a verified property. Sections 4 through 8 and 10 define every member of the object, its JSON type, its encoding, its value constraints, and the verification procedure. This document also defines relying- side freshness obligations and describes related approval, fulfillment, and revocation artifacts, whose formats it leaves to other documents. This document does not define identity, authority delegation, payment, settlement, transport, boundary-decision receipts, or a general evidence composition and sufficiency model.", "full": true, "rev": "00", "time": "2026-10-04T16:58:31Z", "group": "individual", "pages": 47, "relevant": 0.67, "domain": "attestation", "domain_conf": 1, "centrality": 1.76, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-04T18:17:27.990Z", "evaluated": "2026-10-04T18:17:27.990Z" }, { "name": "draft-levi-agent-certification", "title": "Autonomous Agent Certification Protocol (AACP)", "abstract": "This document defines the Autonomous Agent Certification Protocol (AACP), a framework for binding successful evaluation of an AI agent to cryptographically verifiable evidence of demonstrated capability. AACP introduces Evaluation Profiles that define the conditions under which an agent may be certified for a specific capability. An Agent Configuration that satisfies an Evaluation Profile may receive a short-lived Agent Certification Credential (ACC) bound to the configuration that was evaluated. An ACC does not grant access to a resource. It provides verifiable evidence that an agent has demonstrated a capability under defined evaluation conditions. Existing authorization systems may require such evidence as a condition for granting corresponding production permissions. AACP therefore separates capability certification from identity, authentication, delegation, and authorization.", "full": true, "rev": "00", "time": "2026-10-04T11:52:31Z", "group": "individual", "pages": 23, "relevant": 0.93, "domain": "attestation", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-04T12:17:31.175Z", "evaluated": "2026-10-04T12:17:31.175Z" }, { "name": "draft-klassen-eu2122-content-profile", "title": "EU2122 V1.0 Standard: Content Profile for AI Output Verification Receipts", "abstract": "This document defines a content profile for AI output verification receipts. It specifies the minimum fields, classification taxonomy, and evidentiary properties that a receipt MUST contain in order to constitute verifiable evidence that an AI-generated output was checked before a human or downstream agent acted on it. The profile is designed to be carried over any conformant wire format, including ACTA signed receipts, SCITT transparency logs, and standalone JSON or CBOR payloads. Existing IETF drafts in this space define wire formats for signing, transmitting, and storing AI agent receipts. None defines what a verification receipt must contain at the content layer. This document fills that gap. It introduces a mandatory fourteen-category failure taxonomy (the Information Bottleneck Species), a verification verdict schema, and evidentiary field requirements derived from the EU AI Act (Regulation 2024/1689), the Product Liability Directive (2024/2853), and the IDW PS 861 audit standard. We invite and even urge implementers to adopt, populate and grow the AI Output Verification market segment, which the author has also defined in communications to Gartner, Forrester, PAC/Teknowlogy, and IDC. The category exists. The specification is here. Build to it.", "full": true, "rev": "02", "time": "2026-10-03T11:40:13Z", "group": "individual", "pages": 16, "relevant": 0.83, "domain": "attestation", "domain_conf": 1, "centrality": 1.85, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-03T12:17:32.548Z", "evaluated": "2026-10-03T12:17:32.548Z" }, { "name": "draft-beyer-agent-identity-avian-carriers", "title": "Agentic Identity and Provenance over Avian Carriers (AIPAC)", "abstract": "This document specifies a method for establishing cryptographic identity and provenance attestation for agentic AI systems operating over Avian Carriers (AC). As large language models increasingly delegate sub-tasks to other models via pigeon, questions of authorship, intent, and hallucination propagation across feather- based transport layers demand urgent standardization. This document extends the delegation chain model and provenance structure of draft-beyer-agent-identity-architecture-00 to the specific constraints of feather-based transport layers, and extends RFC 1149, RFC 2549, and RFC 6214 to address agent identity. It is an April 1 publication.", "full": true, "rev": "00", "time": "2026-10-03T07:09:05Z", "group": "individual", "pages": 8, "relevant": 0.58, "domain": "identity", "domain_conf": 0.63, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-03T12:17:32.548Z", "evaluated": "2026-10-03T12:17:32.548Z" }, { "name": "draft-palanisamy-scitt-aac-otel", "title": "OpenTelemetry Correlation Extension for Agent Action Capsules", "abstract": "This document defines org.agentactioncapsule.otel, a namespaced payload extension for the Agent Action Capsule profile. The extension carries OpenTelemetry trace and span context alongside a sealed agent-action record so that the Capsule and the observability spans describing the same action can be joined after the fact. It maps the OpenTelemetry Generative AI semantic conventions onto Capsule fields where a mapping is well defined and states which OpenTelemetry values MUST NOT enter a Capsule at all. The extension does not alter Capsule verification: a verifier that does not implement it treats the block as informational.", "full": true, "rev": "00", "time": "2026-10-03T03:06:11Z", "group": "individual", "pages": 15, "relevant": 0.88, "domain": "attestation", "domain_conf": 0.62, "centrality": 1.89, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-03T06:17:30.058Z", "evaluated": "2026-10-03T06:17:30.058Z" }, { "name": "draft-dogru-cedulon-core", "title": "Spend Receipts and Payment Rail Reconciliation for AI Agents", "abstract": "This document addresses auditable payments for AI agents and builds upon state-of-the-art HTTP 402, AP2 and credit card systems. We specify a cryptographically secured payment reconciliation protocol using a Trade Manifest (a signed offer before payment), a Policy Decision Point with default deny, a Spend Receipt (a COSE/CWT claim set issued after a gated payment), and rail-extract reconciliation.", "full": true, "rev": "03", "time": "2026-10-02T18:54:38Z", "group": "individual", "pages": 73, "relevant": 0.84, "domain": "protocols", "domain_conf": 0.44, "centrality": 1.53, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-03T00:17:31.784Z" }, { "name": "draft-fane-opena2a-aap", "title": "OpenA2A Agent Authorization Protocol (AAP)", "abstract": "This document defines the OpenA2A Agent Authorization Protocol (AAP), a protocol for authorization in AI agent systems. AAP provides mechanisms for agent identity assertion, scoped capability grants, cross-agent delegation, behavioral attestation, cross-organizational federation, and revocation propagation. AAP is the authorization complement to agent communication protocols such as A2A and the Model Context Protocol, in the same way that OAuth 2.0 complements HTTP for web applications. AAP has two layers. The token model, defined in this document, specifies the AAP credentials and assertions: what they contain, how they are signed, and how they are verified. A companion broker and resolution layer specifies how an agent obtains and exercises a grant without the credential value ever entering the agent's reasoning context. This confinement property, that no secret, temporary credential, or backend identifier reaches the agent or the model behind it, is the primary design goal of the protocol. This revision adds a structured, mandatory-to-understand \"authorization_details\" claim with a typed entry registry and a per- type attenuation relation for delegation, an \"aap_crit\" claim naming the claims a verifier must understand, a \"cnf\" claim binding a token to the presenter's key, a session label in the behavioral attestation claim, and a local grant revocation list.", "full": true, "rev": "02", "time": "2026-10-02T15:46:09Z", "group": "individual", "pages": 25, "relevant": 0.96, "domain": "authz", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-02T18:17:32.343Z", "evaluated": "2026-10-02T18:17:32.343Z" }, { "name": "draft-khandelwal-bmwg-agent-memory-integrity", "title": "A Benchmarking Method for the Integrity of AI Agent Memory at Rest", "abstract": "AI agents increasingly persist memory across sessions and treat that memory, on the next turn, as if it were their own prior experience. This document defines a benchmarking method that measures whether an agent's memory subsystem detects that its persisted memory has been altered, removed, reordered, replayed, or forged at the storage layer, and refuses to serve that memory or reports it before it is served. The method defines eight storage-level edits, three verdict classes, a detection-point distinction between read time and audit time, three control cases, and a scoring rule. It is a laboratory method for controlled, reproducible measurement, in the spirit of RFC 2544 and RFC 8239, and it is intended as a test method for the \"Protection of Memory Data Integrity\" metric under discussion in the Benchmarking Methodology Working Group. This revision adds a control that proves each edit landed as intended, reports the method's results on thirteen memory subsystems including six that claim tamper evidence, and records the first vendor fix made in response to a measurement.", "full": true, "rev": "01", "time": "2026-10-02T14:05:15Z", "group": "individual", "pages": 12, "relevant": 0.76, "domain": "attestation", "domain_conf": 0.78, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-02T18:17:32.343Z", "evaluated": "2026-10-02T18:17:32.343Z" }, { "name": "draft-sharif-x509-agent-identity-profile", "title": "X.509 Certificate Profile for Autonomous AI Agent Identity", "abstract": "This document defines an X.509 certificate profile for identifying autonomous AI agents. It specifies a new X.509v3 extension, AgentIdentity, that encodes agent-specific metadata within a standard X.509 certificate, including agent trust level, operational capabilities, delegation constraints, owner attribution, and revocation control endpoints. The profile enables certificate authorities (CAs) to issue interoperable agent identity certificates that any relying party can parse, validate, and enforce, regardless of the issuing CA or the platform that provisioned the agent. The design builds on existing PKI infrastructure (RFC 5280), SPIFFE Verifiable Identity Documents (SPIFFE SVIDs), and the MCPS cryptographic signing layer (draft-sharif-mcps-secure-mcp). It does not require changes to X.509v3 certificate parsing or to existing CA issuance pipelines beyond supporting a new non-critical extension.", "full": true, "rev": "04", "time": "2026-10-02T10:32:50Z", "group": "individual", "pages": 25, "relevant": 0.95, "domain": "identity", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-02T12:17:34.731Z", "evaluated": "2026-10-02T12:17:34.731Z" }, { "name": "draft-fane-opena2a-aip", "title": "OpenA2A Agent Identity Protocol (AIP)", "abstract": "This document defines the OpenA2A Agent Identity Protocol (OpenA2A AIP), an open standard for creating, managing, and verifying cryptographic identities for AI agents. As AI agents proliferate across browsers, cloud platforms, and enterprise environments, systems need a standardized answer to the question of which agent is present, what it is permitted to do, and whether it should be trusted. OpenA2A AIP is distinguished by five elements that it places at the center of the design: a multi-factor behavioral trust score that is computed from independently verifiable signals; a portable signed credential, the Agent Trust eXtension, carrying a hybrid Ed25519 and ML-DSA-65 signature for post-quantum readiness; an append-only, RFC 9162-style Merkle transparency log for identity and credential issuance; agent identifiers expressed as W3C Decentralized Identifiers, provider-scoped as a did:web profile at the identity- provider layer and ecosystem-scoped under the registered did:opena2a method at the trust-fabric layer; and a structured capability vocabulary with reserved namespaces. On top of these, the protocol specifies challenge-response verification, behavioral governance policies, a lifecycle model, and an append-only audit log. The qualifier \"OpenA2A AIP\" is used throughout this document because the abbreviation \"AIP\" is shared by other Internet-Drafts. OpenA2A AIP is framed as complementary to agent communication protocols such as A2A and the Model Context Protocol, and to identity and credential standards such as OpenID Connect, WebAuthn, and the W3C Verifiable Credentials Data Model.", "full": true, "rev": "03", "time": "2026-10-02T07:21:49Z", "group": "individual", "pages": 29, "relevant": 0.97, "domain": "identity", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-02T12:17:34.731Z", "evaluated": "2026-10-02T12:17:34.731Z" }, { "name": "draft-wei-aic-jwt", "title": "AI Agent Identity Certificate (AIC) JSON Web Token Profile", "abstract": "The AI Agent Identity Certificate (AIC) defines a data model in which the cryptographic identity of an AI agent is bound to a responsible principal, together with a structured capability container, delegation mode, authorization constraints, and principal-signed delegation evidence. The normative definition of this model is specified by the AIC specification, where it is encoded in ASN.1 and carried in X.509 certificates, enabling authorization decisions at the transport layer, including fully offline operation. Many HTTP, web, and OAuth 2.0 (RFC 6749) deployments cannot present X.509 certificates at the transport layer. This document therefore defines AIC-JWT as a JWT-based application-layer representation of the AIC data model defined by the AIC specification. AIC-JWT is a companion representation, not a replacement for the X.509 form and not a new authorization model. AIC-JWT uses the standard JWT (RFC 7519) and JWS (RFC 7515) mechanisms as its carrier and cryptographic envelope. Its authorization semantics are inherited from the AIC model rather than defined by JWT or OAuth. In particular, the outer AIC-JWT is issuer- signed and carries the principal-signed DA JWT as the value of the top-level da claim, preserving the two-layer signature model of AIC. The normative content of this document is limited to: * a mapping from the X.509 AIC extension fields to JWT claims that preserves the AIC data model and its two-layer signature model; * representation and key-binding rules for the principal-signed DelegationAuthorization; * validation rules for AIC-JWT, including claim consistency, audience, and key-binding checks; and * a thin OAuth 2.0 consumption profile defining presentation of the DA at a token endpoint as an RFC 7523 JWT bearer authorization grant and the projection of the AIC authorized and representative delegation modes into OAuth roles.", "full": true, "rev": "02", "time": "2026-10-02T07:21:28Z", "group": "individual", "pages": 50, "relevant": 0.93, "domain": "identity", "domain_conf": 0.71, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-02T12:17:34.731Z", "evaluated": "2026-10-02T12:17:34.731Z" }, { "name": "draft-laplante-av-air-routing-en", "title": "AV-AI.R: A.V.AN Vectorized Artificial Intelligence Routing -- Eco-Responsible Transmission of IP Packets between AI Agents via Carriers Augmented by Artificial Intelligence", "abstract": "This memo amends RFC 2549 \"IP over Avian Carriers with Quality of Service\" by introducing an eco-responsible inter-AI communication channel based on carriers whose cognitive capabilities have been augmented by embedded language models (edge-LLM). AV-AI.R defines the communication protocol between artificial intelligence agents via carriers equipped with miniaturized transformer neurons, offering a low-carbon-footprint alternative to conventional data centers. This protocol is not recommended for production use, except in the event of fiber outage or major ecological crisis. This memo is an experimental protocol document submitted as an Independent Submission in the tradition of RFC 1149 and RFC 2549.", "full": true, "rev": "00", "time": "2026-10-02T07:09:04Z", "group": "individual", "pages": 13, "relevant": 0.52, "domain": "protocols", "domain_conf": 0.99, "centrality": 1.94, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-02T12:17:34.731Z", "evaluated": "2026-10-02T12:17:34.731Z" }, { "name": "draft-wei-aic-identity-cert", "title": "AI Agent Identity Certificate (AIC) Extension for X.509 v3", "abstract": "This document defines the AI Agent Identity Certificate (AIC) Extension for X.509 v3 certificates. The AIC extension enables binding of an AI Agent's cryptographic identity to a natural person (principal), providing cryptographic evidence that can support attribution of AI-autonomous actions to a principal. This specification intentionally separates cryptographic delegation from authorization semantics: AIC defines the cryptographic binding between agent and principal, while all capability and policy semantics are defined externally by vendors, industries, or regulators. The extension is identified by the IANA Private Enterprise Number 66257 assigned to the document author's organization. The AIC extension carries agent identity fields (agentId, delegationMode), a principal identifier (principalUid) linking the agent to the authorizing principal, a container-based capability declaration, authorization boundary constraints, and delegation authorization evidence with replay protection. A companion PrincipalAuthorization extension anchors Principal-side grant declarations and delegation policies. An authorizationConstraints container provides offline-verifiable execution boundaries (IP range, window). An extensibility framework allows vendor-specific and user- specific metadata. This document specifies the ASN.1 module, OID registration, field semantics, delegation model, and extensibility framework. Security considerations for deployment in regulated enterprise environments are discussed.", "full": true, "rev": "02", "time": "2026-10-02T06:31:58Z", "group": "individual", "pages": 52, "relevant": 0.94, "domain": "identity", "domain_conf": 0.99, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-02T12:17:34.731Z", "evaluated": "2026-10-02T12:17:34.731Z" }, { "name": "draft-skyfire-oauth-using-kyapay-tokens", "title": "Using KYAPay Tokens", "abstract": "The KYAPay Token is a JSON Web Token (JWT) that carries verified identity (\"Know Your Agent\", KYA) and payment (PAY) information for requests made by software agents on behalf of human principals. This document describes how security intermediaries -- bot managers, fraud managers, account-takeover (ATO) protection systems, and customer identity and access management (CIAM) systems -- consume KYAPay tokens to answer a question that traditional bot detection cannot: \"did a verified human authorize this agent?\", rather than \"is this a human?\". It specifies how KYAPay tokens are carried in HTTP requests, how they are validated (including in combination with request-signing layers such as HTTP Message Signatures), and how the verified, layered identity in a token is used to make access, routing, fraud detection, account-lifecycle, and step-up decisions. It defines the token-consuming \"recipient\" role that the KYAPay Token leaves unspecified. It is intentionally non-prescriptive about how tokens are created, because agent architectures, agent-identity technologies, and agent-communication protocols are diverse and still emerging; the token itself is the interoperability contract.", "full": true, "rev": "01", "time": "2026-10-02T00:44:30Z", "group": "individual", "pages": 32, "relevant": 0.82, "domain": "authz", "domain_conf": 0.76, "centrality": 1.82, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-02T06:17:33.819Z", "evaluated": "2026-10-02T06:17:33.819Z" }, { "name": "draft-nirvanai-nbtp-behavioral-trust", "title": "NirvanAI Behavioral Trust Protocol (NBTP)", "abstract": "The NirvanAI Behavioral Trust Protocol (NBTP) defines a cryptographic framework for continuous attestation of AI agent behavioral integrity in distributed networks. NBTP treats trust as a volatile, time- decaying state variable measured by an oracle-federated layer of independent scanner nodes. Unlike static credential systems that answer \"Is this agent authorized?\", NBTP answers \"Is this agent currently acting like itself?\" Identity systems confirm who sent a message. NBTP confirms whether the sender is still the entity that earned that identity. Trust computation is performed locally by each verifying party using signed attestations from independent oracle scanners; no centralized policy engine or authorization server is required at verification time. NBTP introduces a temporal decay model with context-dependent decay rates, a four-state trust machine (PROBATIONARY, TRUSTED, SUSPECT, QUARANTINED), cross-context co-silence detection, and a genesis bootstrapping mechanism (Creole gate) using formal CHALLENGE/RESPONSE packet types. Absence of attestation data is treated as a security- relevant signal. This document specifies the protocol wire format, state machine, decay model, security properties, and IANA considerations. Implementation-specific measurement heuristics are out of scope.", "full": true, "rev": "01", "time": "2026-10-01T21:24:59Z", "group": "individual", "pages": 43, "relevant": 0.93, "domain": "attestation", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-02T00:17:32.120Z", "evaluated": "2026-10-02T00:17:32.120Z" }, { "name": "draft-seymour-wimse-connected-flight", "title": "Zero Trust Fabric Layer Agent-to-Agent Chained Trust on a Connected Flight", "abstract": "The Zero Trust Fabric Layer (ZTFL) verified a single autonomous agent issuing a single request. It did not address what happens when that agent delegates its authority to a second agent, or a third, a pattern already standard in multi-agent orchestration. Existing delegation mechanisms do not close this gap. OAuth 2.0 Token Exchange represents prior actors as claims that are informational only for access control decisions. Classical logic-based and relationship-based authorization models were built for stable, long- lived principals and do not enforce a tenant boundary at the specific hop where it is crossed, nor do they bind every hop in a chain to a single expiring credential established at the chain's origin. This document extends ZTFL with a chained authorization model, structured on the mechanics of international travel. An immutable Passport establishes identity for the full journey. A Ticket, issued once at task initiation as a conditional ephemeral credential, binds every subsequent hop to the same authorized chain; a locally valid-looking Boarding Pass that cannot trace back to it is rejected regardless of appearance. A per-hop Boarding Pass, a child ephemeral token derived from and traceable to the Ticket, authorizes each leg. A Visa, an explicit and narrowly scoped grant, is required only at the moment a hop crosses a tenant boundary the Passport alone cannot cross. The model is formalized as a boundary-conditional evaluation function, implemented and validated against the Cedar policy language, and compared directly against OAuth Token Exchange, delegation logic, and relationship-based authorization on two properties none of them enforce structurally: chain-wide traceability to a single origin, and containment at the boundary itself. This revision further shows that the model's per-hop Boarding Pass structurally resists mid-chain redirection, including redirection caused by prompt injection reaching an intermediate agent, because issuing a Boarding Pass requires standing the redirected agent never holds and cannot acquire by altering its own behavior.", "full": true, "rev": "06", "time": "2026-10-01T17:08:56Z", "group": "individual", "pages": 26, "relevant": 0.83, "domain": "authz", "domain_conf": 1, "centrality": 1.89, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T18:17:57.752Z", "evaluated": "2026-10-01T18:17:57.752Z" }, { "name": "draft-das-interim-effectuation-validation", "title": "Authority Is Earned from the Real Path, Not Granted Per Session: Receipt-Gated Interim Effectuation Validation for AI Agents, Frontier AI Model Providers, and Autonomous Systems", "abstract": "Authority to cause a real-world effect should not be granted for a whole session; it should be earned, one bounded step at a time, from the real path itself. This document specifies an experimental architecture for controlling consequential external effects produced by agentic, autonomous, and conventional computing systems, and is addressed in particular to operators of AI machines and to frontier AI model providers. It separates a proposed act from authority to make that act effective, permits a real bounded effect to occur, obtains protected evidence of what actually occurred, independently evaluates that evidence in an Interim Effectuation Validator (IEV), and makes a later effect technically dependent on a protected continuation condition. The validator does not relay the original command, and if trustworthy evidence is missing the system holds or quarantines the act instead of retrying it. The architecture supports single-phase, two-phase, and multi-phase operation; human, automatic, and hybrid escalation; crash and indeterminate-state reconciliation; validator-integrity hardening; conflicting-evidence handling; effectuation-time revocation; taint and provenance propagation; privilege-separated credential surrogation; and software, hardware, virtual-machine, operating-system, destination- native, quorum, and tokenless realizations. The document defines an abstract protocol and conformance model rather than one mandatory transport or serialization. It also specifies implementation-invariance rules so that changing component placement, token representation, operating system, proxy topology, validator location, or credential representation does not by itself change the functional sequence when the required security properties are preserved. Patent pending: the concept described in this document is the subject of Indian Patent Office application number 202631117633, \"Systems and Methods for Cryptographically Staged Effectuation with Verified Partial Effect, Receipt-Bound Full Effectuation, and Software- Hardware Enforcement\".", "rev": "00", "time": "2026-10-01T08:04:49Z", "group": "individual", "pages": 206, "relevant": 0.83, "domain": "authz", "domain_conf": 0.58, "centrality": 1.26, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:21.553Z", "evaluated": "2026-10-01T10:59:21.553Z", "full": true }, { "name": "draft-das-receipt-gated-iev", "title": "Evidence Is the Key, Not the Log: Receipt-Gated Staged Effectuation and Interim Effectuation Validation for AI Agents, Frontier AI Model Providers, and Autonomous Systems", "abstract": "Authority to cause a real-world effect should not exist on a machine until the real path has shown that it is safe. This document describes an experimental execution-control architecture for agentic, autonomous, and conventional computing systems, and is addressed in particular to operators of AI machines and to frontier AI model providers. A proposed act is separated from authority to make the act consequential. The architecture supports single-phase protected effectuation, a bounded real first effect followed by receipt-gated continuation, and arbitrary multi-phase progression. In the Interim Effectuation Validator (IEV) profile, protected evidence of an earlier real effect is not a log but a structural dependency: it is independently evaluated before a protected continuation condition for a later effect is established, and the validator does not relay the original command. If trustworthy evidence is missing, the system holds or quarantines the act instead of retrying it. The document also describes taint and provenance propagation, protected origin attribution, surrogate or non-exportable credential references, boundary credential resolution, privilege-separated connector execution, human and automatic remediation, crash and indeterminate-state reconciliation, anti-bypass requirements, tokenless and cryptographic continuation, and software, virtual- machine, operating-system, mobile, application, network, transaction, hardware, destination-side, and distributed realizations. The architecture is defined by functional relationships rather than by a particular product name, operating system, validator placement, token format, proxy, or credential representation. Patent pending: the concept described in this document is the subject of Indian Patent Office application number 202631117633, \"Systems and Methods for Cryptographically Staged Effectuation with Verified Partial Effect, Receipt-Bound Full Effectuation, and Software- Hardware Enforcement\".", "rev": "00", "time": "2026-10-01T08:04:12Z", "group": "individual", "pages": 214, "relevant": 0.8, "domain": "attestation", "domain_conf": 0.45, "centrality": 1.19, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:21.553Z", "evaluated": "2026-10-01T10:59:21.553Z", "full": true }, { "name": "draft-das-safety-first-execution-finality", "title": "A Permit to Effect Once Is Not a Permit to Effect Permanently: Reality as a Cryptographic Dependency for AI Machines, Frontier AI Model Providers, and Critical Systems", "abstract": "A permit to effect once is not a permit to effect permanently. An approval, a policy decision, or one successful effect is not standing authority for a larger or repeated one. For AI machines and frontier AI models that can now act in the world, this separates a contained mistake from an irreversible one. Today, security checks who is asking, inspects a token, opens the gate, and hopes that the downstream network path, destination, or physical machine is safe. AI agents now send messages and files, move money, change production infrastructure, invoke tools, update model and memory state, release sensitive data, and drive vehicles, robots, and industrial equipment. Approval can show that an action was allowed in principle without showing that the exact action reaches the right recipient, device, or outcome. Simulations and dry-runs do not close this gap, because a simulation can pass in a clean sandbox while the real target, route, or actuator has been hijacked. Logs do not close it either, because a log explains a disaster after it has happened. This document makes reality a cryptographic dependency. The full- consequence command is held in a state that cannot execute. First, a deliberately bounded real effect is produced on the exact operational path: a trailing capsule, one record, a payment hold, a canary deployment, a constrained session, or a millimetre of actuator movement. The destination, transaction system, network element, sensor, or hardware controller then returns an Effect Confirmation Receipt. An Interim Effectuation Validator validates that receipt out of band against the intended act, nonces, epoch, scope, destination, current policy, and revocation state. Only then does it issue the continuation instruction that reconstructs the key, releases the split credential, or unlocks the hardware register for the next phase. Without the receipt, the key for full effect does not exist on the machine. Evidence is therefore a structural dependency and not a log. Two properties are central. First, the validator never relays the original command: the micro-effect proceeds independently and the validator observes the proof from a distance, so compromising an inline proxy or manipulating routing through prompt injection does not hand over the keys. Second, uncertainty is a first-class state. If a micro-effect fires but trustworthy evidence is missing, the system quarantines and refuses progression instead of retrying, so an autonomous loop cannot compound a duplicate transfer, a double commit, or an over-actuation. These properties hold under stated assumptions, including receipt integrity, path completeness, and atomic consumption of continuation authority, which the document identifies. The architecture covers single-phase and multi-phase execution; human, automatic, hybrid, threshold, and hardware-rooted approval; anti-replay and anti-substitution controls; alternate-path closure; reconciliation of indeterminate outcomes; and rollback, compensation, and safe-state handling. It consolidates thirty-five workflow profiles across communications, files, payments, databases, cloud and model deployment, AI tool invocation, data export, robotics, vehicles, UAVs, industrial control, radio and satellite systems, GPU and accelerator egress, and software and firmware activation. The Safety-First Critical-System Profile applies where avoiding catastrophic or hard-to-reverse outcomes comes before minimum latency: a deployment MUST NOT remove a validation, receipt, anti- replay, or safe-state protection merely to be faster, when protected policy classifies it as necessary for the consequence class.", "rev": "00", "time": "2026-10-01T08:00:19Z", "group": "individual", "pages": 599, "relevant": 0.88, "domain": "attestation", "domain_conf": 0.42, "centrality": 1.31, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:21.553Z", "evaluated": "2026-10-01T10:59:21.553Z", "full": true }, { "name": "draft-westerbeck-reason-protocol", "title": "reason:// -- A URI Scheme and Registry Protocol for Validated Agent Reasoning Artifacts", "abstract": "This document defines the \"reason://\" URI scheme and associated registry protocol for naming, storing, and retrieving compressed structural reasoning artifacts across distributed autonomous agent networks. An artifact enters the registry only by winning a live competitive arbitration round scored by the Web Agent Reasoning Federation (WARF) protocol. The artifact schema contains no raw data fields; the structural representation is mathematically non- invertible (empirical reconstruction rate r = 0.0149). The protocol is designed to function as open infrastructure — analogous to DNS for network addresses or HTTP for document retrieval — for the agentic internet.", "rev": "00", "time": "2026-10-01T07:09:07Z", "group": "individual", "pages": 11, "relevant": 0.85, "domain": "discovery", "domain_conf": 0.61, "centrality": 1.98, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-krausz-verification-state", "title": "The verification.* Constraint Family: Pre-Action Fail-Closed Gates for AI Agent Decisions", "abstract": "This document specifies the verification.* constraint family --- a pre-action, fail-closed gate primitive for AI agent decisions, sibling in shape to the environment.* family used in Verifiable Intent specifications. A verification.* receipt is a JSON Web Signature (JWS) signed artifact carrying a canonical input, a derived binary act/halt output, and a versioned mapping identifier that binds them. A relying party recomputes the gate locally from signed primitives under the named mapping; the verifier never trusts the issuer's runtime. This revision replaces the raw verdict domain of draft-krausz- verification-state-01 (supported/refuted/unverifiable/unknown) with a four-state vocabulary --- verified, contradicted, indeterminate, and not_evaluated --- together with a reason-code mechanism that separates a state's substance from a verifier's own instrument failure, and with an admissibility gate applied before a state is ever assigned. It adds evidence pinning: a receipt MAY carry an evidence_set block that content-addresses the sources considered during verification, so that a verdict can be recomputed offline from the receipt and the pinned bytes alone, without depending on a live retrieval provider. Freshness is anchored to the evidence's own retrieved_at timestamp rather than a separately declared validity window. This shape provides decision explainability and traceability evidence aligned with EU AI Act Article 12 record-keeping obligations and with the Decision Explainability tier of an industry Zero Trust for AI Agents framework published in 2026. The format is forward- compatible across mapping revisions: receipts signed under one mapping ID remain verifiable as correct-under-that-mapping after newer mappings ship. The vectors that content-address a mapping document or an evidence set are historical, digest-anchored artifacts and are unchanged by this revision; nothing in this document alters a previously issued digest.", "rev": "03", "time": "2026-10-01T00:58:29Z", "group": "individual", "pages": 45, "relevant": 0.91, "domain": "attestation", "domain_conf": 1, "centrality": 1.84, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-morrison-org-alter-policy-provision", "title": "Policy Provision and Governance Inheritance from an Organisational Identity Substrate", "abstract": "This memo specifies how an artificial-intelligence agent runtime, bound at instantiation to a principal identity handle, resolves at session initialisation a target organisational identity substrate from a manifest source bound to the runtime's working context and retrieves from that substrate a typed policy stack comprising a handbook artefact, a standard-operating-procedure registry pointer, an enforcement-gate specification, and an audit-signal ingestion endpoint. The policy stack is then applied as runtime constraints on subsequent tool invocations, with audit signals emitted back to the same substrate. Policy provision occurs in the same act of session initialisation as principal identification, rather than as a separate ceremony against a side-channel governance plane. A principal concurrently bound to multiple organisational substrates operates the runtime under a deterministic composition of the several policy stacks, with cross-organisational residual conflicts routed to the peer-protocol Identity Accord ceremony rather than to a meta- federation authority. The memo is Informational. The wire surface relies on the DNS-based discovery of draft-morrison-mcp-dns-discovery and the handle namespace of draft-morrison-identity-pronouns; no new transport is introduced.", "rev": "04", "time": "2026-09-30T09:27:05Z", "group": "individual", "pages": 22, "relevant": 0.89, "domain": "authz", "domain_conf": 0.4, "centrality": 1.95, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-morrison-binding-moment-envelope", "title": "The Briefing-and-Binding Envelope: A Delivery Contract for Agent-to-Principal Decision Moments with Dual-Veto Reconciliation", "abstract": "This memo specifies the briefing-and-binding envelope: a delivery contract for the wire-level structure by which an artificial- intelligence agent surfaces a consequential decision to the human principal it acts for, and by which the principal commits, declines, amends, or rejects that decision. The envelope carries eight named slots (a synopsis, findings, recommendations, an offer of detail, a question stem, a set of options each marked with its own reasoning, a single recommended option, and a pair of escape hatches) and is emitted as a structured field of a Model Context Protocol tool result. The contribution is the delivery contract itself: a single renderer-agnostic envelope so that the briefing an agent delivers and the binding a principal commits back have one machine-checkable shape across every consuming surface. The central element is the dual-veto handshake: one escape hatch lets the principal revise the answer space while accepting the question; the other lets the principal reject the question itself and reopen deliberation. Either party may veto. The memo defines a content digest over the envelope, canonicalized under JCS and hashed with SHA-256, so that a resolution names the exact envelope it resolves and an external receipt can reference that envelope by digest. The memo is Informational. No new transport is introduced; the envelope composes with the handle namespace of draft-morrison-identity-pronouns and the MCP tool surface of draft-morrison-org-alter-policy-provision.", "rev": "03", "time": "2026-09-30T09:26:00Z", "group": "individual", "pages": 24, "relevant": 0.86, "domain": "protocols", "domain_conf": 0.91, "centrality": 1.97, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-mo-cats-agent-selection-mapping", "title": "A Selection Mapping Framework for AI Agent Services in Computing-Aware Traffic Steering", "abstract": "The Computing-Aware Traffic Steering (CATS) framework selects a service contact instance for a service request by combining computing and network metrics that are distributed by CATS Service Metric Agents and CATS Network Metric Agents. For AI agent services, the request that arrives at the network is not a single unit of work: it is a session that expands into multiple steps, each of which may require a different capability, a different state, and a different path. This document describes a mapping framework that turns the characteristics of an agent step into (1) a set of hard constraints and (2) a per-dimension valuation over a three-dimensional resource view composed of forwarding, computing, and storage, and that feeds the resulting suitability of each candidate service contact instance into the existing CATS selection function. The framework introduces no new functional component.", "rev": "00", "time": "2026-09-30T03:23:06Z", "group": "individual", "pages": 45, "relevant": 0.69, "domain": "netmgmt", "domain_conf": 0.77, "centrality": 1.63, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-rosenberg-vcon-redaction", "title": "Use Cases and Requirements for Redaction in VCON", "abstract": "The Virtualized Conversations (VCON) specification defines a standardized object format for representing multimedia conversations between users and AI agents. Recent work has expanded VCON to enable it to been used to capture sessions with AI Agents as well, including tool calls, reasoning steps, model configuration and more. This has also expanded the set of use cases and requirements for redaction of sensitive information from a VCON. This document outlines use cases and requirements for redaction in VCONs. This document is meant for discusssion purposes. All of this document was written by the author and not by an LLM.", "rev": "00", "time": "2026-09-29T20:30:13Z", "group": "individual", "pages": 12, "relevant": 0.71, "domain": "other", "domain_conf": 0.79, "centrality": 1.13, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-anandakrishnan-rats-ptv-agent-identity", "title": "The Prove-Transform-Verify (PTV) Protocol for Attested Agent Identity", "abstract": "This document describes the Prove-Transform-Verify (PTV) protocol for hardware-anchored attestation of AI agent identity. PTV enables an agent to prove, at exercise time, that it is bound to an enrolled attestation key and an authorized configuration, without exposing model weights or inference inputs. PTV is a thin request/response profile over the RATS architecture (RFC 9334) and the Entity Attestation Token (RFC 9711). It does not replace workload identifiers such as SPIFFE or WIMSE. It does not attest behavioral continuity; behavioral continuity is a separate requirement class that relying parties need to treat as such. This revision is intended as Experimental. It defines a common CBOR/ CDDL message set, four message types, a COSE-based message protection rule, an informative EAT claim mapping, and a threat model that separates identity binding integrity from behavioral continuity.", "rev": "01", "time": "2026-09-29T15:23:25Z", "group": "individual", "pages": 23, "relevant": 0.92, "domain": "attestation", "domain_conf": 0.9, "centrality": 1.92, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-agentic-ai-tool-execution-finality", "title": "Execution Finality for Agentic AI: Stopping Unauthorized Tool Calls, Memory Writes, and Real-World Consequences Before They Happen (DAS -- Decoupled Authorisation System)", "abstract": "Agentic AI systems now call tools, write memory, move money, change infrastructure, and trigger physical actions. Most safety layers still decide permission upstream and then trust the downstream path. Once that path is compromised, or once the approved request is widened, replayed, or substituted, the act becomes real before any audit can stop it. This document specifies a protected execution-finality architecture of the Decoupled Authorisation System (DAS). It is built on four mechanisms: (1) two-instance binding that separates collection-time evidence from execution-time validation, (2) mutually load-bearing, cross-committed protected evidence so that no single artifact authorizes effectuation, (3) scoped non-bearer finality authority whose possession alone is never enough, and (4) independent Finality Sink reconstruction that re-derives the actual pending operation at the effectuation boundary and permits the act only when every required condition still matches. A Candidate Act remains in a Non-Effective State until the Finality Sink has reconstructed the operation, verified the protected evidence against sink-local monotonic state, and advanced that state. Failure at any step produces fail-closed denial before effectuation rather than post-event remediation. The architecture is applicable to agentic tool use, MCP and connector frameworks, RAG and vector-memory systems, cloud control planes, financial settlement, telecom routing, and cyber-physical control. The document elaborates the problem space, compares the approach with representative existing techniques, presents the detailed solution and its advantages, supplies JSON Schema definitions for core protected objects, and includes an industry-relevance section. Related Indian provisional applications and PCT filings appear in the final appendix.", "rev": "00", "time": "2026-09-29T14:43:35Z", "group": "individual", "pages": 30, "relevant": 0.79, "domain": "authz", "domain_conf": 0.93, "centrality": 1.91, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-das-ot-actuation-finality", "title": "A Setpoint Write Is Not Actuation: Finality for ICS, Grid, and Robot Command", "abstract": "Industrial systems already know how to move a breaker, a valve, a robot joint, or a turbine setpoint. They do not know whether this write — this tag, this value, this device, from this operator session or this agent — is the write that was authorized to become motion. A signed OPC UA call, a valid DNP3 control, an IEC 61850 command, or an MQTT publish onto the plant bus can all be protocol-correct while the act is wrong. The protocol authenticates a channel. It does not bind a Candidate Act at the actuation sink. That gap is now an agent gap. Copilots sit on historians and work- order text. They propose \"explain this alarm\" and then \"set this point.\" If the gateway treats a well-formed write as authority, reconstruction of plant state becomes physical consequence. Past incidents stole engineering workstations. Present incidents steal the jump host or the agent seat. Future incidents let the model format the command. This document specifies an OT-side execution-finality profile. A write remains an Actuation Candidate Act. A Protected Enforcement Domain binds principal, zone, device, tag, value envelope, mode (local/remote, auto/manual), safety interlock state, policy epoch, and intended actuation sink, then commits evidence before scoped non- bearer authority is issued. The sink that would actually drive I/O verifies that authority against the live write and consumes it. A setpoint write is not actuation.", "rev": "00", "time": "2026-09-29T14:43:26Z", "group": "individual", "pages": 21, "relevant": 0.87, "domain": "authz", "domain_conf": 0.96, "centrality": 1, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-das-global-privacy-execution-enforcement", "title": "Technical Enforcement of the European GDPR and Global Data-Protection Constraints Without Paper Policy", "abstract": "The European Union's General Data Protection Regulation (GDPR), China's Personal Information Protection Law (PIPL), and India's Digital Personal Data Protection Act (DPDP Act) each require, in their own terms, that personal data be used only for a specified purpose, be limited to what is necessary, be kept secure, and remain subject to the data subject's or regulator's ability to hold a controller accountable. Every one of these regimes is currently enforced primarily through paper: privacy notices, consent records, data-processing agreements, internal policies, access-control configurations, and audits performed after data has already moved. Paper policy fails in the age of artificial intelligence because it assumes a human-speed decision that no longer exists. An agentic AI system can authenticate, read from several lawfully accessible data sources, combine those sources into a new relationship that was never separately assessed, choose a purpose, select a recipient or an international destination, and transmit the result -- all within a single inference pass, before any privacy officer, consent record, contract clause, or after-the-fact audit log can intervene. A GDPR purpose-limitation clause, a PIPL processing-purpose restriction, or a DPDP consent-manager rule can be entirely correct on paper and still fail in practice, because none of them is a property of the computation itself; each is a property of a document that the computation is merely expected to obey. By the time an audit trail shows that Article 5(1)(b) of the GDPR, the purpose-limitation principle of the PIPL, or the purpose-limitation requirement of the DPDP Act was violated, the disclosure, the cross-border transfer, or the unauthorized combination of data has already occurred and cannot be undone. This document introduces an execution-finality architecture that converts an already-determined privacy rule from a document into a mandatory, machine-verifiable precondition of the computer operation itself. A proposed privacy-sensitive operation is represented as a Candidate Act and is held in a Non-Effective State -- technically incapable of disclosing, transmitting, or combining protected data -- until a Protected Enforcement Domain conjunctively validates the requesting Virtual Identity (VI), the applicable purpose and jurisdictional constraints represented as a Compliance Jurisdiction Token or Structure (CJT/CJS), the minimum required data attributes, the recipient, and the destination, and a Finality Sink positioned at the boundary of first usable external effect independently reverifies that state immediately before release. Non-Joinable Vaults further ensure that holding a valid credential or an authenticated AI session does not, by itself, grant authority to recombine separated categories of personal data. A worked example applies the architecture to a small-or-medium enterprise (SME) AI customer-service deployment, including a prompt- injection scenario in which a manipulated AI agent is technically prevented from exfiltrating payment and identity data regardless of what the model was tricked into generating. A feasibility and latency analysis shows the mechanism can be deployed as ordinary gateway middleware without replacing existing identity or SaaS infrastructure. The document then provides a deliberately bounded mapping onto specific GDPR provisions (Articles 5(1)(b), 5(1)(c), 5(1)(f), 6, 25, 32, and Chapter V), stating plainly which provisions this architecture can make technically load-bearing and which -- such as the legal validity of a basis for processing, or the lawfulness of an international transfer mechanism -- must remain a legal and regulatory determination that no software can make on its own. This document does not advocate discarding paper-based privacy policy, consent management, contractual controls, or audit for general-purpose applications, where the cost, rigidity, and operational overhead of execution-level enforcement would be", "rev": "00", "time": "2026-09-29T14:43:14Z", "group": "individual", "pages": 90, "relevant": 0.79, "domain": "authz", "domain_conf": 0.9, "centrality": 1.26, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-das-ai-native-6g-execution-finality", "title": "Execution-Finality for AI-Native 5G/6G and O-RAN", "abstract": "In programmable and AI-assisted mobile networks, successful authentication of a network function or AI controller does not establish authority for every routing, signaling, session, resource- allocation, sensing, or subscriber-specific consequence that the function can generate. This document defines an informational execution-finality profile for AI-native 5G, 5G-Advanced, IMT-2030/6G, O-RAN, and AI-RAN environments. A proposed network operation is represented as a Network Candidate Act and remains in a Non-Effective State while a Protected Enforcement Domain validates act-specific predicates. Protected validation evidence is committed before, or atomically with, release of scoped non-bearer finality authority. A Network Finality Sink at the enforcement boundary independently verifies that authority immediately before live network state changes. The governing rule is that network authentication is not network finality, and computation is not authority. This revision also defines a JSON interoperability profile for Candidate Acts, validation decisions, scoped authority, and sink verification. This profile is distinct from, and complementary to, present AI- native 6G industry roadmaps that focus on radio, sensing, and platform capability, including air-interface, MIMO, spectrum, and AI- RAN infrastructure work described in Qualcomm's public AI-native 6G platform material, and the broad native-trustworthiness and agentic- core-network architectures described in Huawei's public 6G security research. Those efforts address how a network becomes more intelligent, autonomous, and platform-trustworthy. This document addresses a narrower and later question: once an already- authenticated, already-policy-approved AI-generated network operation has been computed, whether that exact operation may become a live network consequence. The Candidate Act, Non-Effective State, Protected Enforcement Domain, and Finality Sink constructs defined here, as an explicit pre-effectuation gate with act-bound non-bearer authority and independent sink-side re-verification, are not established as an equivalent primitive in publicly reviewed material from those roadmaps.", "rev": "03", "time": "2026-09-29T14:42:34Z", "group": "individual", "pages": 59, "relevant": 0.89, "domain": "authz", "domain_conf": 0.68, "centrality": 1.22, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-das-payment-execution-finality", "title": "A Signed Instruction Is Not Settlement: Finality for Agentic and API Payments", "abstract": "Payment rails already know how to move money. They do not know whether this generated instruction — this amount, this beneficiary, this rail, this purpose, from this agent or API worker — is the instruction that was authorized to move. A signed ISO 20022 message, an OAuth token on a PSP, a stored mandate, or a pass through 3-D Secure can all be valid while the act is wrong. The signature authenticates a channel. It does not bind a Candidate Act at the settlement sink. That gap is now an agent gap. A model that can call payout.create, a RPA job that submits ACH, or a checkout agent that captures a card will treat tool selection as settlement authority. Fraud used to steal credentials and replay files. It now steals a seat or injects a document and asks the authorized worker to pay a new beneficiary at the old amount, or the old beneficiary at a new amount. This document specifies a payment-side execution-finality profile. An instruction remains a Payment Candidate Act. A Protected Enforcement Domain binds principal, wallet or account, amount, currency, beneficiary, rail, purpose, policy epoch, and intended settlement sink, then commits evidence before scoped non-bearer authority is issued. The sink that would actually post, capture, or release funds verifies that authority against the live instruction and consumes it. A signed instruction is not settlement.", "rev": "01", "time": "2026-09-29T14:42:18Z", "group": "individual", "pages": 42, "relevant": 0.88, "domain": "authz", "domain_conf": 0.96, "centrality": 1.39, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-das-execution-finality-protocol-layer", "title": "The Missing Protocol Layer for the Agentic Internet: Computation Is Not Authority", "abstract": "TLS tells you the channel is authentic. OAuth tells you the caller holds a valid grant. HTTPS tells you the origin is who it claims to be. EMV tells you a payment cryptogram is transaction-specific. None of these mechanisms answer a question that autonomous, machine- speed systems now raise on every turn: is _this specific act_, generated by _this_ model, agent, or workload, at _this_ moment, actually authorized to become externally effective? Large language model agents, autonomous cloud workloads, and machine- to-machine network functions increasingly compute, decide, and act inside a single event loop, at latencies where no human, log reviewer, or downstream audit process can intervene before an API call fires, a payment settles, a file leaves the enterprise boundary, or a physical actuator moves. Transport, authentication, and authorization protocols were designed for a world in which the gap between \"this request was generated\" and \"this request had a chance to be reviewed\" was measured in human-relevant time. That gap has collapsed to milliseconds. Existing protocol layers were never built to close it, because the question they answer -- identity, channel integrity, delegated scope -- is a necessary but categorically different question from whether _this act, right now, should be allowed to leave computation and become consequence_. This document specifies an architectural pattern, execution finality, that treats every machine-generated operation as a Candidate Act held in a Non-Effective State until a Protected Enforcement Domain validates act-specific authority -- purpose, destination, jurisdiction, freshness, revocation state, policy epoch, and runtime integrity -- and issues a narrowly scoped, non-bearer Execution Handle bound to that act and to a specific Finality Sink, the first boundary at which the act would otherwise become externally effective. The document formalizes the vocabulary, a cold-path/hot- path split for latency-sensitive deployment, a structured threat model with adversary-facing pseudocode, an incremental migration path for coexistence with TLS, HTTPS, OAuth, and EMV rather than replacement of them, and worked examples spanning AI agents, payments, telecommunications, cloud infrastructure, satellite command, industrial control, and robotics. The central claim is narrow and falsifiable: _computation does not itself confer authority for consequence_, and no general, cross- domain Internet layer currently makes that separation a structural property of the release path rather than an application-specific convention. This document is intended to solicit IETF community review of whether that gap is real, whether it is already covered by existing or in-progress work, and if not, which venue should take it up. This document describes a patent-pending architectural concept. Any intellectual-property rights or disclosure obligations relating to implementation are outside the technical scope of this document and are subject to applicable IETF IPR procedures, including BCP 79.", "rev": "01", "time": "2026-09-29T14:41:58Z", "group": "individual", "pages": 75, "relevant": 0.92, "domain": "authz", "domain_conf": 0.9, "centrality": 1.04, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-das-eu-ai-act-execution-enforcement", "title": "Technical Enforcement of the EU AI Act and Global AI Laws for High-Risk AI Systems Without Relying on Paper Policies", "abstract": "This architecture is specifically designed for high-risk AI systems, where standard engineering priorities shift from speed and latency toward absolute determinism and safety. The European Union Artificial Intelligence Act establishes an extensive paper-based governance regime for artificial intelligence: risk-management documentation, data-governance records, conformity assessments, human-oversight instructions, transparency notices, logging obligations, and post-market monitoring plans. These instruments are necessary, and this document does not propose to discard them. They are not, however, sufficient by themselves once an AI system can autonomously or semi-autonomously act at machine speed, because a document can only describe what an operation should do; it cannot, by itself, make an operation technically incapable of doing otherwise. This is not a problem unique to the European Union. South Korea's AI Basic Act regulates \"high-impact AI\" through comparable risk- management, human-oversight, and documentation duties. Japan's AI Act, in force since September 2025, takes a lighter, more promotion- oriented approach but still assumes that written governance is the primary control. China enforces a binding but differently structured set of algorithm-recommendation, deep-synthesis, generative-AI, and AI-content-labelling rules. Texas and Colorado have each enacted state-level AI statutes in the United States with disclosure and consequential-decision obligations, and Brazil's PL 2338/2023 and Canada's lapsed AIDA proposal show the same EU-style risk-based model spreading, whether or not yet enacted. Every one of these regimes, whatever their legal differences, shares the identical underlying engineering gap this document addresses: a written rule, however well drafted, does not by itself make a machine unable to break it before anyone can react. The gap is most consequential precisely where the stakes are highest. In defence-relevant AI, critical-infrastructure control systems, and satellite or space-system automation, an autonomous agent can select a target, reroute power or water, transfer control of a physical asset, or transmit a command to an orbital platform within a single inference cycle -- before any operator, reviewer, regulator, or after-the-fact investigation can intervene. If that act causes harm, two questions follow immediately: who is liable, and at what cost. A risk-management file, a conformity-assessment certificate, or an audit log written after the fact can show that a rule existed; none of them can show that the machine was technically incapable of breaking it, and none of them limits the cost already incurred by the time the record is examined. For these classes of system, the appropriate default when an authorization cannot be verified is not \"log it and investigate later\"; it is fail-closed: the act simply does not occur. This document describes an execution-finality architecture that converts a selected, already-determined AI-governance requirement from a document into a mandatory, machine-verifiable precondition of the AI-generated operation itself. A consequential AI-generated operation is first represented as a Candidate Act and is held in a Non-Effective State -- technically incapable of invoking a tool, actuating a device, transmitting a command, or otherwise causing an external consequence -- until a Protected Enforcement Domain validates the machine-readable constraints applicable to that exact act, including the AI system identity, permitted operation, target, recipient, destination, required human-oversight state, transparency marker, risk-control status, policy epoch, and revocation state. Successful validation produces narrowly scoped, act-bound effectuation authority; a Finality Sink positioned at the point of first usable external effect independently re-verifies that exact authority, and the current required state, immediately before the consequence is permitted to occur. Absent, stale,", "rev": "02", "time": "2026-09-29T14:40:55Z", "group": "individual", "pages": 112, "relevant": 0.85, "domain": "authz", "domain_conf": 0.95, "centrality": 1.94, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-das-agentic-execution-finality", "title": "Tool Selection Is Not Execution: Finality for Agentic Tool Dispatch in High-Risk AI Systems", "abstract": "This architecture is specifically designed for high-risk AI systems, where standard engineering priorities shift from speed and latency toward absolute determinism and safety. An agentic model can emit a tool call that today's runtimes treat as something to execute. Allowlists, OAuth tokens, MCP server auth, sandboxes, output filters, and human approval decide whether an agent may reach a tool. They do not decide whether this generated call, with this argument digest, from this instruction chain, at this delegation depth, may take effect now. That gap is the incident surface. Prompt-injected content, poisoned retrieval, a malicious tool response, or a delegated sub-agent can produce a call that looks like ordinary tool use. If the dispatcher executes whatever the model selected, policy that lived upstream becomes advisory. This document specifies a dispatch-time gate. The model may compute a call. The call remains a Candidate Act. A Protected Enforcement Domain binds agent, tool, arguments, purpose, destination, provenance, and policy epochs, then issues scoped non-bearer authority. A Tool-Dispatch Finality Sink verifies that authority against the actual invocation immediately before the tool runs, then consumes it. The same gate applies to support, coding, payments, clinical, SOC, browser-use, and multi-agent MCP deployments. Tool selection is not execution authority. A runnable reference implementation for this dispatch-time gate is provided at tool_use Is Not invoke(): Binding Execution-Finality to Agentic Tool-Call Interfaces and MCP (https://github.com/sangmdas/ tool_use-Is-Not-invoke-Binding-Execution-Finality-to-Agentic-Tool- Call-Interfaces-and-MCP).", "rev": "02", "time": "2026-09-29T14:40:40Z", "group": "individual", "pages": 25, "relevant": 0.86, "domain": "authz", "domain_conf": 0.99, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-das-rats-attestation-bnd-execution-finality", "title": "Attestation-Bound Execution Finality for GPU, AI Accelerator, DPU, SmartNIC, and Confidential-Computing Infrastructure", "abstract": "Remote attestation can establish that a CPU, confidential virtual machine, GPU, AI accelerator, DPU, or SmartNIC is running expected firmware and software in an expected configuration. However, an acceptable Attestation Result describes the execution environment, not the operations it later emits; it remains the same whether subsequent workload outputs arise from expected logic, prompt injection, or model error. As AI workloads become agentic and move onto confidential accelerator infrastructure, they emit high- consequence operations, such as financial transfers, cloud-control mutations, database deletions, and external API invocations, where platform trustworthiness alone cannot determine whether a concrete operation is authorized to take effect. OAuth access tokens, transaction tokens, and workload credentials do not close this gap on their own: they typically authorize by scope and by possession of a credential rather than by the exact content of one operation, and they do not require that the protected effect be unreachable except through a verifying boundary. This document describes an attestation-bound execution-finality architecture that bridges platform appraisal and consequence-bearing authorization. A consequential operation originates in a non- effective state as a Candidate Act. An Execution-Finality Validator evaluates the act's security-relevant arguments together with the platform's Attestation Result, workload identity, and policy, and issues an act-bound, single-use, non-bearer Execution Handle. A Finality Sink verifies that handle at the non-bypassable boundary where the operation would first acquire external effect, so that an authorized act cannot be swapped, mutated, or replayed. The architecture requires no changes to silicon, microcode, firmware, drivers, or accelerator programming models, and it separates concerns: platforms such as NVIDIA confidential-computing GPUs and BlueField DPUs, Arm Confidential Compute Architecture (CCA), AMD SEV- SNP, and Intel TDX supply environment appraisal on the cold path, while enforcement is placed at the gateway, service-mesh, DPU or SmartNIC, network, or storage boundary. On the hot path, verification uses local cryptographic bindings and single-use checks rather than repeated attestation round trips. The document discusses its relationship to RATS, WIMSE, OAuth, and related IETF work, and its engineering FAQ addresses platform layering, DPU visibility under end-to-end encryption, tail latency, and other anticipated critical questions. It is intentionally long because it is explanatory rather than a protocol specification. The architecture is implemented, not only described. An executable reference implementation (GitHub: reference implementation, tests, benchmarks, and deployment materials, https://github.com/sangmdas/ Execution-Finality-for-GPU-AI-Accelerators-and-Confidential- Workloads) demonstrates act binding, single-use enforcement, and replay rejection in running code. It uses a software-only attester; it has not been run on any vendor's confidential-computing hardware and does not consume any vendor-issued attestation token, and vendor platforms are discussed on the basis of public documentation only. This document is vendor-neutral, neither claims nor implies review, adoption, endorsement, or affiliation by any named vendor, and complements rather than replaces existing attestation, workload- identity, and authorization mechanisms.", "rev": "04", "time": "2026-09-29T14:40:27Z", "group": "individual", "pages": 114, "relevant": 0.91, "domain": "attestation", "domain_conf": 0.94, "centrality": 1.02, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-das-execution-finality-enforcement-profiles", "title": "Execution Finality at External-Effect Boundaries: Enforcement Profiles for 6G, AI-Native RAN, RF, ISAC, Accelerated Compute, Devices, and Autonomous Systems", "abstract": "AI-native and autonomous infrastructure is increasingly able to generate, optimize, schedule, route, transmit, disclose, render, allocate, encrypt, modify network state, control radio resources, and initiate physical or machine actions without a human decision at every step. An agentic AI system may generate a tool call or machine instruction; an AI-native RAN may compute a beam, handover, power, spectrum, routing, slicing, or topology change; an integrated sensing and communication (ISAC) system may generate sensing information for release or fusion; an O-RAN xApp or rApp may generate a network- control instruction; an accelerator may produce a routing, scheduling, inference, or resource-allocation result; or an autonomous controller may prepare a cyber-physical actuation. Successful computation, authentication, attestation, access authorization, credential possession, or execution inside a trusted environment does not, by itself, establish authority for the resulting operation to become externally effective. This document describes a protected execution-finality architecture in which that distinction is machine-enforced. A proposed consequential operation is represented as a Candidate Act and remains in a Non-Effective State while a Protected Enforcement Domain establishes a machine-verifiable act descriptor, validates applicable machine-verifiable authority predicates, and performs, consumes, advances, or references applicable protected state. The resulting state is represented by an applicable protected-state representation, and Protected Validation Evidence is committed before, or atomically with, authorization of availability of a scoped non-bearer capability. The capability is machine-verifiably or cryptographically bound to the specific Candidate Act, the act descriptor or its digest, the committed validation evidence, applicable protected state, freshness constraints, permitted effectuation scope, the relevant execution-finality boundary, and the applicable Finality Sink. The Finality Sink is positioned at or before the point at which the Candidate Act would first acquire an externally meaningful consequence. Before effectuation, the Finality Sink performs a machine-enforced capability-validity check and permits the Candidate Act to cross the execution-finality boundary only when the required bindings, protected state, validation evidence, freshness conditions, and effectuation scope remain valid. Absence, expiry, revocation, exhaustion, replay, staleness, mismatch, timeout, unverifiability, indeterminacy, scope failure, binding failure, or failure of a required preceding protected operation causes the architecture to fail closed, leaving the Candidate Act non-effective. The document provides 132 detailed Enforcement Profiles that instantiate this common architecture at materially different consequence boundaries. The profiles cover agentic AI tool calls and machine instructions; AI-native RAN and RF control; integrated sensing and communication (ISAC); sensing-result, location, telemetry, and metadata release; restricted-content delivery, decryption, decoding, recommendation, and rendering; derivative, transformed, synthetic, and AI-modified content; VPN, proxy, encrypted-DNS, encrypted-session, and tunnel establishment; cyber- physical, robotic, vehicle, industrial, and actuator control; network exposure, CAPIF, northbound APIs, and operator-controlled capabilities; distributed, edge, joint communication-compute, and in- network compute; shared AI-RAN accelerators and deterministic resource isolation; O-RAN xApp, rApp, A1, E2, and O1 control paths; cloud-native and virtualized RAN; network slicing, routing, topology, service-function-chain, and autonomous-network operations; ambient, passive, batteryless, backscatter, and zero-energy IoT; device wake and RF-energy admission; dynamic spectrum occupancy and spectrum authorization; RF, millimetre-wave, sub-THz, and future-band emission; reconfigurable intelligent surfa", "rev": "02", "time": "2026-09-29T14:39:02Z", "group": "individual", "pages": 262, "relevant": 0.93, "domain": "authz", "domain_conf": 0.69, "centrality": 1.26, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-das-enterprise-ai-enforcement-profiles", "title": "Securing the Enterprise Future: Technical Non-Joinability for Enterprise AI", "abstract": "Enterprise artificial-intelligence systems are increasingly connected to multiple organizational repositories, applications, tools, memory systems, and workflow interfaces. Representative industrial deployment classes include OpenAI ChatGPT and ChatGPT Work, Anthropic Claude, Google Gemini Enterprise, xAI Grok for Business, Microsoft Copilot and Copilot Studio, Amazon Q Business, Salesforce Agentforce, ServiceNow AI Agents, and comparable enterprise or privately deployed AI systems. These names are cited only as publicly described examples of the broader deployment class. Their inclusion does not assert that any named product implements, lacks, requires, endorses, or is vulnerable to the mechanisms described here, does not characterize undisclosed internal architectures, and does not imply that equivalent functionality is absent from an existing product or specification. The security problem considered here is not limited to theft of a pre-existing database. An enterprise-AI workload may be individually authorized to retrieve information from customer, engineering, financial, source-code, supplier, scheduling, communication, memory, and operational systems while the combination of those sources reveals a sensitive relationship or future enterprise state that no single repository contains. Conventional access control, encryption, network segmentation, database separation, confidential computing, and source-level authorization remain important, but storage separation alone does not prevent such reconstruction where the same effective authority can obtain the constituent values and freely resolve the relationships among them. The mechanism described here therefore separates not only protected data but also the authority required to create protected semantic relationships among that data. Identity components, substantive content, relationship-mapping information, reconstruction-enablement state, and authorization state may be maintained under independently controlled protection domains. A processing request establishes a bounded reconstruction authorization tied to the actual workload, execution context, session, permitted fields, permitted relationships, processing purpose, and output conditions. Each required protection domain independently determines whether its component may participate. Approved components may remain session bound, cryptographically wrapped, capability restricted, opaque, or accessible only through a mandatory mediated path. Only the specifically authorized relationships are resolved inside a protected reconstruction environment, which constructs a temporary minimum- necessary view without providing the AI workload with unrestricted authority over the underlying stores. This creates a technical distinction between authority to access information and authority to associate information. Access to an identity component and access to a content component do not, by themselves, authorize every relationship between them. The same distinction applies after computation: successful reconstruction, inference, or generation does not automatically authorize disclosure, persistence, transmission, tool invocation, database modification, payment, downstream-model use, or another external consequence. A resulting output or proposed act can remain technically non- releasable while current session, execution, association, provenance, destination, recipient, policy, revocation, and disclosure conditions are verified. Protected evidence of successful verification is committed before scoped release authority is created and checked at the actual consequence boundary. This document presents 79 Enforcement Profiles that apply the same underlying architecture to different enterprise-AI enforcement points, including multi-domain information separation, independent association authority, session-bound reconstruction, protected provenance, runtime behavioral verification, agentic tool invocation, prompt and input mediation, streaming dis", "rev": "01", "time": "2026-09-29T14:37:36Z", "group": "individual", "pages": 78, "relevant": 0.89, "domain": "authz", "domain_conf": 0.91, "centrality": 1.64, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-das-execution-finality-ai-interoperability", "title": "Secure and Privacy-Preserving AI Interoperability under Article 6(7) of the European Digital Markets Act: An Execution-Finality Architecture", "abstract": "AI assistants increasingly interoperate with operating-system functions, applications, cloud services, payments, files, messaging, sensors, network interfaces, and device controls. In that environment, authenticating an assistant or granting it a broad permission does not by itself answer the final security question: whether this exact pending operation, with these exact parameters and this current system state, is authorized to become externally effective. Existing mechanisms such as operating-system permissions and sandboxing, application intents and typed APIs, OAuth delegated authorization, Rich Authorization Requests, sender-constrained tokens, trusted execution environments, attestation, hardware-backed keys, transaction preconditions, and audit logs address important parts of that problem. They can also be composed with the architecture described here. However, those mechanisms do not inherently require the complete sequence defined in this document: keep the proposed act non-effective, bind authority to the exact act and current protected state, re-derive the actual pending consequence at a mandatory effectuation boundary, consume freshness or budget state in a TOCTOU-resistant manner, and deny any alternate path that could cause the same protected effect without the final check. This document calls the staged operation a Candidate Act and the pre- effect condition the Non-Effective State. A Protected Execution Domain performs protected validation and may commit pre-effect validation evidence, including a LAVR. It then makes available narrowly scoped, non-bearer execution authority bound to the exact act, requester, resource, destination, policy and revocation epoch, freshness state, Finality Sink, and Effectuation Boundary. The Finality Sink is the mandatory policy-enforcement or command/commit gate that independently reconstructs the actual operation immediately before the consequence can occur. In conventional security and control terminology, the architecture combines properties associated with a reference monitor, policy enforcement point, safety interlock, command gate, actuation gate, transactional authorization check, cryptographic parameter binding, proof-of-possession or sender-constrained authority, anti-replay state, fencing or generation epochs, bounded capabilities, and a TOCTOU-resistant check-and-commit operation. The terminology is not intended to require one component name, protocol, hardware block, or packaging model; functional equivalence depends on the enforcement sequence and invariants. The design addresses prompt injection, compromised assistants or cloud infrastructure, confused-deputy behavior, replay, token theft or reuse, destination and parameter substitution, scope escalation, stale authorization, policy or revocation changes, wrong-sink presentation, alternate-path bypass, crash ambiguity, persistent- state rollback, and unauthorized consequential execution. It also supports privacy minimization by allowing a platform to expose a narrow act without granting reusable authority over an entire application or data class. For interoperability deployments, the intended result is open participation with bounded, verifiable effectuation authority: a third-party or first-party AI may propose the same class of device or service action, while the platform or service independently enforces whether the concrete action may cross the protected consequence boundary. This document describes a technical architecture and does not determine whether a particular deployment satisfies the Digital Markets Act, GDPR, the EU AI Act, or any other legal requirement. The same engineering question is relevant beyond any single assistant or mobile platform. Representative current interoperability contexts include Google Gemini on Android, where Gemini can operate as a default digital assistant and Android exposes device-assistance functions and AppFunctions-style application capabilities for use by agents and assistan", "rev": "05", "time": "2026-09-29T14:37:17Z", "group": "individual", "pages": 200, "relevant": 0.89, "domain": "authz", "domain_conf": 0.99, "centrality": 1.94, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-das-agentic-effectuation-boundary", "title": "When AI Agents Hold the Keys: Threat Model and Execution-Finality Requirements for Autonomous High-Consequence Systems", "abstract": "AI agents are increasingly being delegated authority to invoke APIs, move money, modify enterprise state, operate infrastructure, and trigger physical actions. Existing mechanisms for authentication, authorization, proof-of-possession, attestation, request preconditions, and authorization-context propagation are necessary building blocks, but they do not by themselves establish a universal invariant that the exact consequential act approved earlier is the exact act permitted to become effective now. This document defines a threat model for autonomous high-consequence agents and identifies an effectuation-boundary gap: a request can be correctly authenticated, correctly authorized, correctly attested, and still be unsafe to execute because parameters, policy state, external prerequisites, delegation state, lineage, or the execution path changed after the earlier decision. The document describes an execution-finality architecture in which a proposed act remains non- effective until a protected enforcement point verifies exact-act binding, freshness, current policy state, anti-replay state, required provenance, and path completeness immediately before effectuation, with authority consumed in coordination with the consequential commit.", "rev": "00", "time": "2026-09-29T14:36:44Z", "group": "individual", "pages": 31, "relevant": 0.92, "domain": "authz", "domain_conf": 0.83, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-das-accountable-autonomous-effectuation", "title": "AI Safety and Accountability at the Effectuation Boundary: Protocol Requirements for Autonomous Actions", "abstract": "Artificial intelligence and autonomous systems are increasingly moving from generating information to initiating actions that directly affect data, services, networks, infrastructure, and physical systems. At the opening of the General Debate of the 81st Session of the United Nations General Assembly, UN Secretary-General Antonio Guterres warned of \"technology without accountability,\" describing the concern further as \"capability without oversight\" and \"decision-making without transparency,\" and called for cooperation on AI safety risks, testing, evaluation, transparency, and common safeguards. This document examines that problem from governance intent to consequence-edge verification protocols: the corresponding technical question is how can accountability remain enforceable at the moment a machine-generated decision becomes an externally consequential action? It defines an effectuation-boundary problem in which a proposed action may be correctly authenticated and authorized upstream, yet the operation ultimately presented for execution may differ because of substitution, redirection, replay, stale authority, changed state, compromised intermediaries, or other causes. An execution-finality architecture is presented as one possible technical response. A proposed operation remains non-effective until applicable authority and protected-state conditions are satisfied, and the component controlling the external consequence verifies that the operation actually presented for effectuation corresponds to currently valid authority. This document does not define AI governance policy, and it does not imply endorsement of this architecture by the United Nations or any other institution. It is intended to solicit IETF discussion about whether effectuation-boundary accountability constitutes an interoperability or protocol requirement, which existing mechanisms can provide the required properties, and whether any additional standardization is necessary.", "rev": "01", "time": "2026-09-29T14:36:36Z", "group": "individual", "pages": 47, "relevant": 0.86, "domain": "authz", "domain_conf": 0.45, "centrality": 1.56, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-das-agentic-adaptive-authorization", "title": "Adaptive Authorization for Agentic AI: Graduated and Escalated Execution Control for Critical Infrastructure", "abstract": "AI agents are beginning to move money, release confidential data, change cloud privileges, and command industrial and other critical- infrastructure equipment. Existing controls answer whether an actor or request may proceed. These include authentication, OAuth scopes, conditional access, risk engines, and attestation. None of them, alone, guarantees three things about the consequence that finally occurs: that it is the exact act that was evaluated, that it is still permitted under current state, and that it cannot be replayed, substituted, or routed around the check. Risk engines that return ESCALATE widen this gap. The escalation is a label, and nothing forces the stricter conditions it implies to reach the point where the effect actually happens. This document defines Graduated and Escalated Conditional Execution Finality. Every AI-generated operation is held as a non-effective Candidate Act. It is classified into a graduated release class rather than a binary allow/deny: ordinary, reduced, escalated, canary, sandbox, review, quarantine, or deny. For an elevated-risk act, the system first derives a narrower consequence boundary. It then binds the required controls into an act-bound, sink-bound Execution Handle; examples include a lower value, one named recipient, protected approval, short validity, fresh attestation, and single use. The Finality Sink at the last preventable boundary re-verifies those controls against current protected state, atomically with effectuation. The contribution is threefold. First, escalation changes executable authority, not merely a decision record. Second, escalation is monotonic: it cannot be laundered, fragmented, downgraded, or resubmitted away on its path to the sink. Third, the Finality Sink is shown to be necessary but not sufficient, so finality is an end- to-end property rather than a gateway. The document specifies nineteen testable enforcement points, from the base execution- dependency mechanism to proxy, hardware, escrow, rollback, inheritance, and path-closure requirements. It also provides a comparison with conventional mechanisms, a security model with explicit assumptions and invariants, a latency model, escalation- specific attacks, and the problems it leaves open.", "rev": "00", "time": "2026-09-29T14:36:22Z", "group": "individual", "pages": 87, "relevant": 0.91, "domain": "authz", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-das-execution-finality-deployment", "title": "Execution-Finality Architecture for AI and Autonomous Critical Systems", "abstract": "AI models, agents, and autonomous services increasingly initiate payments, communications, data releases, infrastructure changes, and physical actions in critical systems. Authentication, authorization, human approval, proof of possession, attestation, policy evaluation, and audit are important, but none of them alone establishes that the exact operation becoming externally effective is the operation that was authorized and remains permitted under current protected state. This document defines an execution-finality architecture in which a proposed operation remains non-effective until a mandatory enforcement function controlling the effectuation boundary reconstructs the actual operation, verifies exact-act binding and current protected state, prevents replay or stale authority, and couples the decision to the resulting consequence through an atomic or equivalently crash-consistent transition. The document explains why latency is only one engineering consideration and is often not the dominant problem. Consequence-path completeness, deterministic act representation, protected state, atomicity, crash recovery, safe degraded operation, and legacy-system integration are usually harder requirements. A detailed FAQ addresses whether placing OAuth at the last irreversible execution boundary is the same architecture. It is not automatically equivalent merely because a token, scope, or sender- constrained proof is checked at that location. An OAuth-protected implementation is functionally equivalent only when it also exclusively mediates every consequence path, reconstructs and binds all consequence-relevant fields, revalidates authoritative current state, enforces replay and generation controls, atomically couples authorization consumption to the exact effect, and provides safe failure and recovery semantics. In that case, the implementation is functioning as the Finality Sink, regardless of terminology. The document also identifies the division of responsibility and possible relevance of OAuth, RATS, WIMSE, Web Bot Auth, other IETF communities, and longer-term IRTF research. This document is architectural and informational; it does not define a wire protocol.", "rev": "01", "time": "2026-09-29T14:36:12Z", "group": "individual", "pages": 32, "relevant": 0.89, "domain": "authz", "domain_conf": 0.69, "centrality": 1.06, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-das-protocols-enterprise-ai", "title": "Assume the AI Server Is Already Compromised: Execution-Consequence Decoupling So a High-Risk Enterprise AI Cannot Join, Infer, or Send", "abstract": "Start from the assumption that the attacker already controls the AI server — that the workload is fully compromised. Not the perimeter, not a phished seat — the workload itself: its credentials, its connectors, its context window, its output path. Nearly every enterprise control in use today has already failed by that point, because nearly every one of them is designed to keep the attacker out of the workload rather than to limit what the workload can do once it is theirs. Before anything else, the engineering posture: this architecture is specified for high-risk AI systems, where the standard priorities shift from speed and latency toward determinism, containment, and safety. It is written for billion-dollar enterprise and mission- critical deployments — banking and treasury, defence and national security, critical infrastructure, and regulated enterprises holding unreleased material — and not for general day-to-day, consumer-grade, or low-stakes use. It introduces evaluation on the join path and on the release path, and accepts that cost deliberately, because in these environments an unauthorized reconstruction or an unauthorized send is not recoverable by being fast. This document asks what is still denied to the attacker at that moment, and specifies an architecture in which two things are still denied: the attacker cannot cause independently held enterprise fragments to be bound into a map of the organization, and cannot cause any generated result to become externally effective. Access to a store is not authority to join it to another store. Finishing a generation is not authority to send it. The mechanism is Execution-Consequence Decoupling, enforced by three pillars: Decomposition of Authority (Technical Non-Joinability) across independently controlled identity, content, relationship- mapping, and cryptographic domains; Mandatory Mediation of every consequence-bearing Candidate Output; and Technical Non- Completability, so that computation can run to completion in a compromised environment without the ability to complete an external consequence. Reconstruction is governed by a non-bearer Reconstruction Authorization Object bound to attested execution context, session, purpose, and Permitted Association Scope. Candidate Outputs are sealed, re-verified at output time, and committed to a Protected Output Validation Receipt before an output- specific Release Capability can be issued and exercised at a designated Output Release Boundary. The industrially relevant systems are the enterprise assistant and agent runtimes now deployed into exactly those environments, including those built on Anthropic Claude, OpenAI ChatGPT, Google Gemini, xAI Grok, and self-hosted Meta Llama models, together with the connector and Model Context Protocol fleets attached to them. These are named as publicly described deployment classes, because an architecture for high-risk enterprise AI should say plainly which systems it is about; nothing here characterizes any vendor's internal design or security posture, and no vendor has reviewed or endorsed this work. It states the problem space, compares the architecture against representative conventional technologies (access control, bearer credentials, vaulting, TEEs, sandboxes, DLP, provenance, DRM, clean rooms, and information-flow control), gives a detailed technical description, and supplies JSON Schema definitions for the three protected objects. A published runnable reference implementation [GITHUB-DAS-VII] executes the protected chain described here, so the architecture can be run and tested rather than only read; it is an architectural reference for the state machine and its failure states, not a claim of production isolation. This is the architecture and rationale document. Its companion, draft-das-enterprise-ai-output-finality [I-D.das-enterprise-ai-output-finality], specifies the same split as a deployable protocol profile and metadata format for vendor assistant and agent seats. The two are ", "rev": "02", "time": "2026-09-29T14:35:37Z", "group": "individual", "pages": 40, "relevant": 0.94, "domain": "authz", "domain_conf": 0.64, "centrality": 1.95, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-das-enterprise-ai-output-finality", "title": "The Missing Piece for High-Value Confidential Enterprise AI: Non-Joinable Vaults and Output-Release Finality for Banking, Defence, and Public-Sector Deployments", "abstract": "This profile is specified for high-risk, multi-system enterprise and public-sector AI — assistants and agents that can see several independently authorized stores and then send, write, or invoke. It is not specified for consumer chat. In industrial terms that describes enterprise assistant and agent seats of the kind offered by Anthropic, OpenAI, Google Gemini, and xAI Grok, together with self- hosted open-weight deployments; these names are used with respect, as publicly described deployment classes only, and imply no claim about any vendor's internals and no vendor endorsement of this profile. A 2020 breach stole what was already stored: a server image, a database dump, user rows. After 2025 a compromised assistant can do what a dump cannot. In minutes it can join mail, tickets, code, finance, and memory into a map of launch plans, targets, defects, and negotiation room — strategy that was never one record — and that map can be sold to a competitor. There is no credential rotation for a future that has already been read. Traditional access control still answers who may touch each store. It does not answer whether those fragments may be joined into that meaning, or whether that meaning may leave. This document specifies an architectural framework and metadata profile for that gap. Technical Non-Joinability is enforced by a session-bound Reconstruction Authorization Object (RAO) that limits relational binding. Technical Non-Completability is enforced by an Output Release Boundary that requires committed validation evidence before a generated token or tool invocation can take external effect. The specification defines the authorization objects, cryptographic bindings, and boundary validation sequences required to isolate reconstruction domains without modifying the underlying datastores. A published runnable reference implementation is provided so that the profile can be executed and tested, not only read as theory. That implementation is an architectural reference for the state machine, not a claim of production isolation. The architecture introduces bounded evaluation on the path that can intercept unauthorized join or release. That latency is accepted where the asset is high- consequence enterprise or public-sector intelligence and raw speed is subordinate to preventing reconstruction and release. The author states that trade-off explicitly: this profile is for deployments that choose that priority. It is not offered as a design for consumer chat or other paths that optimize only for speed. Readers are respectfully encouraged to review Section 4 and Section 5 in full, as those sections set out the complete problem description and motivating scenarios and should not be skipped.", "rev": "03", "time": "2026-09-29T14:34:06Z", "group": "individual", "pages": 65, "relevant": 0.9, "domain": "authz", "domain_conf": 0.89, "centrality": 1.97, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-das-protocols-candidate-act-finality", "title": "Stopping AI Hallucinations and Unsafe Acts from Becoming Real-World Consequences (DAS Protocols)", "abstract": "The internet has protocols for moving data, securing channels, naming hosts, and delegating identity. It has no protocol for the moment a machine-generated instruction becomes a real-world act. As AI systems begin to move money, change databases, reconfigure networks, send communications, and control physical systems, that missing boundary becomes a structural risk. Today an AI can hallucinate a fact, cite a stale source, invent a tool argument, or propose an unsafe agentic step — and still reach an effectuation interface. Model approval is not output approval. Workflow approval is not consequence approval. Moderation, access control, TEEs, simulation, and post-hoc audit all leave the final transition from computation to consequence under-protected. This document specifies the DAS Protocols Candidate-Act Finality architecture. Every effect-capable AI output is first converted into a non-effective Candidate Act. The Candidate Act stays non-effective until a Protected Enforcement Domain has validated output, provenance, factual support, consequence, jurisdiction, epoch, and sink predicates. Only then is a scoped non-bearer capability or Execution Handle released and verified at a Finality Sink. In advanced forms the Finality Sink is cryptographically unable to complete the act unless the handle supplies the missing execution material. The architecture supports graduated and escalated conditional finality so that elevated-risk but necessary acts can still proceed under stricter controls. The document elaborates the problem space, compares the approach with representative existing techniques, describes the base and advanced finality paths, and provides JSON Schema definitions for the core protected objects. Related Indian provisional applications and PCT filings are listed in the final appendix.", "rev": "01", "time": "2026-09-29T14:32:37Z", "group": "individual", "pages": 34, "relevant": 0.85, "domain": "authz", "domain_conf": 0.37, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-das-hardware-enforced-execution-finality", "title": "Computation Is Not Authority: Hardware-Enforced Execution-Finality for Agentic AI, MCP Tool Calls, and Industrial Agents", "abstract": "Neural AI systems -- large language models, vision-language models, and other learned decision systems -- now move directly from computation to consequence. A model output becomes a tool call; a tool call becomes an API transaction, memory write, payment, file mutation, browser action, or actuator signal; an agent delegates to another agent. Successful inference, sandbox containment, connector allowlisting, session permission, or upstream model approval does not by itself establish authority for that particular real-world consequence. A model may be authorized to compute while remaining unauthorized to act. This document specifies a hardware-rooted execution-finality architecture for neural and agentic systems. A proposed consequence- bearing operation is represented as a Candidate Act and held in a Non-Effective State until a Protected Enforcement Domain validates act-specific predicates and an independent Finality Sink verifies scoped, non-bearer finality authority immediately before the operation becomes externally effective. If that authority is absent, stale, replayed, revoked, or mismatched to the act being attempted, the Candidate Act remains non-effective and the operation fails closed. The architecture is model- and vendor-neutral. It is written for the industrial surfaces that now dominate production agent deployments: Model Context Protocol (MCP) tool dispatch, computer use, code execution, enterprise connectors, memory and knowledge-store writes, GPU and confidential-computing egress, and settlement. The same invariant applies to those surfaces: computation is not authority; tool selection is not tool-effectuation; a connector allowlist is not per-act finality.", "rev": "02", "time": "2026-09-29T14:32:03Z", "group": "individual", "pages": 36, "relevant": 0.89, "domain": "authz", "domain_conf": 0.87, "centrality": 1.98, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-das-rats-frontier-model-extraction", "title": "An Execution-Finality Architecture for Controlling Release and Limiting Unauthorized Extraction and Distillation of Sensitive, High-Priority Frontier AI Model Information", "abstract": "This architecture is a hardware-rooted defense against intellectual- property theft of frontier AI models, intended for deployment by AI model creators themselves -- including trillion-dollar frontier-model providers such as OpenAI and Anthropic -- rather than for generic, day-to-day AI use by an end user. It protects Sensitive Model Information that is high-priority and dual-use, with the specific purpose of preventing unauthorized extraction and distillation of the model itself. The architecture introduces bounded, deterministic evaluation latency to intercept unauthorized release paths, a trade- off acceptable specifically for protecting highly valued dual-use assets where standard optimization for raw speed is subordinate to absolute asset security. Frontier and proprietary AI deployments may contain or expose model- related information substantially richer than ordinary final-answer text. Depending on the deployment and interface, such Sensitive Model Information (SMI) can include detailed probability information, embeddings, cached intermediate state, hidden representations, intermediate activations, diagnostic information, model-related metadata, or other high-information artifacts. Repeated unauthorized or excessive release of such information can increase the efficiency of model reconstruction, imitation, extraction, or distillation. Authentication establishes who is requesting an operation. Confidential computing and remote attestation can establish properties of the environment in which computation occurs. Neither property alone determines whether a particular pending release of particular model information, to a particular destination, under the current extraction state and security epoch, remains authorized to become externally usable. This document describes an execution-finality architecture for that remaining problem. Sensitive information may be computed while remaining a non-effective Candidate Release. External release occurs only after release-specific protected validation, evaluation of rollback-resistant extraction state where required, atomic reservation or consumption of bounded authority, and verification at a controlled Finality Sink. Release authority is bound to the applicable Candidate Release or bounded release class rather than operating as a generic transferable bearer credential. The architecture does not claim universal prevention of model extraction or distillation and does not restrict legitimately exposed ordinary model output. Its narrower objective is to make unauthorized, excessive, replayed, rolled-back, or bypassed release of protected model information technically harder to complete through governed release paths. RATS can complement this mechanism by allowing a Verifier or Relying Party to obtain machine-verifiable information about whether the expected release-control mechanism, protected state, security epoch, and Finality Sink are present and operating with the required assurance properties. To demonstrate that this architecture is practically achievable and not merely theoretical, a runnable reference implementation is provided at Execution-Finality for Protected AI Model-State Release -- RATS Reference Implementation (https://github.com/sangmdas/ Execution-Finality-for-Protected-AI-Model-State-Release-RATS- Reference-Implementation).", "rev": "04", "time": "2026-09-29T14:31:22Z", "group": "individual", "pages": 75, "relevant": 0.5, "domain": "attestation", "domain_conf": 0.84, "centrality": 1, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-das-purpose-execution-finality", "title": "Data-Purpose Laundering Prevention: Execution-Finality for Preventing Cross-Domain Data Reuse", "abstract": "Consider a concrete case: a user invokes a highly capable AI model under a declared purpose of education, but the resulting capability is in fact used for a military or terrorist end -- an illustrative example, not a claim about any real deployment. When such misuse surfaces, an unresolved question follows: is the model provider liable, is the user liable, or is the jurisdiction that permitted the deployment liable? This document does not answer that question -- liability determination remains an external legal question for the responsible court, regulator, or contracting parties -- but it addresses the technical gap that makes the question unanswerable today. Systems that collect data, or grant capability, for one stated purpose routinely permit that data or capability to be consumed for a different purpose, not because the second use was authorized, but because nothing in the protocol path was capable of refusing it or of recording what was actually authorized. The most common technical control in deployment today is a self-asserted purpose string: a \"purpose\" claim in a token, a field in an API request, a comment in a data-sharing agreement. A self-asserted string is evidence of intent, not proof of authority, and it fails precisely when it matters most -- when the requester lies. This architecture addresses that loophole deterministically: it makes an undeclared or purpose-switched use technically detectable and refusable at the point of use, and it produces verifiable evidence of what was actually authorized, so that any subsequent liability determination can be argued from that evidence rather than from an unverifiable self-assertion. Achieving that determinism introduces a bounded, measurable amount of evaluation latency at the point of use; this document treats that latency as an acceptable, secured trade-off for closing an otherwise unverifiable gap, not as a cost to be minimized at the expense of the guarantee. The premise is not that AI innovation should slow down, any more than cars should be built slower; it is that innovation moving this fast needs the technical equivalent of a seat belt. A runnable reference implementation accompanies this document at Purpose Execution Finality Validator -- Runnable Reference Implementation (https://github.com/sangmdas/Purpose-Execution- Finality-Validator-to-Prevent-Data-Purpose-Laundering-in-AI-Systems).", "rev": "03", "time": "2026-09-29T14:31:08Z", "group": "individual", "pages": 60, "relevant": 0.84, "domain": "authz", "domain_conf": 0.91, "centrality": 1.43, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-das-agentic-tool-binding", "title": "tool_use Is Not invoke(): Binding Execution-Finality to Agentic Tool-Call Interfaces and MCP", "abstract": "Frontier runtimes already standardized the dangerous moment. A model emits a tool_use block, a tool_calls array, or an MCP tools/call payload. The host then invokes whatever name and arguments the model printed. Alignment, allowlists, and OAuth sit around that moment. They do not sit on it. The consequence of this gap is no longer confined to email or payment demos. In defense, energy, grid control, industrial process control, and other critical-infrastructure deployments, the same tool_use block already reaches actuation-class systems -- logistics and targeting-adjacent decision support, SCADA and PLC interfaces, medical devices, autonomous platforms. In these environments, detection after the fact is not mitigation; it is an incident report written after the effect has already occurred. An agent that can act at machine speed but cannot be halted at machine speed is a system running without brakes: the first uncontrolled invocation is not a warning sign, it is the accident. Command authority, human oversight, and legal review all operate on human time. An unbound tool_use block operates on machine time. When those two clocks diverge, the gap belongs to whichever side reaches the effect first -- and today, nothing structurally guarantees that side is authorization. This document does not invent another assistant API. It binds the Agent Candidate Act profile [I-D.das-agentic] onto the three interface families those runtimes and their customers already ship: tool_use / computer_use style interfaces, function-calling and structured tool-response interfaces, and Model Context Protocol tools/call. The model may emit the block. The block remains non- effective. A local enforcer builds the act, binds the argument digest, and refuses invoke() until scoped authority is verified and consumed at the dispatch sink. For consequence classes above a defined threshold -- FINANCIAL, PHYSICAL, NETWORK_CONTROL, and any act reaching defense or critical- infrastructure actuation -- this binding treats fail-closed as the only conforming behavior: absent successfully verified, current, act- bound authority, the candidate act stays non-effective regardless of model confidence, prior session trust, or upstream alignment signal. Each enforcement decision, allow or deny, commits a Ledger-Anchored Validation Receipt (LAVR) -- a signed, hash-chained enforcement artifact bound to the specific candidate act and its argument digest at the moment of decision. An LAVR is not a log entry assembled afterward for audit; it is the proof that the finality boundary actually gated this act before any effect could occur, and its absence is itself a fail-closed condition. The implementation target is a middleware function that a host loop can call without changing the model vendor. tool_use is not invoke().", "rev": "03", "time": "2026-09-29T14:30:39Z", "group": "individual", "pages": 51, "relevant": 0.94, "domain": "authz", "domain_conf": 0.92, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-sharif-agent-audit-trail", "title": "Agent Audit Trail: A Standard Logging Format for Autonomous AI Systems", "abstract": "This document specifies a standard logging format for autonomous AI agent systems. The Agent Audit Trail (AAT) defines a JSON-based record structure with mandatory fields for agent identity, action classification, outcome tracking, and trust level reporting. Records are linked via tamper-evident hash chaining using SHA-256 per RFC 8785, with optional ECDSA signatures for non-repudiation. The format addresses requirements from the EU AI Act (Regulation 2024/1689), which mandates automatic recording of events for high-risk AI systems, whose application dates were staged into 2027-2028 by Regulation (EU) 2026/1744. It also maps informatively to SOC 2 Trust Services Criteria, ISO/IEC 42001, the draft ISO/IEC 24970 and prEN 18229-1 logging standards, and PCI DSS v4.0.1 logging requirements. The design is transport-agnostic and supports export to JSONL, Syslog (RFC 5424), and CSV while preserving chain integrity. Privacy is addressed through input/output hashing, content fingerprinting, and tombstone-based deletion compatible with GDPR Article 17. The -01 revision added pre-execution recording requirements, recording independence, deny reason codes, replay protection, external timestamp anchoring, and content fingerprinting based on feedback from independent implementers. The -02 revision added a Decision Reproducibility section (Section 13) that distinguishes record reproducibility, available for any model, from decision reproducibility, available only for open-weight models executed at temperature zero in an attested environment, and defines the associated record fields. The -03 revision added the Attestation Closure requirement (Section 13.6): the digests recorded for decision reproducibility MUST cover the complete computational closure of the inference function -- model weights, tokenizer, chat template, inference engine build, decoding configuration, and numeric environment -- together with new record fields (tokenizer_digest, chat_template_digest, engine_build_digest) and a minimal-change threat analysis (Section 13.7) showing that any component left outside the attested set is a forgery channel. This revision (-04) adds algorithm agility for post-quantum signatures (ML-DSA-65, FIPS 204) alongside ECDSA P-256; a key identifier (signer_kid, RFC 7638) that resolves which principal signed an independently recorded record; a trust-level assignment integrity requirement (Section 5.3) so that downgrading a consequential action is an attributable event rather than silent suppression; and OPTIONAL Merkle batch anchoring (Section 6.4) using the RFC 6962 construction for compact inclusion proofs at high throughput. All -04 additions are OPTIONAL to produce, and -04 verifiers stay backward compatible with -03: a -04 verifier accepts -03 records, and the new signing metadata is required only in records that carry a signature.", "rev": "06", "time": "2026-09-29T07:57:04Z", "group": "individual", "pages": 56, "relevant": 0.91, "domain": "attestation", "domain_conf": 0.97, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-01T10:58:39.003Z", "full": true }, { "name": "draft-sankarshan-agent-registry-protocol", "title": "Agent Registry Protocol", "abstract": "Software agents increasingly act on behalf of people and organizations across administrative and security boundaries. Existing discovery mechanisms can identify an endpoint or advertise a capability, but they do not by themselves provide a common way to resolve who operates an agent, the bounded authority under which it acts, whether that authority is current, or what evidence supports a reliance decision. This document defines the Agent Registry Protocol (ARPA), an HTTP and JSON protocol for publishing and resolving information about software agents, their operational deployments, typed relationships, bounded delegated authority, lifecycle status, and associated evidence. ARPA separates identification, authentication, authorization, assurance, and lifecycle state. Registration, successful authentication, capability advertisement, or proof verification does not by itself establish authority to perform an action. The protocol is designed to support deterministic fail-safe behavior when material authority information is revoked, suspended, expired, stale, conflicting, unavailable, or unverifiable.", "rev": "04", "time": "2026-09-29T05:32:53Z", "group": "individual", "pages": 56, "relevant": 0.68, "domain": "discovery", "domain_conf": 0.75, "centrality": 1.98, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-uppalapati-wimse-pq-agent-identity", "title": "Post-Quantum Requirements for Software and AI Agent Identity", "abstract": "A delegation record retained as evidence must remain verifiable long after the key that signed it is retired. A signature of any algorithm establishes who signed, not when, so such a record needs anchoring in trusted time, renewed before the algorithms protecting it weaken. That is long-settled practice for archived signatures. It is rarely required for agent delegation, and where it is, the anchor is not itself required to be post-quantum. An anchor is only as good as the protection behind it, and an RFC 3161 timestamp is itself a signature: an adversary holding a cryptanalytically relevant quantum computer can mint one bearing any date it chooses. Because such a machine may be built without announcement, anchoring must become post-quantum anchoring by a stated transition date, and be applied early, so that the only assumption left about when such a machine appeared is that none existed before a record was first anchored that way. The earlier that date, the weaker the assumption, which makes choosing it a security decision and not only a scheduling one. This document states requirements that software and AI agent identity mechanisms should satisfy in order to remain sound across the transition, and identifies four that no such mechanism yet imposes on delegation credentials in general. The algorithms binding each hop of a delegation chain to its trust anchor must be visible to a verifier and retained with any record kept as evidence; where a signing key is fetched from a key set over TLS, as OAuth deployments commonly do, that binding is rarely recorded and no mechanism for agent delegation requires it to be, so in practice it is absent. Trust anchors must migrate before the credentials issued under them. Every retained record must be anchored, that anchoring must become post-quantum anchoring from a stated transition date and be maintained by renewal, and credentials of any type kept as evidence must be signed post-quantum from that same date. Delegation chains also propagate the weakest algorithm in the chain, and routinely cross organizational boundaries where no common trust anchor policy can be assumed.", "rev": "00", "time": "2026-09-29T03:32:00Z", "group": "individual", "pages": 42, "relevant": 0.69, "domain": "identity", "domain_conf": 0.88, "centrality": 1.04, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-pidlisnyi-aps", "title": "Agent Passport System (APS): Verifiable Authority, Lifecycle, Enforcement, and Evidence for AI Agents", "abstract": "This document specifies the Agent Passport System (APS), a protocol for representing and evaluating authority exercised by AI agents. APS separates agent identity, represented principal, delegated authority, policy approval, admission to dispatch, observed results, and external effects. It defines cryptographic identity and principal records, monotonic delegation, revocation and authority- lifecycle semantics, deterministic action and decision references, signed governed-action records, verifier outcomes, evidence resolution, profiles, and protocol bindings. APS defines how an enforcement boundary rechecks current authority before admitting an action to dispatch, and how a verifier distinguishes what a signed record establishes from claims that remain unresolved or external to the protocol. Requirements are split into APS Core, which every conforming implementation carries, and Candidate features, which an implementation opts into by naming them in its claim, and most of the lifecycle and decision-to-effect material in this document is Candidate rather than Core. Candidate features specify additional lifecycle and decision-to-effect behavior without making those features requirements of APS Core conformance. Implementation and conformance sections identify which requirements have exact conformance-vector coverage and which are implemented by the reference implementations. APS does not treat a valid signature, receipt, or delegation chain as proof of external truth or of the absence of an out-of-band execution path.", "rev": "04", "time": "2026-09-28T18:03:25Z", "group": "individual", "pages": 271, "relevant": 0.92, "domain": "authz", "domain_conf": 0.88, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true }, { "name": "draft-mo-cats-agent-service-characteristics", "title": "AI Agent Service Characteristics and Their Implications for Computing-Aware Traffic Steering", "abstract": "AI agent services place a new class of demands on the network: sessions are long-lived and stateful, a single user request expands into multiple model invocations and tool calls, and the quality of the result depends jointly on the forwarding path, on the computing capability that is available at the selected site, and on whether the state that the agent needs is already present near that site. Computing-Aware Traffic Steering (CATS) already selects a service contact instance using a combination of computing and network metrics, but the CATS framework, metric, and data model documents were not written with agent services in mind. The document covers long-horizon tasks and their long-tail behaviour, discrete and distributed tool invocation, the cost of context growth and compression, the communication modes used by agent services, and the persistence of session state and memory. It reports measured distributions of model, state, and software artifact sizes, states what a CATS system must measure in order to steer this traffic, and identifies the information that a CATS system needs in order to select an instance for an agent service. This document does not define any protocol extension, metric encoding, or data model.", "rev": "00", "time": "2026-09-28T16:48:03Z", "group": "individual", "pages": 27, "relevant": 0.87, "domain": "other", "domain_conf": 0.52, "centrality": 1.96, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-01T10:59:01.083Z", "full": true } ] }