Preserving Evaluation State in Agent Protocol Decisions
draft-konda-agentproto-evaluation-state-00

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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,
              <https://datatracker.ietf.org/doc/draft-ahuja-agent-
              routing-policy/>.

   [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,
              <https://datatracker.ietf.org/doc/draft-asor-wimse-agent-
              delegation-chain/>.

   [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,
              <https://datatracker.ietf.org/doc/draft-carleton-workload-
              authz-grant/>.

   [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, <https://datatracker.ietf.org/doc/draft-gilda-wimse-
              agent-audit-record/>.

   [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,
              <https://datatracker.ietf.org/doc/draft-jackson-wimse-
              evaluation/>.

   [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,
              <https://datatracker.ietf.org/doc/draft-kroehl-agentic-
              trust-aae/>.

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, <https://datatracker.ietf.org/doc/draft-
              rosenberg-agentproto-usecases/>.

   [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,
              <https://datatracker.ietf.org/doc/draft-wei-aic-identity-
              cert/>.

   [I-D.wei-capability-language-core]
              Wei, J., "Capability Language Core", Work in Progress,
              Internet-Draft, draft-wei-capability-language-core-00,
              September 2026, <https://datatracker.ietf.org/doc/draft-
              wei-capability-language-core/>.

Author's Address

   Girish Konda
   Email: girish.sai1@gmail.com

Konda                     Expires 8 April 2027                 [Page 18]