| Internet-Draft | Evaluation State in Agent Protocols | October 2026 |
| Konda | Expires 22 April 2027 | [Page] |
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. Test cases for the requirements are included, with a machine-readable form published separately.¶
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 22 April 2027.¶
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.¶
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.¶
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.¶
Section 7.1 gives test cases for the evaluation states and requirements below, and [EVAL-STATE-VECTORS] gives them in machine-readable form, using the state names in Section 6 and candidate names for the reason recorded with each state. Section 4.2 describes what a report of a policy profile that is not held needs to carry. How a protocol encodes this state is left to that protocol, or to a later document.¶
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.¶
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.¶
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.¶
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.¶
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.¶
The decision point did not complete evaluation because one or more required decision-time inputs were not established.¶
The decision point has an older value for an input, but at the time of the decision the value's age is greater than the freshness bound required for the decision. An age equal to the bound is within it.¶
The observation layer cannot determine whether an effect occurred. This document uses "indeterminate" for observation state, not as a substitute for "not evaluated".¶
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.¶
A durable operator-facing record of a decision, refusal, effect, or observation. This document does not define an audit record format.¶
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.¶
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.¶
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. Section 7 of [I-D.schrock-ep-bounded-capability-receipts] defines PROFILE_NOT_HELD and NO_COMPARISON_RELATION as distinct reasons for UNDECIDED. Section 4 of [I-D.ahuja-agent-routing-policy] adopts those reasons. In the first case, retrieving the exact profile or routing evaluation to a verifier accepted under relying-party policy may remedy the problem. In the second, the verifier holds the exact profile but it supplies no applicable relation. These are different facts about the input, even when both cause refusal.¶
When either result is reported to a participant in another domain, the report needs to carry three things. The first is the reason, so that the two cases do not arrive as a bare UNDECIDED. The second is the exact governing profile identifier, which Section 6 of [I-D.ahuja-agent-routing-policy] requires to name immutable comparison semantics, so that a recipient can tell whether it holds the same definition. The third is the component that was compared, which Section 7 of [I-D.schrock-ep-bounded-capability-receipts] requires a comparison report to record.¶
Carrying the identifier does not establish that the recipient holds or trusts that definition. Other causes of UNDECIDED stay distinct from these two and are not reported as either, as Section 4 of [I-D.ahuja-agent-routing-policy] requires. A later evaluation that obtains the profile produces a new result and leaves the original PROFILE_NOT_HELD report unchanged (REQ-10). How a participant finds a party that holds the profile, and what the next hop does with the result, are out of scope.¶
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.¶
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.¶
"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.¶
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-audit-agent-audit-record], Section 5.4 defines an evaluation member separate from the reported decision. Its evaluation.status value not-evaluated records incomplete evaluation, with unavailableInput naming the inputs the decision point could not obtain. The reported decision still states what was enforced, and evaluation is not an input to agreement. A denial with no observed effect can therefore derive agree even when evaluation.status is not-evaluated. Agreement alone does not establish that evaluation completed.¶
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.¶
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.¶
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.¶
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.¶
Where a later hop establishes an input that an earlier hop could not, it makes a new decision using that input. It does not change the earlier hop's evaluation state or establish that the earlier decision was complete.¶
The negative/unestablished distinction changes operations in four common ways.¶
A negative result may be permanent for the presented 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.¶
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.¶
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.¶
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.¶
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.¶
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:¶
The input was established and satisfied the relevant predicate for the decision.¶
The input was established and did not satisfy the relevant predicate for the decision.¶
The input required for evaluation was not established.¶
A value was available, but its age at the time of the decision was greater than the freshness bound required for the decision. The age is measured from the value's "as of" time, the time at which the input's source produced it, not from the time the decision point received it.¶
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.¶
Implementations need to agree on the boundary itself. In this document, an input whose age equals its freshness bound is within the bound; it becomes stale only when its age is greater. [I-D.gilda-audit-agent-audit-record] uses the same rule (its vector FR2). Section 3 of [I-D.jackson-wimse-evaluation] does not allow a fetched input to be used at or past its horizon, which is its as-of time plus its maximum age. An input whose age equals that maximum is therefore already outside the bound there (cases G2 and G3 in Appendix A.3 of that document). A deployment that reads records produced under both rules needs to settle which one applies.¶
An input that was never established has no "as of" time; it is not-established, not stale. A value whose "as of" time is later than the time of the decision by more than the clock-skew tolerance that the deployment states cannot be placed relative to the decision, and the input is treated as not-established.¶
"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.¶
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.¶
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, for each input the decision depended on, the "as of" time of the value it used and the freshness bound it applied to that input, or the freshness failure that caused the input to be treated as stale or not established. This applies to accepted inputs as well as to stale and not-established ones, so that an evaluated decision can be checked in the same way as one that was not evaluated.¶
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, the evaluation state, the "as of" time from the input's source, and any freshness bound needed by the next hop to resolve, retry, or refuse safely. A receiving hop judges the value against its own freshness bound, measured from that "as of" time and not from the time it received the value.¶
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.¶
REQ-9: When a decision depends on an input whose evaluation state is established by another participant, the protocol SHOULD make that evaluation state available to the deciding participant at the time of the decision, directly or by reference, and not only in a record produced afterwards.¶
REQ-10: A hop that later establishes an input that an earlier hop recorded as not established SHOULD record its own evaluation, and it MUST NOT alter the earlier record or the evaluation state that the earlier hop reported.¶
The cases below are format-neutral. Each states a condition at the time of the decision, the expected evaluation state of the input concerned, and, where it matters, what the operator-facing record needs to show. The final decision is left to local policy except where a requirement in Section 7 constrains it. Where a public draft already defines a matching test vector or worked case, the entry names it. [EVAL-STATE-VECTORS] gives the same cases as machine-readable test vectors, with a checker that applies the rules in Sections 6 and 7.¶
An input whose age at the time of the decision is less than its freshness bound. The input is established-positive or established-negative under the relevant predicate, and the record carries its "as of" time and bound (REQ-4). Cases G1 and G4 in Appendix A.3 of [I-D.jackson-wimse-evaluation] cover this case.¶
An input whose age equals its bound. Under the rule in Section 6, the input is within the bound. Vector FR2 of [I-D.gilda-audit-agent-audit-record] matches this case. Under Section 3 of [I-D.jackson-wimse-evaluation], the same input is already past its horizon (cases G2 and G3 in Appendix A.3 of that document).¶
An input whose age is greater than its bound. The input is stale. A fail-closed refusal is recorded as a refusal on a stale input, not as an established negative (REQ-1, REQ-2). Vector FR3 of [I-D.gilda-audit-agent-audit-record] covers this case.¶
An input the decision point never obtained. The input is not-established and has no "as of" time. Vectors A10 and FR4 of [I-D.gilda-audit-agent-audit-record] cover this case.¶
A source that cannot be reached, and a source whose use the decision point's own retrieval policy prevents. The input is not-established in both cases, not established-negative, and the record names it (REQ-1, REQ-3). REQ-PROP-3 of [I-D.king-dawn-requirements] separates the same two cases for discovery.¶
A lookup that completes and finds that the referenced information is absent. The absence is established, so the input is established-positive or established-negative under the relevant predicate. For example, a token absent from a complete revocation list is not revoked. A lookup that did not complete cannot establish absence; as in TC-5, the input stays not-established. REQ-PROP-3 of [I-D.king-dawn-requirements] states the same rule for discovery.¶
A request that names a cross-domain policy profile that the decision point does not hold (Section 4.2). The input is not-established, not established-negative, and the record carries the reason, the exact profile identifier, and the compared component (REQ-3). Vector A20 of [I-D.gilda-audit-agent-audit-record] covers this case.¶
Consumption state that cannot be read when an approval is presented. The input is not-established, a refusal is transient, and the record does not read as expiry or as consumption. Case E7 in Appendix A.1 of [I-D.jackson-wimse-evaluation] covers this case.¶
A status list that cannot be fetched, or a cached status answer that has outlived its time to live and cannot be refreshed. The input is not-established in the first case and stale in the second, and in neither case is it reported as "not revoked". Step 7 of Section 6 of [I-D.asor-wimse-agent-delegation-chain] treats both as UNKNOWN.¶
A value received from another hop. Its age runs from the "as of" time at its source, not from the time the hop received it (REQ-6). Vectors FR1 and FR3 of [I-D.gilda-audit-agent-audit-record] cover this case.¶
One forwarded value judged at two hops that apply different bounds, for example 7200 and 3600 seconds, when its age lies between them. The input is within the bound at the first hop and stale at the second, and each hop records its own result (REQ-6).¶
A later hop establishes an input that an earlier hop recorded as not established. The later hop records its own evaluation. The earlier record, and the state it reported, stay unchanged (REQ-10).¶
An input whose "as of" time is later than the time of the decision by more than the stated clock-skew tolerance. The input is not-established. Vector FR9 of [I-D.gilda-audit-agent-audit-record] treats a record that carries such a value as malformed.¶
The evaluation state of an input established by another participant reaches the deciding participant only after the decision. The decision is recorded as made without that state. A record written afterwards does not change what was available when the decision was made (REQ-9).¶
A refusal for which the caller receives only a coarse reason. The caller-facing response says only that evaluation did not complete, and the operator-facing record names the input and its state (REQ-5, REQ-8).¶
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.¶
Section 4.2.3 of [I-D.agentic-ai-usecases-requirements] separates dialog continuity from the checks needed at resumption. B1-6 covers persistent dialog identifiers and resumption after network interruption or change. B1-7 requires the protocol to enable the receiving participant to verify that the resuming party is the participant whose exchange was interrupted, that the dialog context presented is the current state of that dialog, and that the dialog has not been terminated or its authorization revoked. B1-8 requires that the dialog not be resumed when any of those checks fails or cannot be completed, that the reason be signaled, and that the receiving participant be able to determine whether the check failed or could not be completed. CMN-12 applies the same distinction to the check a participant makes before accepting a change to a dialog.¶
These checks do not by themselves establish the outcome of an operation submitted before the interruption. Resumption alone does not justify submitting that operation again. If the outcome is still unknown, the operation's identity and unresolved status need to remain available to the participant deciding whether to reconcile or retry. Separately, if a required authorization input cannot be established, the decision point needs to preserve that fact rather than report an established revocation or policy rejection. The requirements in Section 7 apply even when the safe local action is refusal.¶
In the terms of this document, a check that failed rests on an established-negative input, and a check that could not be completed rests on an input that was not established or was stale. A stale input therefore does not count as a completed check that failed. B1-8 and CMN-12 place the distinction at the participant making the check. Where that participant depends on an input whose evaluation state another participant established, REQ-9 asks that the state reach it at the time of the decision, not only in a record produced afterwards.¶
Sections 2 and 2.1 of that document distinguish dialog context from task context, which is not carried by the protocol. This mapping concerns decision-relevant state, not transport of prompts, conversation memory, or complete task context.¶
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.¶
[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-audit-agent-audit-record], Section 5.3 separates decision.reported, effect.observed, and agreement. Section 5.4 adds evaluation.status, with the values evaluated and not-evaluated, and evaluation.inputs, which is required under both. Each entry names one input the reported decision depended on, from the closed set standing-source, key-source, consumption-state, and policy-source. It gives the time the input's source produced the value (lastResult, or none if the decision point never held one) and the maximum age the decision point applied (maxAge). Age runs from lastResult to the time the decision was reported, and an age equal to maxAge is within the bound. Under not-evaluated, unavailableInput names exactly the inputs that were stale or never established.¶
In that format, decision.reported continues to record what was enforced. Evaluation is separate from the policy decision and is not an input to the agreement calculation. The format can represent a fail-open permit with evaluation.status set to not-evaluated; representing that event does not prescribe an admission policy.¶
Those members carry what REQ-4 asks a decision point to record for each input, and that document cites REQ-4 and REQ-6 for them. A value received from another hop keeps its source's lastResult while the receiving hop applies its own maxAge, as REQ-6 describes. A hop that later obtains an input writes a new record and never amends the earlier one, which its producer's signature has sealed; REQ-10 states the same rule. The policy-source input includes a policy profile that a request names and the decision point does not hold, the case in Section 4.2. This document names the stale and not-established states directly, where that format derives them from lastResult and maxAge. This comparison does not define additional members for that audit format.¶
[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 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 the need to preserve why a comparison could not complete. It identifies NO_COMPARISON_RELATION, where the verifier holds the governing profile and the profile supplies no applicable relation, and PROFILE_NOT_HELD, where the exact governing profile definition is unavailable to the deciding verifier, as distinct reasons for UNDECIDED. Its Section 9 requires the relying party to halt under NO_COMPARISON_RELATION. Under PROFILE_NOT_HELD, the chain is not valid to that relying party, which may route the evaluation to a party holding the exact definition. Neither case permits treating the chain as valid by default. Its Section 9 also states that the authenticated relation binding adjacent hops is supplied by another layer, so no chain-wide statement is available where that layer is absent, and that no chain-wide statement spans a mediator that terminates a delegation and originates a new one. Carrying evaluation state between hops, as described in Section 5.3, does not supply that relation and does not extend a chain-wide statement across such a mediator. This document does not redefine that document's comparison vocabulary or chain-validity rules.¶
[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. Step 7 of its Section 6 treats a status reference whose list cannot be fetched, or whose cached answer has outlived its time to live and cannot be refreshed, as UNKNOWN: the verifier denies, and UNKNOWN is not read as not revoked. This document uses that as an example of a status/freshness input whose value and freshness need to remain visible.¶
[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.¶
[I-D.king-dawn-requirements] applies the same distinction to discovery. Its REQ-PROP-3 requires a discovery mechanism to distinguish a reference that does not resolve, a reference whose resolution is prevented by the discovering entity's own retrieval policy, and a reference that resolves but whose referenced information is absent. It also requires a finding of absence to be based on a complete result for the requested lookup. In the terms of this document, the first two cases leave the referenced information not established, and only a completed lookup can establish that it is absent.¶
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.¶
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.¶
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.¶
This document has no IANA actions.¶
A document that defines a concrete encoding for the state names in Section 6, or for the reason names in [EVAL-STATE-VECTORS], may need registries for them.¶
The author thanks Patrick Hopper, Lars Kersten Kroehl, Douglas Wadkins, and Iman Schrock for the discussions that helped shape this document, Vaishnavi Gudur for the discussion of dialog resumption, current authorization, and freshness, Sumit Ahuja for the discussion of UNDECIDED reasons, what a PROFILE_NOT_HELD report carries, and chain validity at delegation hops, and Sankalp Gilda, Wes Jackson, and Cliff Singletary for the discussion of "as of" times, freshness boundaries, and forwarded inputs. Lars Kersten Kroehl also proposed the decision-time wording that REQ-9 follows.¶