Internet Engineering Task Force G. Konda Internet-Draft 5 October 2026 Intended status: Informational Expires: 8 April 2027 Preserving Evaluation State in Agent Protocol Decisions draft-konda-agentproto-evaluation-state-00 Abstract Agent protocols often require a participant to establish a decision- time input before it acts: issuer standing, key availability, delegated authority, policy profile availability, consumption state, revocation status, or the outcome of a downstream operation. A participant that establishes an input and receives a negative answer has learned a different fact from a participant that cannot establish the input at all. Collapsing those facts into one denial or failure value changes retry behavior, alert routing, audit interpretation, incident ownership, and post-incident reconstruction. This document specifies requirements for preserving evaluation state across agent protocol boundaries: the value of an input, whether that value was established at decision time, the freshness of the source used to establish it, and whether the resulting policy decision was actually evaluated. The requirements are stated independently of encoding, so that policy, authorization, revocation, routing, and audit documents can satisfy them in their own formats. A subsequent revision will specify concrete representations. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 8 April 2027. Konda Expires 8 April 2027 [Page 1] Internet-Draft Evaluation State in Agent Protocols October 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Resumed Dialog with an Unresolved Downstream Operation . 6 4.2. Cross-Domain Policy Profile Not Held Locally . . . . . . 6 4.3. Issuer Standing or Key Source Unavailable . . . . . . . . 6 4.4. Revocation or Consumption Source Stale . . . . . . . . . 6 4.5. Audit Record for a Failed Evaluation . . . . . . . . . . 7 5. Deployment Models and Considerations . . . . . . . . . . . . 7 5.1. Decision-Point Placement . . . . . . . . . . . . . . . . 7 5.2. Trust-Domain Boundary . . . . . . . . . . . . . . . . . . 8 5.3. Carrying State Between Hops and Recording It Locally . . 9 5.4. Operational Consequences . . . . . . . . . . . . . . . . 9 5.5. Single-Domain and Cross-Domain Deployments . . . . . . . 10 6. Evaluation State Model . . . . . . . . . . . . . . . . . . . 10 7. Architectural Requirements . . . . . . . . . . . . . . . . . 11 8. Mapping to AgentProto Use Cases . . . . . . . . . . . . . . . 12 9. Mapping to WIMSE Evaluation and Audit Work . . . . . . . . . 13 10. Relationship to Capability and Authorization Drafts . . . . . 13 11. Privacy and Oracle Considerations . . . . . . . . . . . . . . 15 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 14.1. Normative References . . . . . . . . . . . . . . . . . . 16 14.2. Informative References . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Konda Expires 8 April 2027 [Page 2] Internet-Draft Evaluation State in Agent Protocols October 2026 1. Introduction Agent protocol participants frequently need to decide before acting. The decision may be about whether to route a dialog, invoke a tool, accept a delegated authority, resume a suspended task, rely on an issuer, consume a one-time grant, or treat a downstream effect as complete. In each case, the deciding participant depends on inputs that may or may not be available at the time of decision. This document uses the term "decision-time input" for those inputs. Examples include: * issuer standing; * issuer or evaluator key availability; * delegated authority and whether it was allowed to be delegated; * policy profile availability; * consumption or single-use state; * revocation or status-list state; * current freshness of a cached source; and * the outcome of a downstream operation. The core claim is narrow. A participant's inability to establish a decision-time input is not the same fact as that input coming back negative. A protocol that collapses the two destroys the distinction at exactly the moment an incident review needs it. For example, "issuer standing source unavailable" is not the same as "issuer standing withdrawn"; "policy profile not held" is not the same as "the profile defines no comparison relation"; "revocation status stale" is not the same as "not revoked"; and "downstream outcome unresolved" is not the same as "downstream operation did not occur". This distinction is operational, not cosmetic. Negative inputs and unestablished inputs lead to different retry behavior, alert routing, owner assignment, and blast-radius analysis. A negative input often points at the party that supplied or violated the input. An unestablished input often points at a dependency, deployment boundary, cache, profile repository, status source, or observation path. If both appear as the same denial, the incident record looks cleaner and becomes less useful. Konda Expires 8 April 2027 [Page 3] Internet-Draft Evaluation State in Agent Protocols October 2026 This document is a requirements document. It states the evaluation state that agent protocols need to preserve, expressed independently of any encoding, so that protocol, policy, authorization, routing, and audit documents can satisfy these requirements in their own formats. A subsequent revision will specify concrete representations for the evaluation states and requirements given below, including candidate field names, encodings, and status or error values. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Decision point: The component that decides whether an agent protocol action, hop, tool invocation, delegation, routing step, or audit conclusion is accepted, refused, retried, forwarded, or recorded. Decision-time input: An input that the decision point needs at the time of decision in order to evaluate the requested action. The input may be supplied in the request, fetched from a source, read from local state, computed from other inputs, or established by observing an effect. Established input: A decision-time input whose value the decision point has obtained from a source that is acceptable under local policy for the decision being made. Negative result: A value of an established input that does not satisfy the decision point's policy. Examples include a revoked token, an expired grant, a withdrawn issuer, a violated constraint, or a completed downstream operation whose result is failure. Not evaluated: The decision point did not complete evaluation because one or more required decision-time inputs were not established. Stale: The decision point has an older value for an input, but the value is outside the freshness bound required for the decision. Indeterminate: The observation layer cannot determine whether an effect occurred. This document uses "indeterminate" for observation state, not as a substitute for "not evaluated". Konda Expires 8 April 2027 [Page 4] Internet-Draft Evaluation State in Agent Protocols October 2026 Refusal: A decision point declines to admit, execute, forward, or report an action as successful. A refusal can result from a negative result or from not being able to evaluate. Audit record: A durable operator-facing record of a decision, refusal, effect, or observation. This document does not define an audit record format. 3. Problem Statement Many protocol designs have a natural two-value shape: permit or deny, valid or invalid, revoked or not revoked, complete or failed, inside or outside a grant. That shape is insufficient when the decision point cannot establish a required input. A negative result means the decision point reached the input and the input did not satisfy policy. An unestablished input means the decision point did not learn the fact it needed. If a protocol uses the same value for both cases, three errors follow. First, callers retry incorrectly. A permanent refusal should not be retried as if a source outage caused it. A transient refusal should not stop a caller whose request could succeed after the unavailable input is established. Second, operators route incidents incorrectly. A revoked grant, a missing policy profile, a stale status cache, an unavailable issuer key source, and a failed downstream task often have different owners. Collapsing them into one denial routes the incident to the wrong team or hides the dependency that failed. Third, audits become misleading. A record that says "deny" may be read later as a correctly evaluated policy denial. If the verifier actually could not evaluate because a required input was unavailable, that record has lost the fact needed to reconstruct what happened. The failure mode is especially important at agent-to-agent and agent- to-tool boundaries because the deciding component is often not the issuer of the input it must establish. It may receive an authorization artifact from one domain, fetch a key from another, evaluate a policy profile published elsewhere, consult local consumption state, and observe effects through an audit or tool layer. Each source can fail independently. 4. Use Cases Konda Expires 8 April 2027 [Page 5] Internet-Draft Evaluation State in Agent Protocols October 2026 4.1. Resumed Dialog with an Unresolved Downstream Operation An invoking agent delegates work to another agent or tool. The downstream participant starts an operation whose result is not available before the dialog suspends or the response path fails. On resumption, the upstream participant needs to know whether the downstream operation occurred, did not occur, failed, or remains unresolved. The unresolved case is not the same as a negative operation result. The protocol needs to preserve that the outcome could not be established so that a retry or reconciliation step can be chosen safely. 4.2. Cross-Domain Policy Profile Not Held Locally A receiving domain evaluates a request governed by a profile that is identified by the sending domain or by a chain of delegation. The receiving domain does not hold the exact profile definition needed for comparison. This is not equivalent to the profile defining no applicable comparison relation. In [I-D.ahuja-agent-routing-policy], Section 4 distinguishes these cases as PROFILE_NOT_HELD and NO_COMPARISON_RELATION. This document generalizes that distinction: "the deciding verifier cannot establish the input" is not the same as "the input was established and was negative." 4.3. Issuer Standing or Key Source Unavailable A verifier receives an artifact whose issuer, signing key, or standing must be established before the artifact can be relied on. The source used to obtain the key or standing is unavailable. A failed lookup does not establish that the issuer is untrusted, that standing was withdrawn, or that the signature was invalid. The safe local action may still be fail-closed, but the record and any operator-facing state need to say that the input was unavailable. 4.4. Revocation or Consumption Source Stale A decision point checks revocation status, token status, grant consumption, or single-use state. It has a cached answer, but that answer is older than the freshness bound required for the current decision, or the state store cannot be reached. Konda Expires 8 April 2027 [Page 6] Internet-Draft Evaluation State in Agent Protocols October 2026 "Not revoked" and "status source stale" are different facts. "Single-use state says not consumed" and "single-use store unavailable" are different facts. A deployment may choose to deny in both cases, but an audit record and incident workflow need the difference. 4.5. Audit Record for a Failed Evaluation A verifier attempts to evaluate a token, delegation, or policy input, but cannot complete evaluation because a required source is unavailable. If the audit format only records a reported decision such as permit or deny, the verifier may be forced to record a denial that later reads as a successful policy evaluation. [I-D.jackson-wimse-evaluation], Section 5 requires a verifier's own record to distinguish a token it evaluated and refused from a token it could not evaluate, and to name the unavailable input. [I-D.gilda-wimse-agent-audit-record], Section 5.3 separates reported decision, observed effect, and agreement, but its current reported decision vocabulary is permit, deny, and permit-with-conditions. A future audit record can preserve the distinction without making "could not evaluate" a policy decision value. 5. Deployment Models and Considerations 5.1. Decision-Point Placement This document does not require one deployment topology. The decision point can sit in several places: * in-process, as a library linked into the agent, host, gateway, or tool service; * out-of-process but co-located, as a sidecar adjacent to the agent or tool; * at a gateway that mediates traffic between agents, tools, or administrative domains; * as an MCP proxy between the agent and its tools; or * as a host pre-tool hook that decides each tool call before it reaches the tool. Konda Expires 8 April 2027 [Page 7] Internet-Draft Evaluation State in Agent Protocols October 2026 The last two placements are worth separating. A decision point between the agent and its tools, run as an MCP proxy or as the host's pre-tool hook, decides each tool call before the tool sees it. That placement is important because the tool side sees the requested call but may not see whether the call falls inside a grant established earlier. In-process libraries are simple to deploy but may share failure and trust boundaries with the agent. Sidecars make policy and audit code separable from the agent process but still commonly share a local administrative domain. Gateways, MCP proxies, and host hooks are natural enforcement points for tool invocation and cross-domain traffic, but they often evaluate inputs issued elsewhere. A protocol requirement to preserve evaluation state applies at all of these placements. The placement changes where state is stored, which source failures are visible, and which operator owns the incident. 5.2. Trust-Domain Boundary The evaluation problem becomes sharper when the decision point is in a different trust domain from the issuer of the input it must establish. In a single trust domain, an implementation can often rely on common administration, shared profile repositories, shared clocks, shared caches, and common incident ownership. Even then, the distinction between negative and unestablished inputs matters, but the operator may be able to reconstruct missing context from local logs. Across domains, the deciding participant often cannot inspect the sender's local policy, grant history, issuer standing source, or downstream audit trail. The sender may not know the receiver's routing policy, comparison profile, freshness bound, or local dependency state. This is the cross-administrative-domain variant of the delegation case in Section 3.3.2 of [I-D.rosenberg-agentproto-usecases]. It is also the point at which single-domain deployment separates from later inter-domain capability exchange, where border policy filtering and per-domain administrative autonomy apply. When domains differ, the response sent to the caller and the record kept by the decision point need not contain the same detail. The caller-facing response can be intentionally narrow to avoid exposing another domain's graph or policy state. The operator-facing record needs enough detail for the domain that made the decision to reconstruct which input was unavailable and which source was used. Konda Expires 8 April 2027 [Page 8] Internet-Draft Evaluation State in Agent Protocols October 2026 5.3. Carrying State Between Hops and Recording It Locally Evaluation state can be carried between hops, recorded locally, or both. State carried between hops is useful when the next participant can resolve an unresolved input, perform a retry, or make a routing decision based on the reason evaluation did not complete. For example, a participant that receives a "profile not held" state might route evaluation to a verifier that holds the exact profile. Locally recorded state is useful when details are too sensitive to reveal to the caller, when the next hop has no need to resolve the input, or when the detail only helps incident review. For example, the identity of a failed issuer-standing source may belong in the verifier's audit record but not in a cross-domain protocol response. A protocol can therefore expose a coarse state on the wire while requiring the decision point to record a more detailed local state. The minimum state needed for reconstruction is: * the input name at a useful level of detail; * whether the input was established; * if established, whether it was positive or negative for the decision being made; * the freshness or "as of" time of the established value, when freshness is relevant; * the source class or source identifier used, subject to privacy and oracle constraints; and * the decision point that made the evaluation or refusal. This document does not require every hop to forward all of that state. It requires that a hop not turn "I did not establish the input" into "the input was negative" before forwarding or recording. 5.4. Operational Consequences The negative/unestablished distinction changes operations in four common ways. Retry behavior: A negative result may be permanent for the presented Konda Expires 8 April 2027 [Page 9] Internet-Draft Evaluation State in Agent Protocols October 2026 artifact or operation. An unestablished input may be transient. Retrying a permanent denial wastes capacity and can amplify load. Treating a transient failure as permanent stops work that could safely proceed later. Alert routing: A negative input often routes to the issuer, grant owner, policy owner, or caller. An unestablished input often routes to the dependency owner, profile publisher, key source, status source, cache owner, gateway owner, or observation pipeline. Incident ownership: Ownership should follow the failed fact. If the decision point established that a grant was outside policy, the policy or caller path owns the issue. If the decision point could not reach the profile repository, the repository or network path may own the issue. If the downstream outcome could not be observed, the owner may be the tool, audit path, or reconciliation process. Reconstruction: After an incident, operators need to reconstruct what was known at decision time. They need to know the value observed, the source used to observe it, the freshness of that source, and whether evaluation completed. A single denial value cannot answer those questions. 5.5. Single-Domain and Cross-Domain Deployments In a single-domain deployment, preserving evaluation state still matters because retries, alert routing, and incident review still depend on the distinction. The deployment may choose compact internal encodings, shared logs, or common source identifiers because one operator controls the decision point and the input sources. In a cross-domain deployment, preserving evaluation state is part of interoperability. Each domain may publish different policies, apply different freshness bounds, and hold different sources. A receiving domain may refuse because it cannot establish an input, while the sending domain may be able to establish that same input locally. A useful architecture allows that state to be carried or locally recorded without requiring either domain to expose its full policy or dependency graph. 6. Evaluation State Model This document models evaluation state per input, not only per final policy decision. For each decision-time input, a decision point can be in one of the following states: Konda Expires 8 April 2027 [Page 10] Internet-Draft Evaluation State in Agent Protocols October 2026 established-positive: The input was established and satisfied the relevant predicate for the decision. established-negative: The input was established and did not satisfy the relevant predicate for the decision. not-established: The input required for evaluation was not established. stale: A value was available but outside the freshness bound required for the decision. not-applicable: The input was not required for this decision. A final policy decision such as permit, deny, refuse, or route is derived from those input states under the governing protocol and local policy. This document does not define that policy. The state "not-established" is not a fourth authorization decision. It is state about the evaluation process. A protocol or deployment may still fail closed and refuse when any required input is not established. The requirement is that the refusal not be recorded or forwarded as if the input had been established and found negative. "Stale" is separated from "not-established" because it carries a different operational meaning. A stale input says a value was known at an earlier time but cannot be used for the current decision under the applicable freshness bound. An input that was never obtained does not say that. Both may lead to fail-closed refusal, but they answer different incident-review questions. "Indeterminate" is not included as an input state in this model. It is reserved here for observations whose effect cannot be determined, as in an audit record that cannot tell whether a write occurred. A later protocol may choose different names, but it should keep evaluation state and effect-observation state separate. 7. Architectural Requirements REQ-1: A decision point MUST NOT report an unavailable or unestablished decision-time input as the negative value for that input. REQ-2: When a decision point refuses because a required input was not established, its operator-facing record MUST distinguish that refusal from a refusal based on an established negative input. Konda Expires 8 April 2027 [Page 11] Internet-Draft Evaluation State in Agent Protocols October 2026 REQ-3: When a decision point records a not-established input, the record SHOULD name the input at the most specific level that is useful for operation and safe for the record's audience. REQ-4: When freshness affects the decision, a decision point SHOULD record the "as of" time, source freshness, or freshness failure that caused the input to be accepted, treated as stale, or not established. REQ-5: A protocol response MAY hide sensitive source details from the caller while requiring more detailed local records at the decision point. REQ-6: A hop that forwards evaluation state to another hop SHOULD preserve the input name, evaluation state, and any freshness bound needed by the next hop to resolve, retry, or refuse safely. REQ-7: A decision point MUST NOT silently discard an unresolved required input in a way that lets a caller, callee, tool, or downstream hop treat the decision as fully evaluated. REQ-8: If a protocol defines both caller-facing responses and operator-facing records, it SHOULD specify which evaluation-state details are safe to reveal to the caller and which are only recorded locally. 8. Mapping to AgentProto Use Cases Section 3.3.3 of [I-D.rosenberg-agentproto-usecases] discusses lifecycle management, including suspended mode while a downstream agent waits for a response, and Section 3.3.5 of that document discusses authentication and authorization for invoked agents whose tasks are not merely enumerated API scopes. Evaluation state sits between those sections. A suspended or resumed dialog may need to know whether a downstream operation completed, failed, did not occur, or remains unresolved. That is a lifecycle concern. The same hop may also need to know whether a user identity, grant, issuer, standing source, or policy profile supports the requested action. That is an authorization concern. The common requirement is that the participant preserve whether each required input was established. Konda Expires 8 April 2027 [Page 12] Internet-Draft Evaluation State in Agent Protocols October 2026 This document does not replace authorization artifacts such as Agent Authorization Envelopes, routing-policy grammars, or capability languages. It supplies a requirement for the Reference Architecture: decision points carry or record evaluation state separately from the final decision, especially at deployment points where the decision point is not the issuer of the input. 9. Mapping to WIMSE Evaluation and Audit Work [I-D.jackson-wimse-evaluation], Section 5 already states the key operational distinction for verifier refusals: a refusal can be permanent for the presented token, or transient because the verifier could not evaluate when a standing source, key source, or consumption state was unavailable. It further requires the verifier's own record to distinguish a token it evaluated and refused from a token it could not evaluate, and to name the unavailable input. This document generalizes that requirement beyond WIMSE verifier evaluation. The same distinction applies to agent routing, tool invocation, revocation/status lookups, delegated-authority evaluation, and downstream-effect observation. [I-D.gilda-wimse-agent-audit-record], Section 5.3 separates decision.reported, effect.observed, and agreement. That separation is consistent with this document's model. A failed evaluation should not be encoded by overloading decision.reported with a new policy value unless that audit format explicitly chooses that design. A sibling evaluation-status member, or another structure that keeps evaluation state separate from the reported policy decision, would preserve the distinction while leaving effect and agreement semantics intact. 10. Relationship to Capability and Authorization Drafts [I-D.wei-capability-language-core] defines a capability language and its decision function. Its Abstract defines a three-valued verdict: allow, deny, and allow_unresolved. Section 8.4 of that document requires recognized constraints that cannot be evaluated by the core to appear in an unresolved list, with a verdict of allow_unresolved rather than allow. Its Section 8.5 defines resolution of those residual obligations, and its Section 9 defines the authorization- side decision function. The two documents operate at different layers. That document specifies an executable capability language and the decision function that evaluates it. This document states an architectural requirement for preserving evaluation state across agent protocol deployment points, including inputs that lie outside any one capability Konda Expires 8 April 2027 [Page 13] Internet-Draft Evaluation State in Agent Protocols October 2026 language: issuer standing, key source availability, revocation freshness, profile availability, consumption state, and downstream operation outcome. Where the unestablished input is a capability constraint, that document's unresolved list is a candidate mechanism. That document also separates two operations that are easy to collapse: containment as the per-hop admission check, and intersection as the operation used when several sources constrain the same action. Section 7 of [I-D.wei-capability-language-core] defines intersection, and its Section 13 defines delegation containment as a separate relation. This document does not redefine either operation. The split matters here only to the extent that a decision point should record which operation it could or could not evaluate. The algorithms for containment, intersection, order independence, and "never broader" are out of scope. Section 2.2 of [I-D.wei-aic-identity-cert] uses permission intersection in an agent identity certificate model, and its Section 7 describes deployment models. It is related because it shows that capability, certificate, delegation, and deployment boundaries are being specified together. This document does not define certificate contents or trust-anchor requirements. Section 4 of [I-D.ahuja-agent-routing-policy] is directly aligned with this document's core distinction. It distinguishes NO_COMPARISON_RELATION, where the verifier holds the governing profile and the profile supplies no applicable relation, from PROFILE_NOT_HELD, where the exact governing profile definition is unavailable to the deciding verifier. Its Section 9 further requires that a PROFILE_NOT_HELD chain is not valid to that relying party, but may be routed to a party holding the exact definition. This document generalizes that unavailable-versus-negative comparison distinction across decision-time inputs. [I-D.kroehl-agentic-trust-aae] defines an Agent Authorization Envelope and verification algorithm. Its Section 6.1 defines PERMIT, PENDING, and DENY verdicts, and says a relying party that cannot evaluate MUST deny. This document is compatible with fail-closed behavior: denial may be the safe action. The additional requirement here is to preserve that the denial resulted from an input that could not be established, where that is the reason. Sections 6 and 8 of [I-D.asor-wimse-agent-delegation-chain] define offline verification and revocation checking for delegation chains, and its Section 9.5 identifies the revocation-latency trade-off created by offline verification. This document uses that as an example of a status/freshness input whose value and freshness need to remain visible. Konda Expires 8 April 2027 [Page 14] Internet-Draft Evaluation State in Agent Protocols October 2026 [I-D.carleton-workload-authz-grant], Sections 6.1, 6.2, 6.3, and 7 discuss issuer keys, permissions, multi-tenancy, and error responses that indicate who must act. This document is consistent with that operational direction: an error or refusal is more useful when it identifies whether the caller, platform, authorization server, resource server, or an administrator can act. 11. Privacy and Oracle Considerations Evaluation state can reveal sensitive information. A response that identifies the unavailable issuer, parent grant, delegation path, policy profile, or revocation source can become an oracle for a caller that should not learn another domain's graph or policy state. A protocol or deployment therefore needs two audiences: * caller-facing state, which may be coarse; and * operator-facing state, which needs enough detail for incident reconstruction. A caller-facing response can say that evaluation did not complete, or that the refusal is transient, without naming the failed path or source. The decision point's own record can name the source, freshness bound, and input that failed, subject to local access control and retention policy. Timing can also reveal evaluation state. A verifier that stops at the first unavailable source may answer faster for some chains than for others. Where chain structure or source availability is sensitive, implementations should consider evaluating independent inputs in a way that does not disclose the location of the failure through response time. 12. Security Considerations Fail-closed denial remains necessary for many unavailable inputs. This document does not recommend accepting an action merely because a required source is unavailable. It recommends preserving that the denial came from failure to establish an input, not from an established negative input. Ambiguous refusals can create retry storms. If a transient failure appears as a generic denial, callers may retry immediately and at scale. If a permanent denial appears transient, callers may also retry unnecessarily. Protocols should give callers enough coarse state to make safe retry choices without exposing sensitive internals. Konda Expires 8 April 2027 [Page 15] Internet-Draft Evaluation State in Agent Protocols October 2026 Stale positive values can widen authority. A status, standing, profile, or consumption value that was positive earlier may no longer be positive at the current decision time. Deployments need explicit freshness bounds and should record when stale state caused refusal. Missing records can erase the distinction this document relies on. A deployment should document whether a decision point continues to admit, refuse, or halt when it cannot write its operator-facing record. Cross-domain deployments need to avoid treating another domain's failure to supply a detail as proof that the detail is false. They also need to avoid treating a locally unestablished input as if it were globally impossible to establish. Finally, evaluation-state vocabularies need input bounds. A request that can force a decision point to record unbounded input names, source identifiers, unresolved lists, or diagnostic strings can become a resource-exhaustion vector. 13. IANA Considerations This document has no IANA actions. The subsequent revision described in Section 1 is expected to define concrete protocol fields and status or error values, together with the evaluation-state and unavailable-input vocabularies. Any registry requests belong with that revision. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 14.2. Informative References Konda Expires 8 April 2027 [Page 16] Internet-Draft Evaluation State in Agent Protocols October 2026 [I-D.ahuja-agent-routing-policy] Ahuja, S. P., "A Policy Grammar for Inter-Domain Agent Routing", Work in Progress, Internet-Draft, draft-ahuja- agent-routing-policy-01, September 2026, . [I-D.asor-wimse-agent-delegation-chain] Asor, R., "Verifiable Attenuated Delegation for AI Agent Chains", Work in Progress, Internet-Draft, draft-asor- wimse-agent-delegation-chain-01, September 2026, . [I-D.carleton-workload-authz-grant] Carleton, P., Steele, N., and A. Parecki, "Workload Authorization Grant", Work in Progress, Internet-Draft, draft-carleton-workload-authz-grant-00, September 2026, . [I-D.gilda-wimse-agent-audit-record] Gilda, S., "An Audit Record Format for AI Agent Authorization Decisions", Work in Progress, Internet- Draft, draft-gilda-wimse-agent-audit-record-01, September 2026, . [I-D.jackson-wimse-evaluation] Jackson, W., "Verifier-Side Evaluation Semantics for Delegated Authority Chains", Work in Progress, Internet- Draft, draft-jackson-wimse-evaluation-03, September 2026, . [I-D.kroehl-agentic-trust-aae] Kroehl, L. K., "Agent Authorization Envelope (AAE): A Machine-Evaluable Authorization Structure for Autonomous AI Agents", Work in Progress, Internet-Draft, draft- kroehl-agentic-trust-aae-02, September 2026, . Konda Expires 8 April 2027 [Page 17] Internet-Draft Evaluation State in Agent Protocols October 2026 [I-D.rosenberg-agentproto-usecases] Rosenberg, J. and C. Jennings, "Framework, Use Cases and Requirements for AI Agent Protocols", Work in Progress, Internet-Draft, draft-rosenberg-agentproto-usecases-00, July 2026, . [I-D.wei-aic-identity-cert] Wei, J., "AI Agent Identity Certificate (AIC) Extension for X.509 v3", Work in Progress, Internet-Draft, draft- wei-aic-identity-cert-02, October 2026, . [I-D.wei-capability-language-core] Wei, J., "Capability Language Core", Work in Progress, Internet-Draft, draft-wei-capability-language-core-00, September 2026, . Author's Address Girish Konda Email: girish.sai1@gmail.com Konda Expires 8 April 2027 [Page 18]