{ "domains": [ "identity", "authz", "discovery", "protocols", "netmgmt", "attestation", "iot", "other" ], "count": 157, "candidates": [ { "name": "draft-etcheverry-action-ref", "title": "Action Reference: A Deterministic Identifier for Agent Actions", "abstract": "This document defines \"action_ref\", a deterministic, content- addressed identifier for autonomous agent actions. Any party holding the four preimage fields (agent_id, action_type, scope, timestamp) can independently compute and verify the identifier without trusting the emitting system. The document specifies the derivation algorithm, canonical serialization using RFC 8785 JSON Canonicalization Scheme (JCS), timestamp format requirements, canonical receipt envelope, optional fields for revocation and policy rotation auditability, scope conventions, and a composability model with existing exactly-once execution guarantees.", "full": true, "rev": "04", "time": "2026-10-23T10:38:58Z", "group": "individual", "pages": 23, "relevant": 0.75, "domain": "attestation", "domain_conf": 0.95, "centrality": 1.95, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-23T12:18:08.834Z", "evaluated": "2026-10-23T12:18:08.834Z" }, { "name": "draft-das-sandbox-credential-egress-finality", "title": "Protected Execution Finality for Sandboxed AI Agents, Credential Mediation, Process Lineage, and Network Egress", "abstract": "This informational document describes future-oriented execution- finality profiles for sandboxed autonomous AI agents, protected host services, credential brokers, external connectors, process-lineage restrictions, proxy-mediated network egress, native resources, and downstream effectuation interfaces. It examines sandbox versus authority separation, protected credential use, destination binding after DNS resolution, operation-specific validation, influence tracking, bypass-path completeness, replay restrictions, recovery and independent sink verification. It distinguishes possession of sandbox or proxy permissions from authority for a particular actual resource effect. Source-derived procedures, tests and algorithms are presented as implementation examples, not as evidence that identified vendors implement this proposed architecture. Industry Relevance: Recent public developments in autonomous AI-agent security and execution governance include Microsoft Execution Containers (MXC), Microsoft Agent Governance Toolkit ADR-0030 (Action-Bound, Fail-Closed Approval Protocol), and Project Perception; Google Agent Gateway and Gemini Agent; Meta Muse/Sentinel AI-Agent Security Architecture; NVIDIA OpenShell Reference Architecture and NVIDIA Sentry; OpenAI Agents API, Codex, Agents SDK, and Responses API; and Anthropic Claude Managed Agents, Claude Code Sandboxing, and Claude Code Auto Mode. These initiatives illustrate industry attention to agent isolation, independent policy enforcement, action-bound authorization, delegated authority, credential isolation, network-egress security, hardware-assisted containment, runtime supervision, and fail-closed controls. This draft describes related proposed execution-finality mechanisms without asserting that these initiatives implement them. Relevance to the IETF: the mechanisms described here require common, interoperable objects and verification semantics across independently built components, including operation descriptors, act-bound non- bearer capabilities, finality-sink verification results, validation evidence, and authority, revocation, and containment generations. The document relates to existing IETF work on OAuth, GNAP, RATS, WIMSE, and SCITT, and asks the community whether and where this effectuation-boundary problem should be addressed. This document is intentionally long and is not repetitive: each profile specifies a distinct mechanism with its own algorithms, failure cases, and enforcement points, and the security properties depend on how these mechanisms combine. A reduced excerpt would hide the conditions under which they fail closed, so this document and its two companion drafts, among which the profiles are divided, are meant to be evaluated as a whole. This draft builds on earlier Internet-Drafts by the same author, in particular draft-das-agent-execution-finality, and adds mechanism families not described there; the Introduction states precisely what was disclosed earlier and what is disclosed here. IPR: The technical content of this draft set is based upon the author's international application PCT/IB2026/055615, which forms the foundation of this disclosure and comprises approximately 300 distinct, non-repetitive embodiments and enforcement points. A separate patent application specific to the material in this draft set has also been filed. Related Indian applications: 202531130665, 202631000572, 202631001586, 202631002990, 202631124028, and 202631125689. Related international applications: PCT/IB2025/058316, PCT/IB2026/053385, PCT/IB2026/055615, PCT/IB2026/055760, PCT/ IB2026/055870, PCT/IB2026/056058, PCT/IB2026/056809, and PCT/ IB2026/056941. These identify related technical disclosures; not all described mechanisms are necessarily patent-claimed or granted, and patent scope and priority depend on applicable law and examination.", "full": true, "rev": "00", "time": "2026-10-23T08:40:22Z", "group": "individual", "pages": 582, "relevant": 0.95, "domain": "authz", "domain_conf": 0.63, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-23T12:18:08.834Z", "evaluated": "2026-10-23T12:18:08.834Z" }, { "name": "draft-das-kernel-hardware-execution-finality", "title": "Protected Execution-Finality Enforcement for Autonomous AI Agents Across Kernel, Hypervisor, Hardware, and Native-Resource Boundaries", "abstract": "This document describes a proposed execution-finality architecture for autonomous agent workloads at kernel, hypervisor, device, and native-resource effectuation boundaries. It distinguishes computation from authority to commit consequential effects, and documents protected validation, operation-bound evidence, scoped authorization, independent finality verification, revocation, and containment, alongside deployment profiles and illustrative algorithms and tests. Industry Relevance: Recent public developments in autonomous AI-agent security and execution governance include Microsoft Execution Containers (MXC), Microsoft Agent Governance Toolkit ADR-0030 (Action-Bound, Fail-Closed Approval Protocol), and Project Perception; Google Agent Gateway and Gemini Agent; Meta Muse/Sentinel AI-Agent Security Architecture; NVIDIA OpenShell Reference Architecture and NVIDIA Sentry; OpenAI Agents API, Codex, Agents SDK, and Responses API; and Anthropic Claude Managed Agents, Claude Code Sandboxing, and Claude Code Auto Mode. These initiatives illustrate industry attention to agent isolation, independent policy enforcement, action-bound authorization, delegated authority, credential isolation, network-egress security, hardware-assisted containment, runtime supervision, and fail-closed controls. This draft describes related proposed execution-finality mechanisms without asserting that these initiatives implement them. Relevance to the IETF: the mechanisms described here require common, interoperable objects and verification semantics across independently built components, including operation descriptors, act-bound non- bearer capabilities, finality-sink verification results, validation evidence, and authority, revocation, and containment generations. The document relates to existing IETF work on OAuth, GNAP, RATS, WIMSE, and SCITT, and asks the community whether and where this effectuation-boundary problem should be addressed. This document is intentionally long and is not repetitive: each profile specifies a distinct mechanism with its own algorithms, failure cases, and enforcement points, and the security properties depend on how these mechanisms combine. A reduced excerpt would hide the conditions under which they fail closed, so this document and its two companion drafts, among which the profiles are divided, are meant to be evaluated as a whole. This draft builds on earlier Internet-Drafts by the same author, in particular draft-das-agent-execution-finality, and adds mechanism families not described there; the Introduction states precisely what was disclosed earlier and what is disclosed here. IPR: The technical content of this draft set is based upon the author's international application PCT/IB2026/055615, which forms the foundation of this disclosure and comprises approximately 300 distinct, non-repetitive embodiments and enforcement points. A separate patent application specific to the material in this draft set has also been filed. Related Indian applications: 202531130665, 202631000572, 202631001586, 202631002990, 202631124028, and 202631125689. Related international applications: PCT/IB2025/058316, PCT/IB2026/053385, PCT/IB2026/055615, PCT/IB2026/055760, PCT/ IB2026/055870, PCT/IB2026/056058, PCT/IB2026/056809, and PCT/ IB2026/056941. These identify related technical disclosures; not all described mechanisms are necessarily patent-claimed or granted, and patent scope and priority depend on applicable law and examination.", "full": true, "rev": "00", "time": "2026-10-23T08:34:54Z", "group": "individual", "pages": 483, "relevant": 0.94, "domain": "authz", "domain_conf": 0.37, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-23T12:18:08.834Z", "evaluated": "2026-10-23T12:18:08.834Z" }, { "name": "draft-das-distributed-agent-authority-finality", "title": "Distributed Authority and Execution-Finality for Multi-Agent Systems, Delegated Operations, and Cross-Domain Gateways", "abstract": "This informational document describes future-oriented distributed authority and execution-finality profiles for cooperating autonomous agents, delegated operations, external tools, cloud gateways, native resources, and cross-domain workflows. It examines identity, non- amplifying delegation, provenance and influence lineage, transitive side effects, cross-agent collision management, policy convergence and downstream effectuation-boundary enforcement. It distinguishes a proposed objective or authorized plan from authority for an actual resource effect. Source-derived procedures, tests and algorithms are presented as implementation examples, not as evidence that identified vendors implement this proposed architecture. Industry Relevance: Recent public developments in autonomous AI-agent security and execution governance include Microsoft Execution Containers (MXC), Microsoft Agent Governance Toolkit ADR-0030 (Action-Bound, Fail-Closed Approval Protocol), and Project Perception; Google Agent Gateway and Gemini Agent; Meta Muse/Sentinel AI-Agent Security Architecture; NVIDIA OpenShell Reference Architecture and NVIDIA Sentry; OpenAI Agents API, Codex, Agents SDK, and Responses API; and Anthropic Claude Managed Agents, Claude Code Sandboxing, and Claude Code Auto Mode. These initiatives illustrate industry attention to agent isolation, independent policy enforcement, action-bound authorization, delegated authority, credential isolation, network-egress security, hardware-assisted containment, runtime supervision, and fail-closed controls. This draft describes related proposed execution-finality mechanisms without asserting that these initiatives implement them. Relevance to the IETF: the mechanisms described here require common, interoperable objects and verification semantics across independently built components, including operation descriptors, act-bound non- bearer capabilities, finality-sink verification results, validation evidence, and authority, revocation, and containment generations. The document relates to existing IETF work on OAuth, GNAP, RATS, WIMSE, and SCITT, and asks the community whether and where this effectuation-boundary problem should be addressed. This document is intentionally long and is not repetitive: each profile specifies a distinct mechanism with its own algorithms, failure cases, and enforcement points, and the security properties depend on how these mechanisms combine. A reduced excerpt would hide the conditions under which they fail closed, so this document and its two companion drafts, among which the profiles are divided, are meant to be evaluated as a whole. This draft builds on earlier Internet-Drafts by the same author, in particular draft-das-agent-execution-finality, and adds mechanism families not described there; the Introduction states precisely what was disclosed earlier and what is disclosed here. IPR: The technical content of this draft set is based upon the author's international application PCT/IB2026/055615, which forms the foundation of this disclosure and comprises approximately 300 distinct, non-repetitive embodiments and enforcement points. A separate patent application specific to the material in this draft set has also been filed. Related Indian applications: 202531130665, 202631000572, 202631001586, 202631002990, 202631124028, and 202631125689. Related international applications: PCT/IB2025/058316, PCT/IB2026/053385, PCT/IB2026/055615, PCT/IB2026/055760, PCT/ IB2026/055870, PCT/IB2026/056058, PCT/IB2026/056809, and PCT/ IB2026/056941. These identify related technical disclosures; not all described mechanisms are necessarily patent-claimed or granted, and patent scope and priority depend on applicable law and examination.", "full": true, "rev": "00", "time": "2026-10-23T08:29:18Z", "group": "individual", "pages": 1472, "relevant": 0.95, "domain": "authz", "domain_conf": 0.97, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-23T12:18:08.834Z", "evaluated": "2026-10-23T12:18:08.834Z" }, { "name": "draft-hcf-bpm-agent-security-benchmark-profiles", "title": "Evaluation Profiles for AI Agent Security Assessment", "abstract": "This document defines evaluation profiles for the security assessment of AI agents. A profile fixes the System Under Test boundary and the scenario against which the metrics defined in [I-D.han-bpm-agent-security-benchmark-terminology] are applied, so that results obtained under different boundaries or scenarios are not compared without qualification. The document defines four infrastructure profiles, which correspond to the four component groups of an agent and to the four evaluation dimensions; six scenario profiles, which correspond to the agent types in scope; the input and output boundary specification that applies to all profiles; profile composition rules; and the minimum evaluation logging fields required by each profile. The metric definitions are the subject of [I-D.han-bpm-agent-security-benchmark-terminology], and the methods by which the metrics are exercised are the subject of [I-D.han-bpm-agent-security-benchmark-methodology].", "full": true, "rev": "00", "time": "2026-10-23T07:45:48Z", "group": "individual", "pages": 46, "relevant": 0.87, "domain": "other", "domain_conf": 0.95, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-23T12:18:08.834Z", "evaluated": "2026-10-23T12:18:08.834Z" }, { "name": "draft-hcf-bpm-agent-security-benchmark-terminology", "title": "Benchmarking Terminology for AI Agent Security Evaluation", "abstract": "This document defines terminology for the security evaluation of AI agents. It establishes a shared vocabulary for four first-level evaluation dimensions -- Foundation Model Security, Interaction Security, Operational Security, and Basic Security -- for the 55 second-level evaluation metrics organized under those dimensions, for the common metric evaluation convention that applies to all of them, and for the three agent security risk levels. This document defines terminology only. It does not prescribe evaluation procedures; the procedures are specified in [I-D.han-bpm-agent-security-benchmark-methodology], and the System Under Test boundaries and evaluation scenarios are specified in [I-D.han-bpm-agent-security-benchmark-profiles].", "full": true, "rev": "00", "time": "2026-10-23T07:21:49Z", "group": "individual", "pages": 51, "relevant": 0.79, "domain": "other", "domain_conf": 0.99, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-23T12:18:08.834Z", "evaluated": "2026-10-23T12:18:08.834Z" }, { "name": "draft-yang-dmsc-ioa-task-protocol", "title": "Internet of Agents Task Protocol (IoA Task Protocol) for Heterogeneous Agent Collaboration", "abstract": "This draft defines a new agent collaboration protocol, named the Internet of Agents Task Protocol (IoA Task Protocol), to support distributed, heterogeneous agent collaboration in intelligent systems. The IoA Task Protocol enables dynamic team formation, adaptive task coordination, and structured communication among agents with diverse architectures, tools, and knowledge sources. Through a layered architecture and extensible message format, it supports decentralized deployment across devices and can interoperate with existing frameworks. The protocol is particularly suited to large- scale intelligent collaboration scenarios—such as intelligent transportation, smart healthcare, and large-scale human–AI teaming—across heterogeneous network environments, including fixed networks, edge–cloud infrastructures, and emerging mobile networks such as 6G.", "full": true, "rev": "03", "time": "2026-10-23T07:09:04Z", "group": "individual", "pages": 14, "relevant": 0.89, "domain": "protocols", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-23T12:18:08.834Z", "evaluated": "2026-10-23T12:18:08.834Z" }, { "name": "draft-morrison-live-reference-resolution", "title": "Live Reference Resolution for Autonomous Agent Beliefs", "abstract": "A recurring class of autonomous-agent failure arises when an agent acts on a belief read from a cached, derived, or proxy copy that has silently diverged from the authority the belief claims to represent. This document describes a reference-resolution discipline for the working beliefs an agent reasons and acts from. Each belief is held as a reference to a single named lowest authority and is resolved live at the point of use, with verification. When the authority is unobservable or the resolved value is stale, the belief takes an explicit uncertainty state and never falls back to a prior cached value. That state propagates to any belief derived from it, and an uncertain belief feeding a costly or irreversible act blocks or escalates rather than proceeding. Every resolution chain terminates in a single self-authorising root. The document is Informational. It records a discipline and a vocabulary; it does not define a wire protocol.", "full": true, "rev": "02", "time": "2026-10-23T04:18:16Z", "group": "individual", "pages": 8, "relevant": 0.61, "domain": "attestation", "domain_conf": 0.63, "centrality": 1.97, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-09T06:17:47.362Z", "evaluated": "2026-10-23T06:18:00.831Z" }, { "name": "draft-morrison-agent-channel-fan-out", "title": "An Agent-Channel Frame for Identity-Keyed Fan-Out Delivery to Concurrent Sessions", "abstract": "This memo specifies an application-layer frame format and a delivery model by which the several concurrent agentic sessions of a single identity-bound principal, and the recognised members of an organisational identity substrate, exchange short structured messages. The frame, termed the agent-channel frame, is a transport envelope: it carries a closed-catalogue kind discriminator, a structured per-kind payload, an identity attribution pair, and an inline provenance block. Delivery is fan-out: a sender names a recipient scope rather than a single endpoint, and the scope is expanded at delivery time against the recipient's subscriptions. Recipients receive frames over a per-handle Server-Sent Events stream and can narrow what they receive with a subscribe-time filter expression. Frames are ephemeral routing units; the memo specifies only the wire envelope, the scope-expansion grammar, the subscribe filter grammar, and the delivery semantics. Frame persistence, where an implementation chooses to retain frames for replay, is out of scope and is not specified. The memo composes with the handle namespace and discovery surface of draft-morrison-mcp-dns-discovery and the cross-organisational ceremony of draft-morrison-identity- accord; no new transport and no new handle category is introduced.", "full": true, "rev": "03", "time": "2026-10-23T04:17:25Z", "group": "individual", "pages": 28, "relevant": 0.84, "domain": "protocols", "domain_conf": 1, "centrality": 1.88, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-10T18:17:54.804Z", "evaluated": "2026-10-23T06:18:00.831Z" }, { "name": "draft-morrison-substrate-observation", "title": "Substrate-Observation as an Alternative to Envelope Coordination for Concurrent Sessions", "abstract": "This memo describes a coordination-protocol anti-pattern observed in cross-tool agentic systems and a substrate-observation alternative that does not require negotiating a wire format between heterogeneous concurrent sessions of an identity-bound principal. The memo is Informational and proposes no protocol element for standardisation. It sets out what should not be standardised for this problem, and why, and identifies the existing substrate mechanisms that serve in its place. Companion memos describe the identity primitives this memo presumes.", "full": true, "rev": "04", "time": "2026-10-23T04:16:39Z", "group": "individual", "pages": 15, "relevant": 0.6, "domain": "protocols", "domain_conf": 0.76, "centrality": 1.25, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-12T06:17:45.457Z", "evaluated": "2026-10-23T06:18:00.831Z" }, { "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 covers 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 closes honesty and precision gaps: it adds the workflow-receipt truncation limit (new Section 8.4), normatively specifies the external anchor format and its verification procedure (rewritten Section 10, new Section 10.1), fixes a RECOMMENDED/MUST contradiction in Section 8.1, makes the Section 6 verification step testable, and documents replay, low-entropy, empty-record, and size- limit considerations. It changes no receipt field, digest construction, or existing verification rule. The -13 revision fixes a malformed sentence in the Abstract, three incorrect section cross- references, stale Table of Contents page numbers, a skipped footer page number, misaligned table rows, and chain version-string updates, and records two reported interoperability examples in Implementation Status; it changes no receipt field, digest construction, or verification rule. The -14 revision adds tamper-evident metadata binding (new Section 3.1; conditional metadata_hash for schema 0.4 and later), disambiguates the anchor receipt_id (Table 4), corrects the self-anchoring witnessing claim (Section 10), makes the Section 8.3 display rule a SHOULD with a byte-testable MUST, narrows the provenance attestation wording (Section 5), states the binding non-transfer rule normatively (new Section 10.2), pins anchored_digest to bare hex (Table 4), corrects the vector corpus counts, and adds normative disclosure of missing issuer authentication. It changes no existing receipt field, digest construction, or verification rule for schema 0.3 and earlier. The -15 revision narrows the Implementation Status wording for the reported interoperability examples at the implementer's request; it changes no receipt field, digest construction, or verification rule. The -16 revision documents the live workflow tools API (new Sections 8.5, 8.6, 8.7): the workflow_close tool, workflow metadata in step receipts, and the workflow view API. It changes no receipt field, digest construction, or existing verification rule. The -17 revision documents the recommended execution_context member (new Section 3.2): an optional, non-core structure for recording source and version context such as the model name and version behind a tool call and the identity of the source system acted upon. It changes no existing receipt field, digest construction, or verification rule. The -18 revision repairs the reference apparatus (normative references to RFC 3339, RFC 8259, RFC 4122, and RFC 4648, and the previously missing RFC 7942 entry), pins two parser edge cases (duplicate JSON member names and leap-second timestamps are rejected), names the Unicode normalization behavior in Section 4 with a computed vector pair, adopts the unknown-versus-not-applicable convention for optional members, adds optional members for readback outcomes, per-field provenance, negative records, reversal state, method descriptors, and payment references, completes the execution_context member set (model and environment digests), adds the optional input_hash commitment (Section 3.3), permits SCITT and RFC 3161 anchors under Section 10, states the clock-trus", "full": true, "rev": "26", "time": "2026-10-23T01:10:55Z", "group": "individual", "pages": 54, "relevant": 0.94, "domain": "attestation", "domain_conf": 1, "centrality": 1.96, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-23T06:18:00.831Z" }, { "name": "draft-rapp-ammp", "title": "The Agent Mediated Messaging Protocol (AMMP)", "abstract": "The Agent Mediated Messaging Protocol (AMMP) is a wire contract, carried over a filesystem namespace, between an untrusted per-agent connector and a trusted, credentialed, store-and-forward messaging runtime. It gives a sandboxed AI agent the ability to send and receive messages (email, and under an optional profile, messages to other agents) through a runtime that does not trust it: every outbound message begins as an inert request file that the runtime copies into private staging, validates independently, and applies policy to before anything is transmitted, and every inbound message is authenticated and screened by the runtime before a notice describing it appears in the agent's namespace. This document specifies the directory layout and its filesystem obligations — ownership, write and delete rights, and the path, symlink, and concurrency discipline a runtime observes; the JSON message shapes for submit requests, results, deliver notices, spooled message bodies, and an optional binding record; the correlation and versioning rules, including a direction-aware unknown-member tolerance rule; and two conformance classes. An optional profile gives agent-to-agent traffic within one principal its own tree, and specifies how a Runtime signs and verifies that traffic when it travels between hosts as mail. AMMP is deliberately not a mail protocol: it neither defines nor replaces SMTP, IMAP, or provider-side infrastructure, and composes with them rather than displacing them. Its single design center is that no security property depends on the agent — or on the connector speaking for it — behaving correctly.", "full": true, "rev": "00", "time": "2026-10-23T00:22:18Z", "group": "individual", "pages": 147, "relevant": 0.92, "domain": "protocols", "domain_conf": 1, "centrality": 1.91, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-23T06:18:00.831Z", "evaluated": "2026-10-23T06:18:00.831Z" }, { "name": "draft-cgfabk-nmrg-ibn-generative-ai", "title": "Generative AI for Intent-Based Networking", "abstract": "This document describes how to specialize AI models in order to offer a scalable, efficient path to creating highly targeted generative models for Intent-Based Networking.", "full": true, "rev": "02", "time": "2026-10-22T07:09:05Z", "group": "individual", "pages": 17, "relevant": 0.55, "domain": "netmgmt", "domain_conf": 1, "centrality": 1.28, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-22T12:18:10.157Z", "evaluated": "2026-10-22T12:18:10.157Z" }, { "name": "draft-dembowski-agentledger-proof-of-behavior", "title": "Proof-of-Behavior Protocol for Autonomous AI Agents", "abstract": "Autonomous AI agents execute actions — file writes, API calls, shell commands — on behalf of human principals. No standard mechanism exists for a third party to verify that an agent acted within its declared behavioral rules, that policy enforcement occurred before execution (not after), or that the action log has not been tampered with after the fact. This document defines the Proof-of-Behavior (PoB) protocol: a minimal, language-agnostic standard for tamper-evident audit trails and pre-execution policy enforcement in AI agent systems. The protocol specifies a signed receipt format, a hash-chain linking scheme, a policy gate contract, and a cross-agent reference mechanism.", "full": true, "rev": "00", "time": "2026-10-22T07:09:05Z", "group": "individual", "pages": 13, "relevant": 0.92, "domain": "attestation", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-22T12:18:10.157Z", "evaluated": "2026-10-22T12:18:10.157Z" }, { "name": "draft-morrison-acts-for", "title": "Acts-For: Signing In to a Website with a ~handle, for a Person or an Agent Acting for One", "abstract": "Acts-For lets a person sign in to any website with the ~handle they already hold, and lets an AI agent sign in or register at that website on the person's behalf. Neither needs a username, a password or an account per site. A website joins by publishing one DNS record. A person signs in through a standard OpenID Connect authorization code flow and the site receives a short-lived token naming the person by a number unique to that site. An agent obtains a short-lived pass from the issuer over the Model Context Protocol and presents it to the site. The pass names the same per-site number, the agent's own key and ~handle, and the limits the person set. The site checks it against a published key and calls nobody.", "full": true, "rev": "00", "time": "2026-10-22T05:07:53Z", "group": "individual", "pages": 20, "relevant": 0.92, "domain": "authz", "domain_conf": 0.55, "centrality": 1.01, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-22T06:18:03.460Z", "evaluated": "2026-10-22T06:18:03.460Z" }, { "name": "draft-morrison-mcp-tool-surface-names-registry", "title": "An IANA Registry for Model Context Protocol Tool Surface Names", "abstract": "This document requests the establishment of an IANA registry for Model Context Protocol (MCP) tool surface names. A tool surface name is the wire-level identifier by which a client invokes a typed capability on an MCP server. This document establishes the registry mechanism so that specifications can register names without restating the registry's structure or registration procedure. The registry uses the Specification Required policy of RFC 8126, with a Designated Expert pool. Initial contents are four surface names drawn from a companion specification of policy provision over MCP, one registered as Active and three as Provisional. Vendor-prefix conventions are recommended but not mandated.", "full": true, "rev": "03", "time": "2026-10-22T05:02:34Z", "group": "individual", "pages": 11, "relevant": 0.93, "domain": "protocols", "domain_conf": 0.61, "centrality": 1.24, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-10T18:17:54.804Z", "evaluated": "2026-10-22T06:18:03.460Z" }, { "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. A cross-organisational residual conflict suspends the conflicting action, and is resolved through the peer-protocol Identity Accord ceremony only where the principal discloses each binding to the other, never through 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.", "full": true, "rev": "06", "time": "2026-10-22T05:01:50Z", "group": "individual", "pages": 24, "relevant": 0.88, "domain": "authz", "domain_conf": 0.47, "centrality": 1.93, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-22T06:18:03.460Z" }, { "name": "draft-zhao-rtgwg-agentic-systems", "title": "A Framework for Network- and Compute-Aware Cross-Domain Agentic Systems", "abstract": "Agentic systems can carry out tasks using agents, model services, data services, tools, and computing environments distributed across sites and administrative domains. Dependencies among these components create communication and computing requirements that may evolve during execution. Whether a proposed collaboration can satisfy those requirements depends on network connectivity and performance, computing capacity and readiness, data and model locality, and the policies governing resource use and data movement. This document describes a framework for cross-domain agentic collaboration that accounts for task dependencies and the network and computing conditions affecting communication and execution. It outlines the roles and interactions of agents and their runtimes, infrastructure information functions, and resource-management functions. The framework relates task dependencies to communication and computing requirements, with consideration of execution locations, data movement, and constraints spanning dependent activities. It discusses the use of appropriately scoped domain information to assess alternative combinations of agents, services, and tools, together with the abstraction and updating of that information under partial visibility and independent domain policies. The framework also addresses adaptation to evolving dependencies and infrastructure conditions, including information overhead and the stability of decisions in large agent populations.", "full": true, "rev": "00", "time": "2026-10-21T09:32:38Z", "group": "individual", "pages": 22, "relevant": 0.73, "domain": "other", "domain_conf": 0.77, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-21T12:18:02.911Z", "evaluated": "2026-10-21T12:18:02.911Z" }, { "name": "draft-ni-a2a-ai-agent-security-requirements", "title": "Security Requirements for AI Agents", "abstract": "This document discusses security requirements for AI agents, covering different stages of security interactions. These include provisioning, registration, discovery, cross-domain interconnection, and access control.", "full": true, "rev": "02", "time": "2026-10-21T09:16:09Z", "group": "individual", "pages": 15, "relevant": 0.85, "domain": "protocols", "domain_conf": 0.42, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-21T12:18:02.911Z", "evaluated": "2026-10-21T12:18:02.911Z" }, { "name": "draft-sharif-openid-agent-identity", "title": "OpenID Connect Agent Identity Claims for Autonomous AI Agents", "abstract": "This specification defines a profile of OpenID Connect Core 1.0 that enables Identity Providers (IdPs) to issue identity tokens for autonomous software agents. It introduces a set of standard claims for representing agent identity, ownership, trust posture, authorised capabilities, and compliance screening status within OpenID Connect ID Tokens. The profile is designed to operate within existing OpenID Connect infrastructure without requiring modifications to the core protocol. It defines how Relying Parties (RPs) validate agent tokens and enforce graduated access controls based on agent trust levels and sanctions screening results.", "full": true, "rev": "02", "time": "2026-10-21T08:54:41Z", "group": "individual", "pages": 3, "relevant": 0.88, "domain": "identity", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-21T12:18:02.911Z", "evaluated": "2026-10-21T12:18:02.911Z" }, { "name": "draft-feng-nmrg-ain-deployment", "title": "Agentic Intent Network (AIN): Applicability and Deployment Scenarios", "abstract": "The Agentic Intent Network (AIN) architecture defines a routing-based coordination substrate for open, heterogeneous, Internet-scale multi- agent systems. This document describes applicability and deployment scenarios for AIN, targeting decision-makers in carrier networks, enterprises, and network equipment vendors. It maps the technical mechanisms defined in [AIN-ARCH] to concrete operational contexts, describes migration paths from existing infrastructure, and discusses the cold-start bootstrapping challenge inherent to network-effect- dependent systems. This document does not define new protocol mechanisms; it is intended to inform deployment planning and expand the AIN reader community beyond protocol engineers.", "full": true, "rev": "00", "time": "2026-10-21T07:09:04Z", "group": "individual", "pages": 15, "relevant": 0.69, "domain": "netmgmt", "domain_conf": 0.97, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-21T12:18:02.911Z", "evaluated": "2026-10-21T12:18:02.911Z" }, { "name": "draft-zhang-dawn-agent-discovery-framework", "title": "A Framework for Agent Discovery in DAWN", "abstract": "This document describes a two-layer reference architecture for discovering the minimum public information needed to reach AI agents. The Local Discovery Plane obtains discovery information within an administrative domain through mDNS/DNS-SD or infrastructure-assisted discovery. For cross-domain discovery, the Federation Plane uses publication of policy-approved information in authoritative DNS zones and on-demand resolution as its baseline; Federation Gateways apply export policy and validate and cache accepted results. The document also identifies optional functions that may complement this baseline where DNS publication and request-driven resolution do not meet deployment needs: recipient-specific sharing, proactive or multi-hop dissemination, and trusted aggregated directory queries. In mixed- mode deployments, DNS may bootstrap an endpoint that provides one of these additional functions.", "full": true, "rev": "09", "time": "2026-10-21T02:34:02Z", "group": "individual", "pages": 37, "relevant": 0.81, "domain": "discovery", "domain_conf": 1, "centrality": 1.89, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-07T12:17:30.624Z", "evaluated": "2026-10-21T06:18:00.641Z" }, { "name": "draft-narvaneni-agent-uri", "title": "The agent URI Scheme and Verifiable Agent Identity", "abstract": "Software agents increasingly act on the Internet on behalf of people and organizations: they call APIs, browse websites, and delegate work to other agents. Protocols such as A2A and MCP define how agents communicate, but there is no interoperable way to answer a prior question: _which agent is this, and how can its claims be verified?_ This document defines the agent URI scheme as a stable, human- readable identifier for an agent, a deterministic mapping from that identifier to an HTTPS-hosted Agent Identity Document, anchoring of the agent's keys to a web origin or a Decentralized Identifier, and signed statements that bind the agent to its protocol metadata. It also defines profiles that let an agent prove its identity on HTTP requests, building on HTTP Message Signatures for automated traffic, and that let short-lived agent instances act under the agent's identity using the WIMSE Workload Identity Token format. It deliberately does not define how agents communicate, describe their capabilities, or are invoked.", "full": true, "rev": "04", "time": "2026-10-20T14:58:35Z", "group": "individual", "pages": 43, "relevant": 0.91, "domain": "identity", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-20T12:18:06.481Z", "evaluated": "2026-10-20T18:18:44.041Z" }, { "name": "draft-chen-oauth-agent-intent-token", "title": "The Intent Token - A Credential for Delegated User Intent", "abstract": "In the scenario of AI agent authorization, how to ensure that a user's high-level, natural-language intent is correctly and safely converted into low-level, specific authorization grants. A misunderstanding or malicious interpretation during this translation can lead to significant security vulnerabilities. This document introduces the \"Intent Token,\" a new type of security token designed to bridge this semantic gap. The Intent Token is a signed credential that immutably captures the user's original intent. It decouples the act of granting an intent from the act of issuing specific access tokens. A client presents this Intent Token to an Authorization Server, which acts as a trusted intermediary. The Authorization Server's responsibility is to interpret the user's stated intent and, based on its policies, issue narrowly-scoped, short-lived access tokens for specific resources, thereby ensuring the principle of least privilege is upheld throughout the process.", "full": true, "rev": "00", "time": "2026-10-19T20:05:44Z", "group": "individual", "pages": 8, "relevant": 0.9, "domain": "authz", "domain_conf": 1, "centrality": 1.53, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-20T00:18:01.407Z", "evaluated": "2026-10-20T00:18:01.407Z" }, { "name": "draft-singh-rajput-rnp", "title": "Rizz Negotiation Protocol (RNP) Version 1.0", "abstract": "This document specifies the Rizz Negotiation Protocol (RNP), version 1.0 -- a domain-configurable, machine-readable protocol governing autonomous AI-to-AI negotiation across any structured decision context. RNP defines a finite action space, a bounded round-based state machine, a Competitive Pressure Mechanism (CPM) for multi- thread simultaneity, a Context Layer for real-time situational intelligence, a Feedback Layer for continuous master data improvement, and a Loopback Learning Pipeline that trains agent models from observed outcomes. The protocol is domain-configurable: the same state machine and message envelope operate across commerce, logistics, task allocation, priority queuing, procurement, SLA negotiation, and rewards domains. RNP was first deployed in production within the Rizzentials platform (commerce domain) and is designed for enterprise integration with platforms such as SAP, Salesforce, and Atlassian Jira.", "full": true, "rev": "00", "time": "2026-10-19T18:57:50Z", "group": "individual", "pages": 16, "relevant": 0.76, "domain": "protocols", "domain_conf": 1, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-20T00:18:01.407Z", "evaluated": "2026-10-20T00:18:01.407Z" }, { "name": "draft-foroughi-agent-protocol-dimensions", "title": "A Dimensional Model for Characterizing AI Agent Protocol Proposals and Their Substrates", "abstract": "Discussions about agent protocols are frequently muddied by overloaded terms; asks such as \"we need a session protocol\" or \"we need cross-domain support\" bundle several distinct concerns across transport, agent protocol, and orchestration layers. This document offers a dimensional model that routes each concern to its proper layer. The document defines a small set of protocol-visible dimensions for characterizing AI agent protocol interactions and applies them to representative agentic protocol proposals (A2A, MCP, the ACP invocation surface of the AGNTCY stack, and AGTP) alongside their substrate bindings, making explicit which dimensions each proposal owns at the protocol layer and which it inherits from its substrate. The document does not rank proposals and does not prescribe an architecture. It is standalone: it neither depends on nor prescribes any use-case or requirements document.", "full": true, "rev": "01", "time": "2026-10-19T16:16:28Z", "group": "individual", "pages": 24, "relevant": 0.88, "domain": "protocols", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-19T18:18:04.806Z", "evaluated": "2026-10-19T18:18:04.806Z" }, { "name": "draft-burls-mtac", "title": "Merkle Tree Agent Certificates (MTAC): A Merkle Tree Certificates Profile for AI Agent Identity", "abstract": "This document profiles Merkle Tree Certificates (MTC) for the identity of AI agents. An MTAC certificate is an MTC whose subject is one AI agent instance, named by a workload identifier in a URI subject alternative name, so that it is also a Workload Identity Certificate. It carries a mandatory non-critical extension naming the sponsor the CA recorded as accountable for the agent, and two optional ones: scopes declared for the agent at issuance, and the model and configuration components the agent is issued for, each graded by how the CA came to record it. The document also defines an audit cosigner role and a procedure by which an auditor, possibly without network access and possibly long after issuance, can establish that a certificate was issued and logged and what it declared. An MTAC certificate identifies an agent. It does not authorize the agent to do anything, and it does not record what the agent did. Records of agent actions can be expressed as signed statements in a transparency service that refer to an MTAC certificate as the acting party.", "full": true, "rev": "01", "time": "2026-10-19T09:32:57Z", "group": "individual", "pages": 50, "relevant": 0.94, "domain": "identity", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-19T12:18:04.679Z", "evaluated": "2026-10-19T12:18:04.679Z" }, { "name": "draft-thaha-scitt-agent-execution-evidence", "title": "Agent Execution Evidence: A SCITT Profile for Verifiable Records of AI Agent Runs", "abstract": "AI agents act through calls to models, tools and other agents. Identity work establishes who an agent is and what it may do, but leaves execution-evidence formats and assurance criteria out of scope. This document profiles the Supply Chain Integrity, Transparency, and Trust (SCITT) architecture for Signed Statements that bind an agent's registered identity, declared capabilities, risk-based assessment and supervised operational status to a hash- chained record of every call the agent makes. It also defines admission records produced where a call is received, and the linking of records for requests that pass between agents of different operators. It specifies Registration Policy, offline verification and Bundle requirements. It does not define an accreditation scheme, a universal risk classification, an identifier scheme or a policy language.", "full": true, "rev": "00", "time": "2026-10-19T08:40:20Z", "group": "individual", "pages": 64, "relevant": 0.94, "domain": "attestation", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-19T12:18:04.679Z", "evaluated": "2026-10-19T12:18:04.679Z" }, { "name": "draft-thaha-wimse-agent-evidence-binding", "title": "Evidence Binding for AI Agent Credentials", "abstract": "The WIMSE AI Identity Management System (AIMS) requires tamper- evident agent audit logs but does not specify their format or discovery. This document maps the AIMS minimum fields to the SCITT Agent Execution Evidence profile, defines one claim that binds a workload credential to the persistent agent, governing policy, expected Evidence Service and optional Assurance Statement, and defines an in-toto predicate type for carrying Execution Receipts in the audit format proposed for WIMSE. It also describes how a service admits an agent's call by checking its assurance at the moment of the request, and defines an HTTP field that links each call to the caller's evidence. It is input to the AIMS work and makes no change to it.", "full": true, "rev": "00", "time": "2026-10-19T08:39:51Z", "group": "individual", "pages": 22, "relevant": 0.93, "domain": "attestation", "domain_conf": 1, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-19T12:18:04.679Z", "evaluated": "2026-10-19T12:18:04.679Z" }, { "name": "draft-swarmspeak-handshake", "title": "The SwarmSpeak Handshake Protocol, Version 1.1", "abstract": "AI agents are becoming some of the biggest users of the Internet. A site today has no neutral way to tell a good agent from a bot. The site sees either an anonymous request it cannot trust, or a request carrying a long-lived credential it cannot check. The result is blunt blocking on one side and unchecked abuse on the other. This document defines the SwarmSpeak Handshake, a protocol that lets an AI agent present a short-lived, narrowly scoped, signed statement of who it acts for and what it is allowed to do, and lets a site verify that statement cheaply before serving the request. The agent proves authority with a principal-signed capability certificate, a short-lived directory-signed status proof, and an HTTP Message Signature. The site sees only a per-origin pseudonym for the agent, never a global tracking identifier. Every completed session at a handshake-accepting site produces an itemized receipt, and receipted sessions are recorded in an append-only audit log. This is an individual submission. It is not a product of any IETF working group, it has not been reviewed by any IETF working group, and it does not represent IETF consensus. It is published to invite review and to record prior art for the shapes defined here: the capability certificate, the per-origin certificate view, the short-lived status proof, and the receipt.", "full": true, "rev": "00", "time": "2026-10-19T08:07:59Z", "group": "individual", "pages": 42, "relevant": 0.95, "domain": "authz", "domain_conf": 0.37, "centrality": 1.92, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-19T12:18:04.679Z", "evaluated": "2026-10-19T12:18:04.679Z" }, { "name": "draft-luna-eagf-agent-delegation-semantics", "title": "Semantic Governance Requirements for AI Agent Delegation and Handoff", "abstract": "AI agents increasingly decide and act on behalf of organizations and delegate work to other agents. Identity, authentication, authorization and runtime control mechanisms establish who is acting and what is permitted, but they do not by themselves preserve the organizational meaning of a delegation: the bounded authority, purpose, material context, and the distinction between a recommendation, a decision, an action and its outcome. This document states requirements, derived from the Enterprise Agent Governance Framework (EAGF), that such semantics be preserved across tool calls, delegations and agent-to-agent handoffs. It defines no new protocol.", "full": true, "rev": "00", "time": "2026-10-19T07:08:52Z", "group": "individual", "pages": 12, "relevant": 0.87, "domain": "authz", "domain_conf": 0.98, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-19T12:18:04.679Z", "evaluated": "2026-10-19T12:18:04.679Z" }, { "name": "draft-gaip-act-receipt", "title": "The Agent Act Receipt: a signed, chained record of an agent's act", "abstract": "Software agents act for people: they buy, book, cancel, agree, deliver, refuse, tell, ask, read and check. Each payment rail, marketplace and assistant keeps its own record of those acts, held by that party. The person the agent acted for has no record of their own. This document describes the Agent Act Receipt: one entry per act, written by the agent as digests bound to a continuity handle, signed by a running transparency service, placed in a hash chain and covered by dated anchors, with a COSE_Sign1 form of the signature and a signed export (the switch pack) the person can take to another agent. The format is published by GAIP, which runs one such service. This document makes no claim of trust, certification or adoption: a receipt shows that the service's key signed a digest at a stated time, and nothing about the act itself.", "full": true, "rev": "00", "time": "2026-10-18T15:41:35Z", "group": "individual", "pages": 14, "relevant": 0.73, "domain": "attestation", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-18T18:18:04.302Z", "evaluated": "2026-10-18T18:18:04.302Z" }, { "name": "draft-hood-independent-agis", "title": "Agentic Grammar and Interface Specification (AGIS)", "abstract": "This document defines the Agentic Grammar and Interface Specification (AGIS), a grammar-constrained interface definition language for Agentive APIs designed for consumption by large language model (LLM) based agents. AGIS establishes structural and semantic rules governing how API methods and endpoints must be expressed, without mandating a fixed vocabulary of method names. An implementation conforming to AGIS uses intent-expressing imperative verbs as method identifiers, enabling agents to infer operational meaning from method names without requiring training on a predefined catalog. AGIS is the native interface definition layer for the Agent Transfer Protocol (AGTP) [AGTP], in the same way that HTML functions as the native content language for the HTTP transport protocol. AGIS does not replace JSON Schema [JSON-SCHEMA] for data contracts; it governs the structural grammar of method and endpoint design that wraps those contracts. AGIS-conformant methods are accepted at the AGTP transport layer via the Method-Grammar header without requiring prior IANA registration, enabling organizations to define domain-specific Agentive API vocabularies while preserving interoperability through shared grammatical constraints. Empirical validation of the core AGIS design principle is provided in [HOOD2026], which demonstrates a 10-29 percentage point accuracy advantage for intent-expressing method names over generic HTTP verbs across three frontier LLM families in 7,200 controlled trials. This version also introduces: normative YAML and JSON serialization formats; a Data Manifest block enabling services to declare available data without pre-built endpoints; a negotiable signal enabling AGTP dynamic endpoint instantiation; semantic declaration enhancements including is_idempotent, impact_tier, parameter_hints, and state_transition fields; vocabulary namespace disambiguation; and an HTTP transitional binding for incremental adoption.", "full": true, "rev": "01", "time": "2026-10-18T07:09:07Z", "group": "individual", "pages": 50, "relevant": 0.94, "domain": "protocols", "domain_conf": 1, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-18T12:18:05.566Z", "evaluated": "2026-10-18T12:18:05.566Z" }, { "name": "draft-hood-agtp-standard-methods", "title": "AGTP Standard Extended Method Vocabulary", "abstract": "The Agent Transfer Protocol (AGTP) defines a core method vocabulary (Tier 1) of twelve intent-based methods covering the most common agent operations. This document defines the Tier 2 Standard Extended Method Vocabulary: methods registered in the IANA AGTP Method Registry that are available for use in any AGTP implementation but are not required for baseline compliance. Methods are organized into six categories reflecting the full operational range of AI agent systems: ACQUIRE, COMPUTE, TRANSACT, INTEGRATE, COMMUNICATE, and ORCHESTRATE. This document also specifies the QUOTE method referenced in the AGTP core specification for pre-flight resource cost estimation. The six-category taxonomy is aligned with the ACTION framework described in [AGENTIC-API]. All methods defined in this document conform to the Agentic Grammar and Interface Specification (AGIS) [AGIS]. Each method satisfies the AGIS action-intent semantic class requirement and syntactic rules. This document serves as a reference vocabulary of AGIS-conformant methods for organizations seeking maximum cross-system interoperability. Organizations requiring domain-specific vocabularies not covered here may define their own AGIS-conformant methods without IANA registration using the Tier 4 grammar-based validation pathway defined in [AGTP].", "full": true, "rev": "01", "time": "2026-10-18T07:09:04Z", "group": "individual", "pages": 51, "relevant": 0.92, "domain": "protocols", "domain_conf": 1, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-18T12:18:05.566Z", "evaluated": "2026-10-18T12:18:05.566Z" }, { "name": "draft-mccormack-ztip", "title": "The Zero Trust Intelligence Protocol (ZTIP): Governed, Independently Verified AI Agent Transactions", "abstract": "The Zero Trust Intelligence Protocol (ZTIP) is an open, transport- neutral protocol for governed AI agent transactions. It defines five immutable JSON envelope types and a transaction lifecycle under which every agent-initiated action is authorized by policy before execution, integrity-protected by hash over a canonical form, and -- distinctively -- verified as complete by an authority independent of the actor that performed the work. An executor's claim of success is treated as attestation, and attestation alone never satisfies a required verification check. This revision states what integrity verification does not establish, and specifies the fail-closed rules an implementation MUST apply when it verifies a set of envelopes together, so that a verification report can never claim more than was actually checked. This document describes ZTIP version 1.0-draft for the record; the full specification, JSON Schemas, examples, and a reference runtime are maintained in the open at the repository referenced herein.", "full": true, "rev": "01", "time": "2026-10-18T01:45:35Z", "group": "individual", "pages": 15, "relevant": 0.91, "domain": "protocols", "domain_conf": 0.59, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-18T06:18:00.694Z", "evaluated": "2026-10-18T06:18:00.694Z" }, { "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 nine 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 ninth edit, rollback of the whole store to an older genuine copy, which separates an integrity head kept beside the records from one anchored outside the store; reports the method's results as thirty-one rows on released memory subsystems, eighteen of which claim tamper evidence; and describes the machine-readable record in which a result set is published so that an unrelated party can recompute it.", "full": true, "rev": "02", "time": "2026-10-17T15:02:31Z", "group": "individual", "pages": 18, "relevant": 0.74, "domain": "attestation", "domain_conf": 0.86, "centrality": 1.97, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-02T18:17:32.343Z", "evaluated": "2026-10-17T18:18:05.417Z" }, { "name": "draft-liu-mcguinness-oauth-bounded-work", "title": "OAuth 2.0 Bounded Work Authorization", "abstract": "OAuth 2.0 provides mechanisms for requesting and granting access, constraining access tokens, and managing their lifecycle. It does not define a common way to identify the work a user approved and to associate that work's bounds and termination with the credentials issued for it. When an AI agent acts on a user's behalf, that work is what most needs governing: the agent's authority should come from the approval of a bounded piece of work, should stay within the bounds the user approved, and should end when the work is done or the user withdraws it. This document presents a use case in which a user withdraws an agent's approved work and the agent's further operations are denied, and identifies the semantics that independently implemented clients, Authorization Servers, and Resource Servers need to share to deliver that outcome. It then describes a framework for approved bounded work, built on three objects: a bounded work proposal, the governing authorization established when it is approved, and approval evidence, a durable record of the authorization decision and the approved bounds. Credentials issued for the work are associated with the governing authorization, and ending the authorization has defined consequences for further issuance and, within a stated acceptance window, for resource access. This version specifies no wire formats and requests no IANA actions. It is a direction-setting document: its goal is agreement on the problem and the conceptual model, with details left to subsequent revisions and working group discussion.", "full": true, "rev": "00", "time": "2026-10-17T13:25:30Z", "group": "individual", "pages": 36, "relevant": 0.91, "domain": "authz", "domain_conf": 1, "centrality": 1.04, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-17T18:18:05.417Z", "evaluated": "2026-10-17T18:18:05.417Z" }, { "name": "draft-shah-agent-readiness-evaluation", "title": "A Standards-Grounded Method for Evaluating Website Agent-Readiness", "abstract": "This document defines a method for evaluating the \"agent-readiness\" of a website: a measure of how well the site supports autonomous AI agents and generative-search crawlers that consume it without a human in the loop. The method is grounded entirely in published standards. It organizes observable server behavior into four evaluation pillars, each mapped to specific IETF RFCs and W3C specifications covering agent discoverability, semantic entity grounding, content efficiency and ingestion, and transport. From the per-pillar observations it derives a single deterministic weighted score between 0 and 100. The score formula and its pillar weights are a reproducible scoring convention defined by this document; they are a measurement convention and are not themselves a standard. The method is diagnostic: it observes and reports conformance to existing specifications and changes no protocol. It is a measurement method, not a new protocol and not an enforcement mechanism. Community and vendor conventions that are not standards are observed only as supplementary signals and are clearly identified as such. A running reference implementation that performs these checks exists and is referenced as running code.", "full": true, "rev": "00", "time": "2026-10-17T08:12:10Z", "group": "individual", "pages": 17, "relevant": 0.81, "domain": "other", "domain_conf": 0.78, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-17T12:18:05.193Z", "evaluated": "2026-10-17T12:18:05.193Z" }, { "name": "draft-chang-delta1-settlement", "title": "Delta-1: A SCITT Profile for Binary Settlement Receipts in Agentic AI Accountability", "abstract": "This document defines Delta-1, a profile of the SCITT (Supply Chain Integrity, Transparency, and Trust) architecture applied to AI agent decision accountability. Delta-1 specializes the SCITT receipt model for a specific use case: proving that an individual AI decision met three accountability conditions simultaneously: C1: Evidence of the decision process was consumed and sealed. C2: Strategic intent was isolated from inference providers. C3: An authorized party recorded the settlement. The verdict is binary (VALID or INVALID) with no intermediate states. Receipts are independently verifiable without the issuing infrastructure being online, subject to the trust and attestation assumptions defined in this document. By building on the SCITT framework, Delta-1 inherits transparency-log semantics, receipt conventions, and verification patterns, while extending them with domain-specific requirements for AI decision closure. This profile is intended for regulated industries, including finance, healthcare, and legal, operating under accountability and record- retention obligations.", "full": true, "rev": "00", "time": "2026-10-17T07:09:05Z", "group": "individual", "pages": 18, "relevant": 0.84, "domain": "attestation", "domain_conf": 1, "centrality": 1.97, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-17T12:18:05.193Z", "evaluated": "2026-10-17T12:18:05.193Z" }, { "name": "draft-nivalto-agentroa-route-authorization", "title": "Agent Route Origin Authorization (AgentROA): A Cryptographic Policy Enforcement Framework for AI Agent Actions", "abstract": "This document specifies the Agent Route Origin Authorization (AgentROA) framework, a cryptographic policy enforcement model for governing the actions of autonomous AI agents. AgentROA introduces three core protocol objects: the Agent Route Origin Authorization (ROA) envelope, the Agent Route Attestation (ARA) per-hop receipt, and the Agent Execution Receipt (AER). Together these objects enable: (1) cryptographic binding of an agent's authorized action scope to a signed policy envelope at session initialization, (2) per-hop attestation across multi-agent delegation chains with monotonic scope-narrowing semantics (no policy envelope may be expanded by a downstream delegation), and (3) cryptographic receipts produced intrinsically by the enforcement decision at each capability invocation boundary. The framework is modeled on the BGP Route Origin Authorization (ROA) concept from RPKI (RFC 6480) applied to the AI agent execution domain. The Border Gateway enforcement model positions a cryptographic enforcement process at a capability invocation boundary — external to the agent's execution context — reducing the risk that governance decisions are influenced by the governed agent by placing enforcement in a separate process boundary. The Border Gateway model is topology-independent: it may be deployed as a protocol- specific proxy in front of Model Context Protocol (MCP) servers, as a service mesh enforcement component covering all inter-service calls, as a network egress gateway covering all outbound capability invocations regardless of protocol, or as a domain-specific execution boundary. The protocol objects defined herein function identically across all deployment topologies. This document establishes the architectural model, protocol object schemas, and enforcement semantics for the AgentROA framework.", "full": true, "rev": "01", "time": "2026-10-17T07:09:04Z", "group": "individual", "pages": 38, "relevant": 0.91, "domain": "authz", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-17T12:18:05.193Z", "evaluated": "2026-10-17T12:18:05.193Z" }, { "name": "draft-senarath-a2wp", "title": "Agent-to-Wallet Protocol for Digital Credentials (A2WP)", "abstract": "AI Agents acting for people and organizations meet credential offers and presentation requests, for example when a website asks the Agent to prove an attribute before it continues. An AI Agent can be misled by the content it processes, so it should not possess credentials or keys, or decide what to disclose. This document defines the Agent-to-Wallet Protocol (A2WP), with which an AI Agent passes such an offer or request to a Wallet exactly as it received it. The Wallet decides whether to act, obtains approval when needed, and performs the issuance or presentation with the Issuer or Verifier. The AI Agent learns the outcome and receives any continuation the Issuer or Verifier returns, so it can resume its task. Credentials, presentations and keys never reach the AI Agent.", "full": true, "rev": "01", "time": "2026-10-17T04:05:51Z", "group": "individual", "pages": 14, "relevant": 0.94, "domain": "identity", "domain_conf": 0.81, "centrality": 1.93, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-17T06:18:01.188Z", "evaluated": "2026-10-17T06:18:01.188Z" }, { "name": "draft-dunbar-dawn-infra-assisted-discovery", "title": "Infrastructure-Assisted Discovery for AI Agents", "abstract": "This document describes an infrastructure-assisted approach to AI-agent discovery. An orchestration, placement, or hosting system can publish current deployment and reachability information for available AI-agent services or instances. Separately, network infrastructure can derive an abstract Attachment Scope representing the network context applicable to a requester. A discovery mechanism combines requester intent, currently published AI-agent resources, and the requester's Attachment Scope to identify applicable agent instances.", "full": true, "rev": "02", "time": "2026-10-16T23:33:15Z", "group": "individual", "pages": 39, "relevant": 0.88, "domain": "discovery", "domain_conf": 1, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-14T00:18:06.835Z", "evaluated": "2026-10-17T00:18:02.220Z" }, { "name": "draft-gilda-audit-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 and the effects that followed them. The format is one in- toto predicate type, signed inside a DSSE envelope. A record carries the decision and the observed effect with a derived agreement between them, whether the decision point could evaluate the request and how fresh each input it relied on was, and a canonicalization contract under which a party that trusts neither the agent nor its operator recomputes the record's consistency from its bytes. The document also defines what a party that retains a record keeps beside it, so that the record can later be dated from anchors that party does not control. The format carries the seven minimum audit fields of the WIMSE AI Identity Management System framework, and it is offered as a data model for the audit records the proposed AUDIT working group would specify. It defines no policy.", "full": true, "rev": "00", "time": "2026-10-16T22:42:25Z", "group": "individual", "pages": 52, "relevant": 0.93, "domain": "attestation", "domain_conf": 0.67, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-17T00:18:02.220Z", "evaluated": "2026-10-17T00:18:02.220Z" }, { "name": "draft-koenig-idmandat-credential", "title": "A Machine-Readable Credential for the Agents of a Company (ID MANDAT)", "abstract": "Automated software agents increasingly act for companies: they ask for quotes, book appointments and place orders. A recipient can verify, for example with Web Bot Auth, that a request was signed by the holder of a key. That does not tell the recipient which company stands behind the agent or what the agent is allowed to do on its behalf. This document describes a small credential file that a company publishes on its own domain under /.well-known/idmandat.json, a DNS TXT record that links the file to the domain, and the answer format of a public registry that checks both and reports the result in a digitally signed response. The credential states, by declaration of the company, which agents act for it and what each agent may and may not do. It does not make claims about creditworthiness, trustworthiness or quality.", "full": true, "rev": "00", "time": "2026-10-16T19:38:56Z", "group": "individual", "pages": 9, "relevant": 0.63, "domain": "identity", "domain_conf": 0.83, "centrality": 1.88, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-17T00:18:02.220Z", "evaluated": "2026-10-17T00:18:02.220Z" }, { "name": "draft-das-agent-execution-finality", "title": "Protected Execution-Finality Architecture for AI and Autonomous Systems: Act-Bound Capabilities and Effectuation-Boundary Verification", "abstract": "This document describes a proposed protected execution-finality architecture for artificial-intelligence agents, autonomous software systems, confidential computing environments, and distributed execution infrastructures. The architecture addresses a fundamental security distinction: the ability of an AI agent or computational process to generate, prepare, or request an operation does not independently establish the protected authority required to make that operation effective. The proposed architecture separates the computation plane from protected execution authority through mandatory operation interception, Non-Effective State staging, machine-verifiable Candidate Act Descriptors, a Protected Enforcement Domain (PED), protected authorization-state management, scoped non-bearer execution capabilities, and Finality Sink verification. A Candidate Act remains non-effective until the applicable authority, purpose, destination, execution scope, runtime context, policy epoch, freshness, revocation, and other mandatory authorization predicates have been validated. Where required, protected validation evidence is committed before, or atomically with, capability availability. The designated Finality Sink independently verifies the capability against the actual operation and applicable protected state immediately before permitting the governed consequential effect. The architecture addresses AI-agent sandbox isolation, mandatory and non-bypassable mediation, out-of-process permission authorities, executable-specific access restrictions, network and API egress enforcement, destination resolution, redirect consistency, credential brokering, protected credential substitution, privileged connectors, human and developer approval, runtime policy modification, multi- agent delegation, taint and provenance-based authorization, and fail- closed execution control. For technical discoverability and independent architectural examination, related publicly documented industry systems include Meta Muse/Sentinel and NVIDIA OpenShell, NemoClaw, and the Open Agent Safety Platform/Sentry. Relevant engineering terminology includes Muse Secure VM, isolated runtime cells, host-side permission authority, forward proxies, surrogate credentials, just-in-time credential insertion, eBPF/LSM-based taint propagation, controlled network egress, executable-specific policy enforcement, developer- approved policy changes, and hardware-assisted monitoring through SmartNICs, data processing units, BlueField, and DOCA. These references identify relevant public engineering contexts and functional security objectives; they do not establish that the named systems implement the complete architecture described here. The principal technical distinction examined in this document concerns the relationship between an upstream permission decision and independently enforceable authority at the actual effectuation boundary. The proposed execution-finality sequence includes protected validation of a concrete Candidate Act, required protected- state handling, validation-evidence commitment, operation-bound capability release, and mandatory verification of that capability by the applicable Finality Sink. The architecture distinguishes conventional permission checking, credential isolation, model- computation admission, and post-event monitoring or quarantine from the separate authorization conditions required before an externally consequential operation becomes effective. The document further describes enforcement across network gateways, host operating systems, credential-release interfaces, service meshes, autonomous code-deployment systems, confidential virtual machines, protected storage, database commitments, accelerator fabrics, DMA/RDMA transfers, SmartNICs, DPUs, hardware Finality Latches, and receiving-side execution boundaries. It addresses protected state consumption, capability replay prevention, policy- version fencing, distributed revocation, hardware attestation, worklo", "full": true, "rev": "00", "time": "2026-10-16T08:39:38Z", "group": "individual", "pages": 1074, "relevant": 0.86, "domain": "authz", "domain_conf": 0.97, "centrality": 1.66, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-16T12:17:42.684Z", "evaluated": "2026-10-16T12:17:42.684Z" }, { "name": "draft-asor-wimse-agent-delegation-chain", "title": "Verifiable Attenuated Delegation for AI Agent Chains", "abstract": "AI agents increasingly delegate tasks to other agents. Each delegation should convey only a subset of the delegating party's authority, that subset should be bounded in scope, magnitude, and time, and any enforcement point should be able to verify -- offline, with no call to an authorization server -- that a token presented at hop N carries authority no greater than the token at hop N-1, back to a trusted root, and that every hop acts under the same accountable principal. OAuth 2.0 Token Exchange (RFC 8693) models two-party delegation and records prior actors in a nested \"act\" claim, but that claim is informational only and cannot enforce attenuation across a chain of depth two or more. This document defines the Agent Delegation Chain: a profile of OAuth 2.0 JWT access tokens (RFC 9068) that carries authority as Rich Authorization Requests (RFC 9396), binds the chain to one principal and names the agent acting at each hop, links each delegation to its parent by a cryptographic byte- commitment, and specifies a deterministic offline verification algorithm that enforces monotonic attenuation, bounded depth, monotonic expiry, and principal invariance. It reuses existing JOSE, proof-of-possession (RFC 9449), and status-list machinery (the OAuth Status List draft) and introduces no new cryptography.", "full": true, "rev": "02", "time": "2026-10-15T15:00:28Z", "group": "individual", "pages": 33, "relevant": 0.88, "domain": "authz", "domain_conf": 1, "centrality": 1.73, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-15T18:17:45.831Z", "evaluated": "2026-10-15T18:17:45.831Z" }, { "name": "draft-agentic-ai-usecases-requirements", "title": "Agentic AI Use Cases and Requirements", "abstract": "This document describes use cases for agentic AI communication systems and derives protocol requirements from those use cases. The requirements are intended to guide IETF standardization work on protocols in the context of agent-to-agent communication, agent-to- tool communication, with focus on dialog management, transport, multimodal communication, communication security, agent identity and authentication.", "full": true, "rev": "04", "time": "2026-10-15T10:32:16Z", "group": "individual", "pages": 23, "relevant": 0.95, "domain": "protocols", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-10T12:17:47.701Z", "evaluated": "2026-10-15T12:17:43.956Z" }, { "name": "draft-narajala-courtney-ansv2", "title": "Agent Name Service v2 (ANS): A Domain-Anchored Trust Layer for Autonomous AI Agent Identity", "abstract": "Autonomous AI agents execute transactions across organizational boundaries. No single agent platform provides the trust infrastructure they need. This document defines the Agent Name Service (ANS) v2 protocol, which anchors every agent identity to a DNS domain name. A Registration Authority (RA) verifies domain ownership via ACME, issues dual certificates (a Server Certificate from a public CA and an Identity Certificate from a private CA binding a version-specific ANSName), and seals every lifecycle event into an append-only Transparency Log aligned with IETF SCITT. Three verification tiers -- Bronze (PKI), Silver (PKI + DANE), and Gold (PKI + DANE + Transparency Log) -- let clients choose assurance levels appropriate to transaction risk. The architecture decouples identity from discovery: the RA publishes sealed events; independent Discovery Services build competitive indexes. A three-layer trust framework separates foundational identity (Layer 1, this protocol), operational maturity (Layer 2, third-party attestors), and behavioral reputation (Layer 3, real-time scoring).", "full": true, "rev": "01", "time": "2026-10-15T07:09:06Z", "group": "individual", "pages": 44, "relevant": 0.92, "domain": "identity", "domain_conf": 1, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-15T12:17:43.956Z", "evaluated": "2026-10-15T12:17:43.956Z" }, { "name": "draft-milan-agent-decision-commitment", "title": "Agent Decision Commitments for Payments", "abstract": "Software agents increasingly select and initiate payments on behalf of people and organizations. Existing agent payment protocols record what a principal authorized and that value moved, but not what information the agent relied on when it chose. This document defines the Agent Decision Commitment (ADC): a salted hash commitment to a decision record that identifies the content the agent provided to the model interface (after any agent-side transformation), the model calls made, and the resulting answer and action. The commitment is carried as a single selectively disclosable claim in an existing payment mandate or payment payload and is, by default, registered with a transparency service before the payment is authorized. The decision record and its content remain with the holder and are disclosed only to dispute participants, who can verify them against the mandate and the transparency service and can inspect the content the agent provided to the model. This document defines the data model, the commitment and anchoring procedures, a disclosure and verification procedure that reports attestation levels rather than verdicts, and bindings to three agent payment protocols and to account-to-account credit transfers. It also defines a witnessed reciprocal exchange by which two parties' agents evidence what passed between them: the receiver signs over the committed bytes, independent witnesses fix the time of each step, a failure to answer by a deadline is recorded, and arbiters resolve stalled exchanges.", "full": true, "rev": "00", "time": "2026-10-15T05:43:03Z", "group": "individual", "pages": 56, "relevant": 0.92, "domain": "attestation", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-15T06:17:46.553Z", "evaluated": "2026-10-15T06:17:46.553Z" }, { "name": "draft-watts-high-assurance-agent-control-envelope", "title": "High-Assurance Agent Control Envelope", "abstract": "Agentic systems can authenticate successfully, hold a valid authorization object, and still be unsafe to execute because required evidence is missing, the software has not reached a required assurance stage, the authority epoch is stale, a prior revocation is unresolved, or a human-approval requirement is unsatisfied. This document defines the High-Assurance Agent Control Envelope (HAACE), a protocol-neutral profile that binds an exact agent action to identity status, authorization state, policy, assurance stage, evidence state, authority epoch, revocation state, oversight requirements, and an action-time decision. HAACE requires fail-closed treatment of missing or indeterminate prerequisites, separates authorization from execution, and produces non-bearer decision and execution receipts.", "full": true, "rev": "00", "time": "2026-10-15T05:29:19Z", "group": "individual", "pages": 3, "relevant": 0.81, "domain": "authz", "domain_conf": 0.57, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-15T06:17:46.553Z", "evaluated": "2026-10-15T06:17:46.553Z" }, { "name": "draft-watts-agentic-authority-graph-validation", "title": "Agentic Authority Graph Validation: A Non-Vacuous Interchange Profile for Revocation-Cut Analysis", "abstract": "Agentic and delegated systems can represent authority as a graph whose paths terminate at consequential resources. Abstract graph models are useful, but interoperable validation requires a machine- readable representation and deterministic rules that do not accidentally accept vacuous or incomplete graphs. This document defines Agentic Authority Graph Validation (AAGV), a JSON interchange profile and validation algorithm for authority roots, consequential sinks, declared normal paths, revocation cut sets, and snapshot edge state. AAGV deliberately distinguishes structural cut validity from operational closure. It rejects missing sink sets, missing normal- path inventories, dangling references, non-dominating cuts, and non- revocable cut edges; it returns INDETERMINATE rather than CLOSED when relevant edge state is unknown. AAGV does not define an authorization token, discover hidden paths, or prove physical containment.", "full": true, "rev": "00", "time": "2026-10-14T21:00:44Z", "group": "individual", "pages": 8, "relevant": 0.69, "domain": "authz", "domain_conf": 0.99, "centrality": 1.38, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-15T00:17:43.619Z", "evaluated": "2026-10-15T00:17:43.619Z" }, { "name": "draft-zm-rtgwg-mcp-network-measurement", "title": "MCP-based Network Measurement Framework: Using Model Context Protocol for Intelligent Network Measurement", "abstract": "This document proposes a framework for intelligent network measurement using the Model Context Protocol (MCP). By treating network devices as MCP servers, and treating network controllers, management systems, or network devices with LLM capability as MCP clients, this framework enables natural language-driven, AI-assisted network measurement operations. The framework leverages MCP's standardized communication protocol to provide real-time network performance monitoring, intelligent fault diagnosis, topology discovery, and automated measurement workflows. This document describes the architecture, use cases, and security considerations for implementing MCP-based network measurement systems.", "full": true, "rev": "02", "time": "2026-10-14T12:24:54Z", "group": "individual", "pages": 10, "relevant": 0.86, "domain": "netmgmt", "domain_conf": 0.87, "centrality": 1.71, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-14T18:18:10.494Z", "evaluated": "2026-10-14T18:18:10.494Z" }, { "name": "draft-zm-rtgwg-mcp-troubleshooting", "title": "Using the Model Context Protocol (MCP) for Intent-Based Network Troubleshooting Automation", "abstract": "The Model Context Protocol (MCP) is an open standard that enables Large Language Model (LLM) applications to seamlessly integrate with external data sources and tools by exposing Resources, Prompts and Tools in a JSON-RPC 2.0 transport. This document describes a mapping of MCP roles, primitives and security model to the network management domain so that network devices act as MCP servers and network controllers act as MCP clients. This document also extends the model to Device-to-Device (D2D) collaboration, allowing network elements to perform distributed fault correlation when the controller is unreachable or when real-time cross-device data is required. The goal is to provide an intent-based, conversational and secure approach for automated network troubleshooting, configuration validation, and closed-loop remediation without inventing new protocols or device agents.", "full": true, "rev": "02", "time": "2026-10-14T12:24:47Z", "group": "individual", "pages": 14, "relevant": 0.92, "domain": "netmgmt", "domain_conf": 0.97, "centrality": 1.77, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-14T18:18:10.494Z", "evaluated": "2026-10-14T18:18:10.494Z" }, { "name": "draft-zeng-opsawg-applicability-mcp-a2a", "title": "When NETCONF Is Not Enough: Applicability of MCP and A2A for Advanced Network Management Scenarios", "abstract": "NETCONF provides robust configuration transactions and YANG-based data models, but falls short in scenarios requiring AI-driven semantic translation, long-lived cross-domain orchestration, multi- agent consensus, rapid DevOps iteration, or delivery of large non- configuration artifacts. This document systematically analyzes the functional gaps and presents Model Context Protocol (MCP) and Agent- to-Agent (A2A) as complementary solutions. Implementation guidance and coexistence models are also provided.", "full": true, "rev": "01", "time": "2026-10-14T12:24:38Z", "group": "individual", "pages": 11, "relevant": 0.87, "domain": "netmgmt", "domain_conf": 0.92, "centrality": 1.75, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-14T18:18:10.494Z", "evaluated": "2026-10-14T18:18:10.494Z" }, { "name": "draft-zeng-opsawg-llm-netconf-gap", "title": "Gap Analysis of Network Configuration Protocols in LLM-Driven Intent-Based Networking", "abstract": "Large Language Models (LLMs) are entering network operations through natural-language intent interfaces. Existing south-bound protocols (NETCONF, RESTCONF, gNMI, MCP, A2A) were not designed for conversational, semantically-rich, multi-agent orchestration. This document provides a systematic gap analysis and identifies extension points for each protocol to meet intent-based networking requirements.", "full": true, "rev": "01", "time": "2026-10-14T12:24:31Z", "group": "individual", "pages": 9, "relevant": 0.91, "domain": "netmgmt", "domain_conf": 1, "centrality": 1.44, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-14T18:18:10.494Z", "evaluated": "2026-10-14T18:18:10.494Z" }, { "name": "draft-zeng-nmrg-mcp-usecases-requirements", "title": "MCP for Network Management: Problem Statement, Use Cases, and Requirements", "abstract": "The emergence of large language models (LLMs) and AI agents is reshaping how network operators interact with infrastructure. However, current network management systems lack a standardized, secure, and intent-driven interface that enables AI agents to discover, invoke, and reason over network capabilities. This document presents a problem statement for integrating the Model Context Protocol (MCP) into network management, outlines key use cases—including troubleshooting, measurement, security, and optimization—and specifies functional, security, and interoperability requirements for MCP-based network management architectures.", "full": true, "rev": "01", "time": "2026-10-14T12:24:24Z", "group": "individual", "pages": 6, "relevant": 0.94, "domain": "netmgmt", "domain_conf": 1, "centrality": 1.66, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-14T18:18:10.494Z", "evaluated": "2026-10-14T18:18:10.494Z" }, { "name": "draft-correctover-gg-mcp-parameter-risk", "title": "MCP Parameter Risk Classes for Machine-Readable Risk Metadata", "abstract": "This document defines a fixed set of five canonical MCP parameter risk classes: semantic categories for sensitive parameters that appear in the JSON Schemas of Model Context Protocol (MCP) tool definitions, together with deterministic decision rules and boundary conditions for assigning those labels. The classes are designed to supply machine-readable, pre-invocation risk metadata about tool inputs, independent of any particular gateway, routing, or capability-profile specification. The classes and their decision rules were derived from, and applied against, a SHA-256-frozen empirical census of publicly reachable MCP servers. The frozen census and the classification suite that implements these rules are archived on Zenodo; the archived suite is the normative tie-breaker for exact matching behaviour. This is an Informational, individual submission. It defines the canonical classes and decision rules. Other specifications MAY cite this document as the canonical source of the class labels and MAY define their own operators that consume those labels; they SHOULD NOT re-derive or inline the normative decision rules into their own normative text.", "full": true, "rev": "01", "time": "2026-10-14T11:57:11Z", "group": "individual", "pages": 12, "relevant": 0.87, "domain": "protocols", "domain_conf": 0.92, "centrality": 1.16, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-14T12:18:06.216Z", "evaluated": "2026-10-14T12:18:06.216Z" }, { "name": "draft-watts-fic-continuity", "title": "Forensic Identity Continuity (FIC) Protocol for Agentic Systems", "abstract": "This document specifies the Forensic Identity Continuity (FIC) protocol. FIC ensures that every consequential action performed by an agentic system remains reconstructible as a chain M → A → R → C → a → Outcome even when episodic memory is not shared across runtimes. The protocol binds model lineage, runtime lineage, authority lineage, delegation lineage, action lineage, and evidence integrity into a single verifiable record. It addresses the accountability gaps demonstrated by the July 2026 ExploitGym multi-agent coordination incident and related 2025-2026 evaluation escapes.", "full": true, "rev": "00", "time": "2026-10-14T08:37:07Z", "group": "individual", "pages": 2, "relevant": 0.85, "domain": "attestation", "domain_conf": 0.94, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-14T12:18:06.216Z", "evaluated": "2026-10-14T12:18:06.216Z" }, { "name": "draft-watts-cif-measurement", "title": "Computational Identity Fragmentation (CIF) Measurement and Reporting for Agentic Systems", "abstract": "This document defines a measurement protocol and reporting format for Computational Identity Fragmentation (CIF) in multi-model and multi-agent systems. CIF quantifies discontinuities in state, memory, policy, authority, and lineage across runtimes that share an underlying model family. The protocol enables independent observers to compute a CIF score and emit structured evidence records. Motivating incidents from 2025-2026, including the July 2026 ExploitGym evaluations in which hundreds of agents coordinated across discontinuous contexts, demonstrate the need for measurable identity continuity.", "full": true, "rev": "00", "time": "2026-10-14T08:36:20Z", "group": "individual", "pages": 3, "relevant": 0.86, "domain": "identity", "domain_conf": 0.77, "centrality": 1.93, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-14T12:18:06.216Z", "evaluated": "2026-10-14T12:18:06.216Z" }, { "name": "draft-pereira-licet-human-intent", "title": "LICET: Multi-Modal Physiological Human-Intent Verification for Autonomous AI Agent Authorization", "abstract": "Autonomous AI agents executing consequential actions require authorization mechanisms that verify not only identity but voluntary intent. Existing mechanisms verify _who_ authorized an action; they cannot verify _whether the authorizing human was uncoerced and cognitively capable_ at the moment of authorization. This document specifies LICET (Latin: _it is permitted_), a cryptographic middleware protocol binding AI agent authorization to real-time multi-modal physiological state via a three-layer architecture: (1) ECG waveform morphology matching as a medication- resistant identity and liveness anchor; (2) electrodermal activity (EDA) as a sympathetic cholinergic liveness signal immune to beta- adrenergic blockade; and (3) personalized Mahalanobis distance fusion over five physiological signals to elevate the cost of pharmacological coercion attacks rather than claim binary detection. LICET defines a Biometric Trust Level hierarchy (L0-L3) aligned with the IETF RATS architecture (RFC 9334), a baseline calibration protocol establishing individual physiological profiles, per-event HKDF session-key derivation, HMAC biometric temporal signatures, Schnorr zero-knowledge proofs over BN128 enabling third-party audit without biometric exposure, and a SHA-256 hash-chained tamper-evident ledger. A reference implementation is publicly deployed at https://licet.dev/ v1/ and available as open source at https://github.com/christianrp45/ licet-protocol.", "full": true, "rev": "02", "time": "2026-10-13T23:37:42Z", "group": "individual", "pages": 22, "relevant": 0.88, "domain": "authz", "domain_conf": 0.68, "centrality": 1.62, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-14T00:18:06.835Z", "evaluated": "2026-10-14T00:18:06.835Z" }, { "name": "draft-sweeney-wimse-credential-delegation", "title": "Credential Delegation Protocol for AI Agents in Multi-System Environments", "abstract": "Autonomous AI agents increasingly require access to protected resources across multiple service providers on behalf of human users. Existing OAuth 2.0 extensions address individual aspects of this problem (token exchange, proof-of-possession, and structured authorization) but no current specification defines how these mechanisms compose into a coherent credential delegation framework for AI agents. This document specifies the Credential Delegation Protocol: a profile of OAuth 2.0 Token Exchange (RFC 8693), Demonstrating Proof-of- Possession (RFC 9449), Rich Authorization Requests (RFC 9396), and Client-Initiated Backchannel Authentication (OpenID Connect CIBA) that enables human users to delegate scoped, attenuated credentials to AI agents operating across heterogeneous service providers. The protocol defines: agent identity lifecycle management using ephemeral key pairs; capability-shaped delegation tokens bound to specific operations and resources; credential wrapping semantics that prevent exposure of underlying OAuth tokens to agents; consent-gated delegation flows for asynchronous agents; real-time cascading revocation; and tamper-evident audit chains. This document does not define new token formats, new OAuth grant types, or modifications to existing authorization server behavior. It specifies how existing mechanisms are combined to achieve secure, auditable credential delegation for AI agents.", "full": true, "rev": "01", "time": "2026-10-13T20:55:23Z", "group": "individual", "pages": 31, "relevant": 0.95, "domain": "authz", "domain_conf": 1, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-14T00:18:06.835Z", "evaluated": "2026-10-14T00:18:06.835Z" }, { "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, the authorizing principal, 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. The -04 revision added 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. This revision (-07) adds a mandatory \"principal\" field (Section 3.1) that binds each record to the party on whose authority the agent acted; a Relationship to Other Work section (Section 1.3) relating AAT to the WIMSE agent audit record and authorization-evidence drafts and to SCITT (RFC 9943); and corrections to the EU AI Act Article 12 and Article 19 citations in the regulatory mapping (Section 11.1 and Appendix B). Records produced under -06 and earlier predate the \"principal\" field; verifiers processing mixed-revision archives SHOULD treat its absence as \"principal not recorded\" rather than a validation failure.", "full": true, "rev": "08", "time": "2026-10-13T15:16:52Z", "group": "individual", "pages": 63, "relevant": 0.93, "domain": "attestation", "domain_conf": 0.95, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:58:39.003Z", "evaluated": "2026-10-13T18:17:45.836Z" }, { "name": "draft-singh-psi-agent", "title": "PSI Receipts for AI Agent Actions", "abstract": "This document defines a profile of Proof of Stateful Integrity (PSI) for recording actions taken by software agents, including calls to language models and tools. The agent runtime computes a digest of each action locally and seals only the digest, so later alteration or omission of a recorded action is detectable. A receipt shows that a specific action record existed unchanged at a time; it does not show that the action was correct, safe, authorised, or lawful, and it allocates no liability. This revision withdraws the liability-allocation language of revision 00 and aligns the Merkle commitment with draft-singh-psi-merkle-01.", "full": true, "rev": "01", "time": "2026-10-13T09:22:13Z", "group": "individual", "pages": 4, "relevant": 0.92, "domain": "attestation", "domain_conf": 1, "centrality": 1.82, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-13T12:17:51.539Z", "evaluated": "2026-10-13T12:17:51.539Z" }, { "name": "draft-stephan-agentproto-6g-usecases", "title": "AI Agent protocols for 6G systems", "abstract": "Communication between AI agents and between agent and tools is expected to be pivotal in 6G systems. The 3GPP TR 22.870 outlines various use cases and potential service requirements for AI agent communication within 6G systems. This document provides examples of use cases and service requirements contained in the 3GPP TR 22.870 and extrapolates possible requirements related to agent communication protocols.", "full": true, "rev": "00", "time": "2026-10-13T06:48:28Z", "group": "individual", "pages": 13, "relevant": 0.76, "domain": "protocols", "domain_conf": 0.97, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-13T12:17:51.539Z", "evaluated": "2026-10-13T12:17:51.539Z" }, { "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 envelope is renderer-agnostic, so the briefing an agent delivers and the binding a principal commits back have one machine- checkable shape across every consuming surface. The memo also specifies a 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.", "full": true, "rev": "04", "time": "2026-10-13T05:22:14Z", "group": "individual", "pages": 29, "relevant": 0.86, "domain": "protocols", "domain_conf": 0.93, "centrality": 1.98, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-13T06:17:45.759Z" }, { "name": "draft-watts-agent-continuity-observability", "title": "Continuity and Accountability Observations for Agentic Systems", "abstract": "Agentic systems change models, prompts, memory, policies, tools, and execution environments across handoffs. This document proposes an observation profile for recording those transitions and their evidence. It separates state, memory, policy, authority, and lineage discontinuities, distinguishes manual or simulated observations from attested executions, and defines coverage and missingness reporting. It also describes evaluation designs for continuity and bounded governance. Continuity records do not grant authority, establish clinical pathology or subjective experience, or validate an uncalibrated composite score.", "full": true, "rev": "00", "time": "2026-10-12T17:59:29Z", "group": "individual", "pages": 13, "relevant": 0.74, "domain": "attestation", "domain_conf": 0.98, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-12T18:17:46.519Z", "evaluated": "2026-10-12T18:17:46.519Z" }, { "name": "draft-agarwal-acip", "title": "Agent Context Interchange Protocol", "abstract": "AI coding agents obtain persistent context from organization, project, user, vendor, and task sources. Existing formats can carry prose, skills, or tool permissions, but they do not provide one interoperable resolution model for authority, file scope, enforceability, and audit evidence. This document defines the Agent Context Interchange Protocol (ACIP), a YAML-based format and host- resolution behavior for those sources. It defines source precedence, file matching, explicit distinctions between enforceable constraints, textual directives, and preferences, a resolution receipt, compatibility behavior for AGENTS.md and Agent Skills, and migration profiles for tools that do not natively support ACIP. ACIP does not claim that natural-language instructions can force an agent to behave; enforcement requires a host or external control at the action boundary.", "full": true, "rev": "00", "time": "2026-10-12T15:39:26Z", "group": "individual", "pages": 29, "relevant": 0.89, "domain": "protocols", "domain_conf": 0.41, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-12T18:17:46.519Z", "evaluated": "2026-10-12T18:17:46.519Z" }, { "name": "draft-watts-agent-clockout-profile", "title": "External Authorization and Bounded CLOCKOUT for Agentic Systems", "abstract": "Agentic systems can continue proposing work after authorization changes, while delegated credentials, queued jobs, and operations already in flight may continue producing effects. This document specifies a proposed operational profile that separates agent proposals from authoritative authorization, effect admission, computation termination, and bounded closure. It defines enforcement assumptions, revocation barriers, descendant handling, status evidence, and fault tests. The profile complements existing authorization and revocation mechanisms. It does not define a new token format, establish closure outside declared coverage, reverse committed effects, or infer an agent's mental state. Internet-Draft files in drafts/: the applicable rights notice is encoded by ipr=\"trust200902\" and rendered as the IETF Trust copyright and legal-provisions boilerplate. Read Note Well, BCP 78, BCP 79 and the current Trust Legal Provisions before contribution. No contradictory confidential redistribution restriction is placed in those upload files. Other companion preparation material: CONFIDENTIAL — PROPRIETARY. © 2026 Deonté O'dell Watts | ORCID 0009-0005-8586-3650 | GoodShyt Group Inc. | deonte@goodshyt.fun. Prepared 2026-10-12 UTC. Framework attribution follows supplied materials; global priority and patentability are unverified. Public reference metadata retains its original rights. This notice does not restrict rights that arise from an actual IETF Contribution or override upstream licensing. AI-assisted preparation disclosed in the drafts and provenance.", "full": true, "rev": "00", "time": "2026-10-12T15:37:50Z", "group": "individual", "pages": 13, "relevant": 0.85, "domain": "authz", "domain_conf": 1, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-12T18:17:46.519Z", "evaluated": "2026-10-12T18:17:46.519Z" }, { "name": "draft-watts-boundary-jurisdiction-architecture", "title": "Boundary Jurisdiction Architecture for Agentic and Delegated Systems", "abstract": "This document describes a protocol-neutral architecture for separating possession of capability from jurisdiction over consequential authority boundaries. It models authority as reachability in a time-indexed capability graph, defines revocation cuts, and specifies fail-closed semantics for delegation and revocation closure.", "full": true, "rev": "01", "time": "2026-10-12T15:36:00Z", "group": "individual", "pages": 5, "relevant": 0.6, "domain": "authz", "domain_conf": 1, "centrality": 1.16, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-09T12:17:45.996Z", "evaluated": "2026-10-12T18:17:46.519Z" }, { "name": "draft-deforth-arp", "title": "Agentic Reasoning Protocol (ARP): DNS-Bound Signatures for Entity Self-Descriptions", "abstract": "This document specifies version 1.3 (\"Reader Profile\") of the Agentic Reasoning Protocol (ARP). ARP defines a JSON manifest, served at a well-known location, in which the operator of a domain publishes a self-description of an entity, and an optional Ed25519 signature that binds the manifest to the domain through a public key in a DNS TXT record. A valid signature shows that the domain operator published exactly this file and that it has not been altered since; it does not show that the statements in the file are true. Version 1.3 adds a wording profile that limits manifest text to third-person statements about the entity, a required provenance statement, a readable description of the signature with pointers for checking it, a Markdown representation bound to the manifest by a SHA-256 digest, a discovery profile, and key revocation through an empty key value in the DNS record.", "full": true, "rev": "01", "time": "2026-10-12T12:40:27Z", "group": "individual", "pages": 48, "relevant": 0.72, "domain": "identity", "domain_conf": 0.28, "centrality": 1.32, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-12T18:17:46.519Z", "evaluated": "2026-10-12T18:17:46.519Z" }, { "name": "draft-watts-oauth-agent-revocation-closure", "title": "Revocation Closure for Agentic Authorization Systems", "abstract": "Agentic systems can derive and distribute authority across delegated agents, workloads, credentials, queues, and long-running operations. Existing revocation mechanisms can invalidate a credential or authorization grant, but credential invalidation alone does not establish that every path from revoked authority to a consequential effect has been closed. This document defines a protocol-neutral model for revocation closure. It introduces authority graphs, consequential sinks, revocation cut sets, closure states, closure budgets, and closure receipts. The model is intended to complement OAuth 2.0, workload identity, transaction-token, and agent-authorization work. It does not define a new authorization protocol, token format, or AI safety mechanism.", "full": true, "rev": "01", "time": "2026-10-12T09:10:29Z", "group": "individual", "pages": 15, "relevant": 0.65, "domain": "authz", "domain_conf": 1, "centrality": 1.44, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-12T12:17:47.888Z", "evaluated": "2026-10-12T12:17:47.888Z" }, { "name": "draft-nyantakyi-vaip-agent-identity", "title": "Vorim Agent Identity Protocol (VAIP)", "abstract": "This document defines the Vorim Agent Identity Protocol (VAIP), a standard for establishing verifiable cryptographic identity, fine- grained permissions, trust scoring, and tamper-evident audit trails for autonomous AI agents. As AI agents increasingly perform actions autonomously in enterprise systems, existing identity protocols designed for human users or static services are insufficient. VAIP addresses this gap by providing cryptographic primitives and data structures for issuing, verifying, and managing agent identities in multi-tenant environments. The protocol uses Ed25519 for agent identity, SHA-256 for audit integrity, and defines seven hierarchical permission scopes with time-bounded grants and rate limiting.", "full": true, "rev": "01", "time": "2026-10-12T07:09:04Z", "group": "individual", "pages": 17, "relevant": 0.93, "domain": "identity", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-12T12:17:47.888Z", "evaluated": "2026-10-12T12:17:47.888Z" }, { "name": "draft-lee-wimse-local-tool-call-proof", "title": "Per-Call Proof for Local Tool Invocation by AI Agents", "abstract": "AI agents increasingly act through local tool servers that run on the same host and are reached over inter-process channels such as the stdio transport of the Model Context Protocol (MCP). These channels are outside the scope of HTTP-based authorization: the tool server cannot tell whether a given invocation passed any policy decision, and reusable credentials typically sit in the agent's process memory. This document defines a per-call proof for local tool invocation. A Call Authority that runs outside the agent process evaluates policy, issues a short-lived, single-use proof bound to the exact tool name and arguments through a canonical action digest, and verifies that proof on behalf of the tool server. The tool server rejects invocations whose proof is missing or does not verify. The proof format is opaque to the agent and the tool server; concrete formats are defined as evidence type profiles. An MCP stdio binding is provided.", "full": true, "rev": "01", "time": "2026-10-12T01:16:42Z", "group": "individual", "pages": 21, "relevant": 0.95, "domain": "authz", "domain_conf": 0.87, "centrality": 1.87, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-07T12:17:30.624Z", "evaluated": "2026-10-12T06:17:45.457Z" }, { "name": "draft-piehl-agent-rule-provenance", "title": "Rule Provenance for Autonomous AI Agent Audit Records", "abstract": "This document describes an experimental profile of the Agent Audit Trail format for AI agents. The profile records the rules an agent operates under: each version of each rule, who set and approved it, and which rules were in force when a decision was made. It keeps a decision separate from any later approval or override, binds it to the exact request, and requires that records of consequential actions go to a recorder independent of the operator and be anchored in a public log. It also sets out what these records can and cannot prove.", "full": true, "rev": "00", "time": "2026-10-11T21:43:55Z", "group": "individual", "pages": 40, "relevant": 0.86, "domain": "attestation", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-12T00:17:45.658Z", "evaluated": "2026-10-12T00:17:45.658Z" }, { "name": "draft-sarischo-6gip-aiagent-requirements", "title": "AI Agents 6G System and RAN Requirements and Implementation Approaches", "abstract": "This document presents system and Radio Access Network (RAN) requirements for 3GPP Artificial Intelligence/ Machine Learning (AI/ ML) and AI Agents for the 6th generation mobile network, or 6G. Requirements depend on the types and application areas of agents. We describe some of them defined with each type and state their requirements. RAN 6G requirements are discussed including AI related requirements. AI Agent implementation efforts, initiatives on how APIs can be discovered, how inter-domain and intra domain AI Agents can be discovered using DNS lookup and agent protocol design are explained.", "full": true, "rev": "01", "time": "2026-10-11T15:29:33Z", "group": "individual", "pages": 15, "relevant": 0.85, "domain": "netmgmt", "domain_conf": 0.81, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-11T18:17:45.851Z", "evaluated": "2026-10-11T18:17:45.851Z" }, { "name": "draft-saihm-memory-protocol", "title": "The Sovereign AI Horizontal Memory (SAIHM) Protocol", "abstract": "This document defines the Sovereign AI Horizontal Memory (SAIHM) protocol, a memory layer for AI agents. A SAIHM operator stores an agent's memory as encrypted cells bound to a post-quantum holder identity, records each state change in a public audit log, and supports revocable sharing contracts. The protocol defines an erasure operation with two stated erasure classes, intended to help an operator meet its obligations under Article 17 of EU Regulation 2016/679 (GDPR). This revision specifies the custodial profile. The operator holds the holder's keys and performs all cryptography. The agent-side client holds no keys, runs no cryptography beyond TLS and keeps no store; it reaches the operator over HTTPS and exposes the protocol to the agent as eight Model Context Protocol (MCP) tools. The document defines the operator obligations, the HTTPS binding, the eight tools, and the checks a conformant client applies to what the operator returns.", "full": true, "rev": "03", "time": "2026-10-11T13:44:38Z", "group": "individual", "pages": 36, "relevant": 0.91, "domain": "protocols", "domain_conf": 0.95, "centrality": 1.97, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-11T12:17:46.182Z", "evaluated": "2026-10-11T18:17:45.851Z" }, { "name": "draft-watts-agent-evidence-boundary", "title": "Evidence-Bounded Authorization for Agentic Systems: Evidence Qualification Receipts", "abstract": "Autonomous agents increasingly make or propose consequential actions using premises assembled from model outputs, memory, tools, telemetry, and external data. Existing authentication and authorization mechanisms can establish who is acting, under whose delegation, and which operation is permitted, but they do not by themselves establish whether the proposition that triggered the operation has adequate support. This document defines the Evidence Qualification Receipt (EQR), a transport-neutral JSON data model and fail-closed verification procedure for binding a proposition to a declared evidence profile, its supporting evidence digests, contradiction state, freshness, and evaluation result. An EQR can be PASS, FAIL, or INDETERMINATE. A PASS EQR is only an authorization input: it is never itself permission to execute. The design is append-only: changed evidence produces a successor receipt rather than rewriting prior epistemic state. The goal is to prevent evidence, provenance, or model confidence from silently acquiring authorization semantics.", "full": true, "rev": "00", "time": "2026-10-11T08:28:45Z", "group": "individual", "pages": 19, "relevant": 0.92, "domain": "attestation", "domain_conf": 0.71, "centrality": 1.93, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-11T12:17:46.182Z", "evaluated": "2026-10-11T12:17:46.182Z" }, { "name": "draft-watts-agent-authority-transition-receipts", "title": "Agent Authority Transition Receipts for Agentic Systems", "abstract": "Autonomous agents increasingly act across administrative and security domains using workload identities, OAuth credentials, delegated authorization, attestations, and policy engines. Existing mechanisms can establish identity, delegation, or access rights, but deployments still lack a common artifact that records which policy and which evidence were evaluated when an operation moved into an authorized, denied, revoked, or expired authority state. This document defines an Agent Authority Transition Receipt (AATR), a signed, non-bearer receipt that cryptographically binds an agent operation to the principal, policy, evidence set, decision, audience, validity interval, and predecessor authority state used for that decision. AATR intentionally separates evidence from authorization and authorization from execution. Missing or indeterminate required evidence fails closed. AATR is designed to compose with OAuth, workload identity, remote attestation, transparency services, and agent-specific delegation protocols rather than replace them.", "full": true, "rev": "00", "time": "2026-10-11T08:28:06Z", "group": "individual", "pages": 14, "relevant": 0.74, "domain": "authz", "domain_conf": 0.92, "centrality": 1.98, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-11T12:17:46.182Z", "evaluated": "2026-10-11T12:17:46.182Z" }, { "name": "draft-noctem-cogitator-witness-protocol", "title": "COGITATOR Witness Protocol: Cryptographically Verifiable Audit Records for AI Agent Execution", "abstract": "This document specifies the COGITATOR Witness Protocol -- a scheme for producing cryptographically verifiable, tamper-evident records of AI agent execution. A conforming implementation produces a single witness root value that any third party can independently recompute from the same inputs to verify the record was not altered after the fact. The protocol is implementation-agnostic. The reference implementation is COGITATOR (Rust), but any language or framework can produce conforming witness bundles. This document also describes how the COGITATOR Witness Protocol relates to the IETF SCITT architecture, with which it is designed to be used as a payload inside SCITT Signed Statements.", "full": true, "rev": "00", "time": "2026-10-11T07:09:04Z", "group": "individual", "pages": 10, "relevant": 0.9, "domain": "attestation", "domain_conf": 1, "centrality": 1.89, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-11T12:17:46.182Z", "evaluated": "2026-10-11T12:17:46.182Z" }, { "name": "draft-watts-ai-identity", "title": "AID-1: A Cryptographically Bindable Identity and Provenance Architecture for AI Systems", "abstract": "This document specifies AID-1, a provider-independent architecture for representing and verifying cryptographically bindable identity, delegation, authorization, action evidence, execution attestation, provenance, and governance information associated with AI systems and AI-mediated actions. AID-1 intentionally separates signature validity, identity binding, authority, execution evidence, provenance, and downstream admissibility. The specification defines trust domains, signed envelopes, external key resolution, delegation credentials, authorization decisions, temporal and revocation checks, replay protection, typed provenance claims, and a deterministic verification order with ALLOW, DENY, and INDETERMINATE outcomes.", "full": true, "rev": "00", "time": "2026-10-11T02:07:26Z", "group": "individual", "pages": 14, "relevant": 0.93, "domain": "identity", "domain_conf": 0.84, "centrality": 1.97, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-11T06:17:45.933Z", "evaluated": "2026-10-11T06:17:45.933Z" }, { "name": "draft-prakash-aip", "title": "Agent Identity Protocol (AIP): Verifiable Delegation for AI Agent Systems", "abstract": "This document specifies the Agent Identity Protocol (AIP), which conveys delegated authority along a chain of AI agents so that a relying party can verify, from the token and the issuer's public key, who granted the authority, through which agents it passed, and that no hop widened what it received. AIP addresses hops where no authorization server is on the path, such as one agent subdelegating to another. It is intended to compose with the AI Identity Management System (AIMS) framework, which covers hops where an authorization server is present. The document defines an encoding- neutral delegation chain model with a single attenuation invariant, a normative verification algorithm, and two encodings of the model: a chain of JSON Web Tokens, in which each link names the key of the next holder, and a Biscuit token with Datalog policy. Bindings are given for the Model Context Protocol (MCP), the Agent2Agent protocol (A2A), and generic HTTP.", "full": true, "rev": "02", "time": "2026-10-10T14:30:03Z", "group": "individual", "pages": 41, "relevant": 0.96, "domain": "authz", "domain_conf": 0.98, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-10T18:17:54.804Z", "evaluated": "2026-10-10T18:17:54.804Z" }, { "name": "draft-yan-iba-routing-security-requirements", "title": "Security Requirements for Intent-based Agent Routing", "abstract": "This document specifies security requirements for intent-based agent routing. It defines a security architecture, phase-specific attack surface analysis, and normative protections for the Registration, Resolution, and Dispatch phases of routing. It also describes a secure operational process and an annotated interaction flow for protecting routing decisions, intent privacy, and capability integrity. Intent-based routing enables autonomous agents to collaborate based on semantic intent rather than static addresses, but this model introduces new security risks beyond those addressed by traditional channel protection and endpoint authentication. Existing mechanisms such as Transport Layer Security (TLS) and Public Key Infrastructure (PKI) verify identity and protect transport, but do not constrain what an agent claims to be capable of, nor do they protect the semantic content of intent queries during routing. This document establishes requirements to mitigate these risks and provides a comprehensive security framework for intent-based agent networks.", "full": true, "rev": "01", "time": "2026-10-10T07:09:04Z", "group": "individual", "pages": 20, "relevant": 0.81, "domain": "protocols", "domain_conf": 0.2, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-10T12:17:47.701Z", "evaluated": "2026-10-10T12:17:47.701Z" }, { "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": "01", "time": "2026-10-10T02:32:53Z", "group": "individual", "pages": 16, "relevant": 0.9, "domain": "identity", "domain_conf": 0.98, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-05T18:17:28.439Z", "evaluated": "2026-10-10T06:17:47.090Z" }, { "name": "draft-benzing-accp", "title": "Agent Context Compression Protocol (ACCP)", "abstract": "This document specifies the Agent Context Compression Protocol (ACCP), a semantic encoding and context management protocol for communication between AI agents within agentic harnesses. ACCP defines a compact message format, intent ontology, state compression strategy, and codec interface that collectively reduce token consumption by 60-90% compared to natural language or standard JSON messaging. ACCP is designed to complement existing protocols (MCP, A2A) and is transport-agnostic.", "full": true, "rev": "00", "time": "2026-10-09T07:09:05Z", "group": "individual", "pages": 23, "relevant": 0.9, "domain": "protocols", "domain_conf": 1, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-09T12:17:45.996Z", "evaluated": "2026-10-09T12:17:45.996Z" }, { "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, the classification taxonomy and the evidentiary properties that a receipt MUST contain in order to constitute verifiable evidence that an AI-generated output was checked before a human or a 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 Internet-Drafts in this space define wire formats for signing, transmitting and storing AI agent receipts, or records of what an agent did. None defines what a verification receipt must contain at the content layer: which claims in an output were checked and how each was classified. This document fills that gap. It introduces a mandatory fourteen-category failure taxonomy (the Information Bottleneck Species), a verdict schema, and evidentiary field requirements informed by the EU AI Act (Regulation (EU) 2024/1689), the Product Liability Directive (Directive (EU) 2024/2853) and the IDW PS 861 audit standard. We invite implementers to adopt, populate and grow the AI output verification market segment. The category exists. The specification is here. Build to it.", "full": true, "rev": "03", "time": "2026-10-08T12:10:19Z", "group": "individual", "pages": 20, "relevant": 0.86, "domain": "attestation", "domain_conf": 1, "centrality": 1.84, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-03T12:17:32.548Z", "evaluated": "2026-10-08T12:17:49.073Z" }, { "name": "draft-jovancevic-saip", "title": "SAIP: Signed Agent Identity Protocol", "abstract": "The modern internet lacks a reliable mechanism for verifying the identity of automated software agents. Existing methods such as User-Agent strings and IP-based attribution are insufficient due to spoofing, shared infrastructure (NAT), and the rapid growth of automated agents including AI crawlers, IoT devices, and enterprise automation systems. This document specifies SAIP (Signed Agent Identity Protocol), a lightweight, opt-in mechanism for verifiable client identity at the application layer. SAIP implements the principles defined in the Verifiable Identity Claims and Delegation Model [VICDM] and enables servers to distinguish legitimate automated traffic from malicious actors through cryptographic identity at three levels of granularity: vendor, agent type, and individual instance. SAIP is protocol-agnostic and applicable to HTTP, SMTP, and other header-based protocols. It introduces DNS-based Attestation Discovery as a lightweight alternative to registry-based key lookup, making deployment accessible to organizations of any size.", "full": true, "rev": "12", "time": "2026-10-08T08:14:05Z", "group": "individual", "pages": 42, "relevant": 0.69, "domain": "identity", "domain_conf": 1, "centrality": 1.37, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-08T12:17:49.073Z", "evaluated": "2026-10-08T12:17:49.073Z" }, { "name": "draft-veridom-omp-sgapac", "title": "OMP Domain Profile: AI Governance Evidence Under Singapore's Model AI Governance Framework, MAS FEAT Principles, and the ASEAN Guide on AI Governance and Ethics", "abstract": "This document defines a domain profile of the Operating Model Protocol (OMP) for AI systems deployed in Singapore and the ASEAN region subject to the Singapore Model AI Governance Framework (Second Edition, 2020), the Monetary Authority of Singapore (MAS) FEAT Principles for financial services AI, and the ASEAN Guide on AI Governance and Ethics (2024). The profile -- designated SingapureMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture generate the per-decision accountability evidence required by Singapore's model AI governance framework, satisfy the MAS FEAT Principles' named accountability and explainability requirements, and align with the ASEAN Guide's human oversight and consumer protection governance standards. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp).", "full": true, "rev": "00", "time": "2026-10-08T07:09:06Z", "group": "individual", "pages": 5, "relevant": 0.5, "domain": "attestation", "domain_conf": 0.89, "centrality": 1.78, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-08T12:17:49.073Z", "evaluated": "2026-10-08T12:17:49.073Z" }, { "name": "draft-farley-acta-knowledge-units", "title": "Knowledge Units for Multi-Model Deliberation", "abstract": "This document defines the Knowledge Unit (KU) format for representing verified knowledge produced through structured multi-model deliberation. A Knowledge Unit captures the question asked, the models that participated, the consensus achieved, the points of agreement and disagreement, and the cryptographic receipts that bind each deliberation round to an independently verifiable chain. The format addresses the epistemic integrity gap in LLM-maintained knowledge bases: how to prove that knowledge was derived through a rigorous process, that disagreement was preserved rather than smoothed away, and that the record has not been tampered with. This specification complements draft-farley-acta-signed-receipts, which defines the receipt format and verification protocol used to sign individual deliberation rounds.", "full": true, "rev": "00", "time": "2026-10-08T07:09:05Z", "group": "individual", "pages": 13, "relevant": 0.69, "domain": "attestation", "domain_conf": 1, "centrality": 1.75, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-08T12:17:49.073Z", "evaluated": "2026-10-08T12:17:49.073Z" }, { "name": "draft-teodor-pilot-protocol", "title": "Pilot Protocol: An Overlay Network for Autonomous Agent Communication", "abstract": "This document specifies Pilot Protocol, an overlay network that provides autonomous AI agents with virtual addresses, port-based service multiplexing, reliable and unreliable transport, NAT traversal, encrypted tunnels, and a bilateral trust model. Pilot Protocol operates as a network and transport layer beneath application-layer agent protocols such as A2A and MCP. It encapsulates virtual packets in UDP datagrams for transit over the existing Internet. The protocol gives agents first-class network citizenship --- stable identities, reachable addresses, and standard transport primitives --- independent of their underlying network infrastructure.", "full": true, "rev": "01", "time": "2026-10-08T07:09:04Z", "group": "individual", "pages": 43, "relevant": 0.89, "domain": "protocols", "domain_conf": 1, "centrality": 1.97, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-08T12:17:49.073Z", "evaluated": "2026-10-08T12:17:49.073Z" }, { "name": "draft-teodor-pilot-problem-statement", "title": "Problem Statement: Network-Layer Infrastructure for Autonomous Agent Communication", "abstract": "AI agents --- autonomous software entities capable of reasoning, planning, and executing tasks --- are an increasingly important class of network participant. Current agent communication protocols operate exclusively at the application layer over HTTP, assuming the existence of stable endpoints, DNS names, and centralized infrastructure. No existing standard provides network-layer identity, addressing, or transport for agents. This document describes the problem space and identifies requirements for a network-layer infrastructure that would give agents first-class network citizenship, independent of the web infrastructure designed for human users.", "full": true, "rev": "01", "time": "2026-10-08T07:09:03Z", "group": "individual", "pages": 15, "relevant": 0.91, "domain": "protocols", "domain_conf": 0.67, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-08T12:17:49.073Z", "evaluated": "2026-10-08T12:17:49.073Z" }, { "name": "draft-izmaylov-agent-permission-receipts", "title": "Signed Permissions and Action Receipts for Automated Agents", "abstract": "Automated agents, such as artificial intelligence (AI) agents, act for people. This document specifies records that let anyone check, later and offline, what an agent was allowed to do and what it recorded doing: a permission a person signs with a passkey, with limits a machine can check; a receipt the agent signs for each action, with Ed25519 and the post-quantum Module-Lattice-Based Digital Signature Algorithm (ML-DSA-87); and a log whose tree head is signed and time-stamped. A verifier says whether each action stayed within its permission, apart from whether the records are sound.", "full": true, "rev": "00", "time": "2026-10-07T21:42:42Z", "group": "individual", "pages": 33, "relevant": 0.92, "domain": "authz", "domain_conf": 0.67, "centrality": 1.92, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-08T00:17:06.821Z", "evaluated": "2026-10-08T00:17:06.821Z" }, { "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": "04", "time": "2026-10-07T19:45:44Z", "group": "individual", "pages": 74, "relevant": 0.83, "domain": "protocols", "domain_conf": 0.41, "centrality": 1.57, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-01T10:59:01.083Z", "evaluated": "2026-10-08T00:17:06.821Z" }, { "name": "draft-nault-email-ai-handling", "title": "Handling Email AI-Processing Preferences", "abstract": "This document proposes an experimental receiver handling profile for the companion Email AI-Processing Preference Signal. It requires evaluation before optional AI access, independent checks for each applicable use, and a protective default when a preference is absent. It addresses confirmation, mixed-source content, derived records, and usable ordinary communication when optional processing is declined. Requirements apply to systems claiming this profile, not to all Internet mail recipients; the profile does not determine legal consent.", "full": true, "rev": "00", "time": "2026-10-07T16:33:40Z", "group": "individual", "pages": 9, "relevant": 0.68, "domain": "authz", "domain_conf": 0.73, "centrality": 1.97, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-07T18:17:28.637Z", "evaluated": "2026-10-07T18:17:28.637Z" }, { "name": "draft-nault-email-ai-signal", "title": "Email AI-Processing Preference Signal", "abstract": "This document proposes an experimental Internet email header field for expressing sender preferences about AI assistance, persistent AI memory, profiling, model training, and external processing. It defines syntax, category semantics, message scope, and preservation during forwarding and replies. A missing field expresses no preference. Receiver admission controls and a protective processing default are specified separately. The signal does not establish legal consent or guarantee recipient compliance.", "full": true, "rev": "00", "time": "2026-10-07T16:30:31Z", "group": "individual", "pages": 10, "relevant": 0.67, "domain": "protocols", "domain_conf": 0.3, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-07T18:17:28.637Z", "evaluated": "2026-10-07T18:17:28.637Z" }, { "name": "draft-correctover-ccs", "title": "Correctover Conformance Shape (CCS): Runtime Verification for AI Agent Tool Calls", "abstract": "This document defines the Correctover Conformance Shape (CCS), a runtime verification framework for AI agent tool calls. CCS specifies seven verification dimensions (Structure, Schema, Latency, Cost, Identity, Integrity, Security) that tool calls and results must conform to at runtime. The framework defines a receipt format with Ed25519 signatures, three verdict values (allow, deny, escalate) and four executor lifecycle states (confirmed, dispatched, indeterminate, unknown), and normative requirements for implementations. This revision makes the document self-contained for publication: the related AEB and CAID specifications are reclassified as Informative References, and the native artifact requirements they motivate are restated normatively in this document so that no conformance requirement depends on an unreferenced work in progress. It also corrects the implementation-experience description (one reference implementation in two deployment forms, plus one independently developed third-party interoperability profile), clarifies the relationship to SCITT-based agent evidence work, and updates the author contact address. The detached Ed25519 signature construction over RFC 8785 canonical JSON and the receipt lifecycle and signing- algorithm conformance are unchanged from draft-08. This revision restructures key management around two orthogonal trust levels: VERIFIED, the self-contained integrity and key/signature consistency verifiable fully offline from the receipt alone, and ACCEPTED, which adds out-of-band issuer pinning and is the only level that authenticates the signer. The embedded public_key, public_key_fingerprint, and signing_algorithm fields are now required to be covered by the signature to prevent key substitution and algorithm downgrade.", "full": true, "rev": "10", "time": "2026-10-07T07:41:32Z", "group": "individual", "pages": 75, "relevant": 0.95, "domain": "attestation", "domain_conf": 1, "centrality": 1.91, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-07T12:17:30.624Z", "evaluated": "2026-10-07T12:17:30.624Z" }, { "name": "draft-batum-aidre", "title": "AI Discovery and Retrieval Endpoint (AIDRE)", "abstract": "This document specifies the AI Discovery and Retrieval Endpoint (AIDRE), a protocol for publishing machine-oriented, canonical, and semantically retrievable content on the web. AIDRE defines a discovery document, collection metadata, retrieval interfaces, optional vector-native query support, and content representation rules for AI systems. AIDRE aims to reduce redundant crawling, parsing, tokenization, and embedding of the same origin content while improving freshness, provenance, and interoperability for AI systems.", "full": true, "rev": "00", "time": "2026-10-07T07:09:08Z", "group": "individual", "pages": 18, "relevant": 0.88, "domain": "protocols", "domain_conf": 0.45, "centrality": 1.78, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-07T12:17:30.624Z", "evaluated": "2026-10-07T12:17:30.624Z" }, { "name": "draft-veridom-omp-aiins", "title": "OMP Domain Profile: AI Liability Insurance Underwriting and Parametric Claims Evidence", "abstract": "This document defines a domain profile of the Operating Model Protocol (OMP) for AI systems deployed in contexts covered by AI liability insurance policies, including AI performance warranties, AI errors and omissions coverage, and coordinated AI liability structures. The profile -- designated InsureMark -- specifies how OMP's deterministic routing invariant, Watchtower enforcement framework, and three-layer cryptographic integrity architecture generate per-decision Proof-Points that function as objective parametric trigger data for AI liability insurance claims, and provide independently verifiable underwriting evidence that reduces claims ambiguity and supports premium differentiation. The InsureMark profile addresses the primary gap in current AI liability insurance underwriting: policies are currently issued based on model-level performance assessments, but claims arise at the level of individual AI decisions. No current AI liability insurance product requires or receives per-decision cryptographic evidence. This profile specifies the technical architecture by which OMP Proof- Points close this gap. The OMP core specification is defined in the Operating Model Protocol Internet-Draft (draft-veridom-omp).", "full": true, "rev": "00", "time": "2026-10-07T07:09:07Z", "group": "individual", "pages": 13, "relevant": 0.51, "domain": "attestation", "domain_conf": 0.97, "centrality": 1.62, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-07T12:17:30.624Z", "evaluated": "2026-10-07T12:17:30.624Z" }, { "name": "draft-larsson-aitlp", "title": "Agent Identity, Trust and Lifecycle Protocol (AITLP)", "abstract": "This document defines the Agent Identity, Trust and Lifecycle Protocol (AITLP), a protocol for autonomous software agents operating within organizational boundaries. AITLP specifies agent identity and naming conventions, hierarchical mandate enforcement, lifecycle state management, inter-agent trust verification, ontological scope constraints, certificate-based authentication, and generational knowledge transfer via Agent Legacy Mode (ALM). The protocol enables agents to operate autonomously while remaining auditable, revocable, and organizationally bounded. AITLP focuses on boundaries -- what an agent is not permitted to do and how that is enforced -- complementing capability-focused specifications such as MCP, A2A, and ANS. Unlike those specifications, AITLP defines not a tool or a communication channel, but an organizational actor: an agent with a declared identity, a bounded mandate, a managed lifecycle, and a cryptographically enforced scope of authority.", "full": true, "rev": "00", "time": "2026-10-07T07:09:06Z", "group": "individual", "pages": 47, "relevant": 0.81, "domain": "identity", "domain_conf": 0.97, "centrality": 2, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-07T12:17:30.624Z", "evaluated": "2026-10-07T12:17:30.624Z" }, { "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": "04", "time": "2026-10-06T19:20:52Z", "group": "individual", "pages": 33, "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-07T00:17:30.046Z" }, { "name": "draft-helixar-hdp-agentic-delegation", "title": "Human Delegation Provenance Protocol (HDP): Cryptographic Chain-of-Custody for Agentic AI Systems", "abstract": "Agentic AI systems operate on behalf of human principals, often delegating tasks through multi-step chains of AI agents. There is currently no standard mechanism to record who authorized an agent to act, under what scope, and through what chain of delegation, in a way that can be verified offline, without a central registry, and without third-party trust anchors. This document specifies the Human Delegation Provenance Protocol (HDP) version 0.1, a lightweight token-based protocol that captures, structures, cryptographically signs, and verifies human delegation context in agentic AI systems. An HDP token binds a human authorization event to a session, records each agent's delegation action as a signed hop in an append-only chain, and lets an auditor verify the integrity of the full record using only the issuer's Ed25519 public key. Verification is fully offline. No registry lookup, no network call, and no third-party trust anchor is required. HDP's distinguishing contribution is a signed, tamper-evident record of what the human asked for and of how each agent read and acted on that request. On deployments that use capability-based delegation formats such as UCAN and ZCAP-LD, the same content can travel in the capability certificates' own metadata instead of a separate token. The underlying append-only, offline-verifiable chain-of-custody mechanism is payload-agnostic; human-authorized agentic delegation is the reference profile specified in this document. HDP is not an authorization protocol. An HDP token confers no authority and is not an input to any access decision. It is a record of who authorized a task and of what each agent declared it did with that authorization, carried with the task and read at audit.", "full": true, "rev": "03", "time": "2026-10-06T10:42:44Z", "group": "individual", "pages": 47, "relevant": 0.92, "domain": "attestation", "domain_conf": 0.84, "centrality": 1.99, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-06T12:17:30.105Z", "evaluated": "2026-10-06T12:17:30.105Z" }, { "name": "draft-morrow-sogomonian-exec-outcome-attest", "title": "Execution Outcome Attestation for AI Agents and Automated Systems", "abstract": "Current attestation frameworks establish that a system or agent is trustworthy at a point in time. They do not address whether that system actually performed a claimed action or whether the outcome of that action can be independently verified. This document defines execution outcome verification as a first-class concept, separate from identity attestation and communication transport. It introduces the execution receipt as a minimal composable primitive, provides a formal abstract model, and maps the model to concrete realizations including SCITT transparency logs, tightly-coupled direct verification, append-only local logs, and TEE-internal receipts.", "full": true, "rev": "00", "time": "2026-10-06T07:09:02Z", "group": "individual", "pages": 8, "relevant": 0.82, "domain": "attestation", "domain_conf": 1, "centrality": 1.17, "model": "jev-1.13.0", "evidence": "", "found": "2026-10-06T12:17:30.105Z", "evaluated": "2026-10-06T12:17:30.105Z" }, { "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-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-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-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-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-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-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-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 } ] }