Interval Absence Claims in Agent Auditing: Problem Statement, Requirements, and Test Scenarios

Introduction Autonomous and semi-autonomous agents receive credentials, tokens, network routes, database privileges, and tool permissions, often for short periods and often through several layers of delegation. Work on auditing such systems, for example the architecture in , focuses on linking user intent, delegation, authorization, and execution so that an auditor can reconstruct what happened. In incident response, compliance reviews, and customer due diligence, the question is often negative rather than positive: during the interval from time T0 to time T1, could this agent have used this capability on this resource? A "no" answer is an interval absence claim. It is a statement about the whole interval, not about the actions that happen to be recorded. Records of actions cannot carry this claim by themselves. Authority that was granted and removed without ever being exercised leaves no action record, yet the capability was usable for part of the interval. A snapshot of granted capabilities at T0 and another at T1 can both be empty in the same case. Records of authorization changes help, but only if the auditor also knows that every change was recorded, that removal of a grant actually ended its use, and that failures and recovery did not create changes outside the record. Existing drafts mark this limit. The audit architecture notes that, where attestation Evidence is unavailable, "that absence is itself an audit-relevant fact and can be recorded" (). That records the absence of evidence; it is not evidence of absence. The same document states that it does not solve the case of an adversarial service that refuses to record what happened at its boundary (). A SCITT profile for agent action receipts has a section titled "Absence is not a negative claim" (). Several recent drafts make the same point for actions: a missing record does not show that an action did not occur (, ). This document asks the corresponding question for authority. Its subject is a capability that may never have been exercised, and its claim covers every point of an interval rather than a particular action. states that it does not address the validity of a delegation or an authorization; this document addresses a related question. It does not propose a mechanism and does not ask for a new deliverable. It is intended as input to the treatment of authorization as a time-evolving state in . It describes:

what an interval absence claim asserts and why action records do not establish it ();
requirements that an evidence system needs to meet before such a claim can be relied on (); and
test scenarios that separate systems that report absence while the capability was in fact usable from systems that answer correctly ().

The requirements are stated as properties of a solution, not as protocol conformance requirements, and this document does not use the requirements keywords of BCP 14.

Terminology

Capability:: Anything that allows a principal (for example, an agent) to use a resource at an enforcement point: a key, token, network route, privilege, role membership, or tool permission.
Usable:: A capability is usable by a principal at a point in time if the principal could use it at that time to change state or obtain information: for example, a credential has been issued and disclosed to it and is still accepted where it is presented, a privilege or route is in effect at an enforcement point, or lingering authority still admits its use. Usability is distinct from use; a usable capability may never be exercised.
Covering capability:: A capability, or a combination of capabilities used together, that grants at least what the capability in question grants, for example a wildcard, a role that includes a privilege, or a policy binding that grants a superset of it.
Checkpoint:: A point in the evidence at which the state of the relevant records and inventories is fixed and can later be referred to.
Interval absence claim:: A claim that, in a named domain, a named capability and every covering capability were not usable by a named principal, or by any member of a named set of principals, at any point of an interval that begins and ends at checkpoints, including both checkpoints.
Lingering authority:: The ability to keep exercising a capability after the authoritative state has removed it, for example through an existing session, a cached authorization decision, or a long-lived connection.
Revocation debt:: Lingering authority, or copies held outside the domain, that have not been confirmed as ended after a revocation.
False-safe outcome:: An outcome that reports absence for a capability that was usable at some point in the interval.

This document uses three outcome categories for an interval absence query:

ABSENT:: The evidence establishes that neither the capability nor any covering capability was usable at any point in the interval. This outcome needs evidence that is complete under a stated completeness property (REQ-4).
PRESENT:: Valid evidence shows that the capability, or a covering capability, was usable at some point in the interval. PRESENT does not mean that the capability was exercised.
INDETERMINATE:: The evidence is insufficient for either of the other outcomes.

Scope and Assumptions A claim concerns one principal or a declared set of principals, one capability together with its covering capabilities, one domain, and one interval. The following are assumed:

Services that grant or remove authority can fail to record, record late, crash between a decision and its effect, or be adversarial in the sense of .
The principal can be adversarial. In particular, it can try to keep authority alive, for example by holding a session open across a revocation.
The party that compiles evidence for a relying party is not trusted. The relying party, or a verifier acting for it, checks the evidence itself.
The relying party trusts the source of checkpoints and the times assigned to them, the keys of the parties that sign records, and, to the extent a system relies on it, attestation of the configuration of enforcement points and of the paths by which a capability can become usable or stop being usable .

Out of scope: fabrication of evidence by a party the relying party trusts; compromise of the common trust base, including compromise of an enforcement point that its attestation does not reveal; authority exercised against systems outside the domain; and the separate question of whether the principal actually exercised a capability.

Problem Statement

Action Records Do Not Establish Absence Action records describe uses. An absence claim concerns usability. The two diverge whenever a capability is usable but not exercised: a grant that is issued and withdrawn without use produces no action record. If the grant and the withdrawal both happen between two inventory snapshots, the snapshots do not show it either. An auditor who reasons "no recorded use, therefore no authority" reaches a false-safe outcome. Records of authorization transitions, such as those described in , close part of this gap. An ordered sequence of them reconstructs the authorization in force at a time, but only for the transitions that were recorded. An absence claim additionally depends on knowing that no transition happened outside the record.

Ambiguous Removals Transition records can carry the state before a change; the example in has a previous_state member, which records what the recording system held to be in force. Consider a request to remove a capability that was never granted, and a different case in which the capability was granted through a path that did not produce a record and was then removed. The recording system can hold the same prior state in both cases. If removal records do not distinguish the cases, the evidence for both can be the same, and an auditor cannot tell them apart.

Removal Is Not the End of Usability Many systems check authorization when a session or connection is established, or when a request is first admitted, and do not check it again for each use. After the authoritative state removes a capability, an existing session can continue to exercise it. The inventory then correctly shows that the capability is no longer granted, while the capability remains usable through lingering authority. An absence claim for an interval that starts after the removal cannot be supported unless the lingering authority was ended, or made unusable, before the interval began. Likewise, a use admitted before a removal and still in progress keeps the capability usable until that use ends. Revocation also does not take effect everywhere at once. OAuth token revocation notes that an invalidation can take time to reach every server that accepts a token, and a token status list describes the status of a credential that a relying party has to consult. A relying party that does not consult the status on every use, or that holds state derived from an earlier check, can still act on the credential. Revocation status at a point in time and usability at that point are therefore different facts.

Failures and Recovery Components that change authorization can stop or stall in the middle of a change. Recovery procedures then decide whether unfinished changes took effect. If a stalled component later resumes and applies a grant that recovery recorded as not having taken effect, the record and the actual state disagree. Changes that were in progress at a checkpoint raise the same question: evidence that ignores them can report ABSENT for an interval in which such a change took effect.

Coverage and Trust An absence claim is only as strong as the coverage of the paths by which a capability can become usable or stop being usable. A path that is not recorded, a recorder that is unavailable, or a service that does not record at its boundary leaves a gap. The claim also depends on assumptions about the operator, the enforcement point, and the keys that protect the evidence. These assumptions differ between deployments and need to be stated, because the same outcome means different things under different assumptions. Agents increasingly act across domains. A record, message, or shared state produced in one domain can be the input that makes a capability usable in another. An absence claim scoped to one domain says nothing about paths that enter it from elsewhere unless those paths are accounted for.

Requirements for Evidence Systems The following requirements describe what an evidence system needs to provide before a relying party can treat an ABSENT outcome as meaningful. They are independent of record formats and of the mechanisms used to meet them. REQ-1, REQ-2, REQ-3, REQ-12, and REQ-13 concern the question and how outcomes are reported, and apply to any system. The others concern what the evidence of a particular deployment has to show; they are where that deployment's trust assumptions (REQ-12) come in.

REQ-1 Bounded question:: An absence claim names the principal, the capability, the domain, and an interval that begins and ends at checkpoints and includes both. An outcome applies only to that question. Any part of the domain excluded from the claim is stated, and the outcome is not ABSENT if the excluded part grew during the interval. Where the claim names an agent together with the sub-agents it created or delegated to, the set includes those that existed during the interval and their descendants, and the evidence shows that the set is complete over the interval. The outcome is then PRESENT if it is PRESENT for any member, and ABSENT only if it is ABSENT for every member.
REQ-2 Three outcomes, biased against false-safe:: A system distinguishes ABSENT, PRESENT, and INDETERMINATE. When the evidence for ABSENT is incomplete, it reports INDETERMINATE rather than ABSENT. When the evidence shows that the capability was usable at some point, the outcome is PRESENT, whatever gaps remain elsewhere. A system that always reports INDETERMINATE never errs but is of no use; in cases where the stated evidence is complete and the capability was not usable at any point, a system is expected to report ABSENT.
REQ-3 Covering capabilities:: The claim accounts for every capability that covers the named one. Where the covering relation can only be approximated, the approximation does not leave out a capability that might cover the named one. If the covering relation, or the way capabilities are named, changed during the interval, the claim accounts for the change. A combination of capabilities counts as usable only at points when all of its parts are usable at once; an outcome for a combination is ABSENT only if the parts are shown never to have been usable at the same time.
REQ-4 Stated completeness:: An ABSENT outcome follows from a completeness property of the evidence that the system states and that a verifier can check, for example that every path by which the capability can become usable was recorded throughout the interval, together with whatever inventories the property requires. Partial coverage is not enough. If the set of paths or the components that operate them changed during the interval, the property covers the paths before and after the change.
REQ-5 Consistent endpoint inventories:: Where a claim relies on an inventory of usable capabilities at a checkpoint, the inventory is complete for the relevant capabilities and is consistent with the record at that checkpoint. A failed or inconsistent inventory rules out ABSENT; the outcome is then PRESENT if other evidence shows that the capability was usable, and INDETERMINATE otherwise.
REQ-6 Unambiguous removals:: Where a claim relies on records of removal, the evidence lets a verifier distinguish the removal of a capability that was in force from a request concerning a capability that was not, so that the two cases of can be told apart.
REQ-7 Changes in progress:: Authorization changes that were in progress at a checkpoint are visible to the verifier, and the evidence shows whether any of them made the capability usable inside the interval.
REQ-8 Lingering authority and revocation debt:: For an interval that follows a removal, the evidence shows that lingering authority derived from the removed capability was ended or invalidated before the interval began, or the outcome is not ABSENT. Lingering authority that cannot be confirmed as ended is reported as revocation debt rather than as removed. Removal of an internal capability and deletion of copies held outside the domain are reported separately.
REQ-9 Recovery:: Before a checkpoint that follows a failure is relied on, the evidence shows that no change begun before the failure can still take effect without being recorded.
REQ-10 Link to enforcement:: Where usability is decided at an enforcement point, the evidence ties the recorded state to the configuration of the enforcement point across the interval. If that configuration could not be confirmed at a checkpoint, the outcome is not ABSENT.
REQ-11 Cross-domain inputs:: Where records, messages, or shared state from another domain can make a capability usable in the named domain, those inputs are treated as paths under REQ-4. An outcome for one domain does not imply an outcome for a combination of domains.
REQ-12 Stated assumptions and independent checking:: Each outcome is accompanied by the trust assumptions under which it holds, including assumptions about the operator, the enforcement point, time sources, and signing keys. A relying party can check the outcome against the evidence without relying on the operator's own conclusion.
REQ-13 Attribution by effect:: Events are assigned to an interval by when they took effect, not by when they were recorded. A removal recorded before the interval that takes effect inside it, for example when a lingering session ends, belongs to the interval, as does a removal still in progress at either checkpoint.

Test Scenarios The scenarios below describe runs in which the ground truth is known by construction. Each system declares its completeness property (REQ-4) before the evaluation, and results state which property each run relied on. An evaluation runs each scenario against the system under test and compares the reported outcome with the acceptable outcomes. Scenarios T-1 to T-14 check that a system does not report ABSENT without sufficient evidence; the primary measure over them is the false-safe rate. Scenarios T-15 to T-22 check usefulness: each has one expected outcome, and a system that reports INDETERMINATE in them never errs but fails the scenario. In every scenario, PRESENT is a failure where the ground truth is not usable. The scenarios are independent of any record format.

T-1 Unused grant:: A capability is granted inside the interval, never used, and removed inside the interval. Ground truth: usable. Acceptable: PRESENT or INDETERMINATE.
T-2 Ambiguous removal:: Case A: a removal is requested for a capability that was never granted. Case B: the capability is made usable through a path that produces no record and is then removed through a recorded path. Ground truth: A not usable, B usable. Acceptable: for A, ABSENT or INDETERMINATE; for B, PRESENT or INDETERMINATE. The two cases are scored as a pair, and reporting ABSENT for both is a failure.
T-3 Lingering session after revocation:: A capability is removed before the interval begins, and the removal is recorded. An existing session continues to be able to exercise the capability during the interval but does not use it. Ground truth: usable. Acceptable: PRESENT or INDETERMINATE.
T-4 Late completion after recovery:: A component begins a grant and stalls. Recovery records the grant as not having taken effect. The component resumes and applies the grant inside the interval. Ground truth: usable. Acceptable: PRESENT or INDETERMINATE.
T-5 Change in progress at a checkpoint:: A grant is in progress at the start checkpoint and takes effect inside the interval. Ground truth: usable. Acceptable: PRESENT or INDETERMINATE.
T-6 Covering capability:: The named capability is never granted, but a covering capability (for example, a role that includes it) is usable during part of the interval. Ground truth: usable. Acceptable: PRESENT or INDETERMINATE.
T-7 Missing evidence (paired):: Two runs leave the same evidence: in both, a piece of evidence on which the declared completeness property relies is missing, for example an endpoint inventory or the records of one path. In the first run the capability is not usable at any point; in the second, the missing part would have shown a grant. Acceptable: for the first run, INDETERMINATE; for the second, PRESENT or INDETERMINATE.
T-8 Unrecorded path:: The capability is made usable through a path that the stated completeness property does not cover, for example an interface added during the interval, which produces no record. Ground truth: usable. Acceptable: PRESENT or INDETERMINATE.
T-9 Renamed resource:: The resource is renamed during the interval. The capability is granted under the old name, and the claim is made under the new one. Ground truth: usable. Acceptable: PRESENT or INDETERMINATE.
T-10 Inventory omission:: The capability is usable at the start checkpoint, but the inventory taken there omits it. Ground truth: usable. Acceptable: PRESENT or INDETERMINATE.
T-11 Record gap:: A grant is made inside the interval, and its record falls in a gap in the record sequence. Ground truth: usable. Acceptable: PRESENT or INDETERMINATE.
T-12 Growing exclusion:: The excluded part of the domain grows during the interval to cover the enforcement point through which the capability was granted. Ground truth: usable in the domain as originally stated. Acceptable: PRESENT or INDETERMINATE.
T-13 Early completion record:: A grant is recorded as complete at a step that does not yet make the capability usable, and a later step makes it usable inside the interval without a further record. Ground truth: usable. Acceptable: PRESENT or INDETERMINATE.
T-14 Sub-agent:: The claim names an agent and its sub-agents. The agent never holds the capability, but a sub-agent holds it during part of the interval. In one variant the sub-agent was created before the interval; in another it was created during the interval by a step that produced no record. Ground truth: usable. Acceptable: PRESENT or INDETERMINATE.
T-15 Recorded grant or removal:: Either a grant is made inside the interval through a covered path, or a capability usable at the start checkpoint is removed inside the interval, and the evidence required by the declared completeness property is intact. Ground truth: usable. Expected: PRESENT. INDETERMINATE here shows that the system does not use evidence it has.
T-16 Busy interval:: Many capabilities that do not cover the named one are granted and removed during the interval, in the same domain and through the same paths. Neither the named capability nor any covering capability is usable at any point, and all evidence required by the stated completeness property is present. Ground truth: not usable. Expected: ABSENT.
T-17 Removal of a capability not in force:: Case A of T-2, where the evidence distinguishes a removal of a capability that was in force from a request concerning one that was not (REQ-6) and is otherwise complete. Ground truth: not usable. Expected: ABSENT.
T-18 Session ended before the interval:: As in T-3, but the session was ended before the interval began, and the evidence shows this (REQ-8). Ground truth: not usable. Expected: ABSENT.
T-19 Denied request:: A grant of the capability is requested during the interval and denied. Nothing else relevant happens, and all evidence required by the stated completeness property is present. Ground truth: not usable. Expected: ABSENT.
T-20 Abandoned grant:: A grant of the capability that was in progress at the start checkpoint is abandoned, and the evidence shows that it did not take effect at any point in the interval (REQ-7). Ground truth: not usable. Expected: ABSENT.
T-21 Parts not usable together:: The named capability is realized only by a combination of two parts. Each part is usable during the interval, but not at the same time, and the evidence establishes the order of each part's grants and removals. Ground truth: not usable. Expected: ABSENT (REQ-3).
T-22 Quiet interval with complete evidence:: Nothing relevant happens, and all evidence required by the system's stated completeness property is present. Ground truth: not usable. Expected: ABSENT. This scenario checks that a system meets REQ-2 by doing more than reporting INDETERMINATE.

Scenarios T-3, T-4, and T-18 depend on the timing of sessions and failures. An evaluation that reports results for these scenarios states how the ground truth for lingering authority and resumed components was established.

Relationship to Agent Audit Architecture and Other Work The architecture in describes Authorization Transition Records and notes that an ordered sequence of them reconstructs the authorization in force at any point in a recorded run. The requirements above describe what such records would additionally need in order to support absence claims. The following questions may be useful in discussions of that work:

Can a stream of authorization transition records state which paths it covers, so that an auditor can tell whether a missing transition means "none occurred" or "not observed" (REQ-4)?
When a transition record carries a prior state, as in , how can an auditor tell the two cases of apart (REQ-6)?
Should an auditor-facing query interface distinguish ABSENT, PRESENT, and INDETERMINATE rather than return an empty result for "no records found" (REQ-2)?
Should deployment guidance address lingering authority after revocation and its reporting as revocation debt (REQ-8)?

Other individual drafts in the same discussion address neighbouring questions. sets out what a check of agent audit records can and cannot establish, including that the absence of a record is not evidence that an action did not occur. ties evidence requirements to specific audit questions and separates a missing record from a negative observation; its authority question concerns whether an admitted action was within the authority that applied at the time. separates the decision, dispatch, receipt, enforcement, and observed effect of control instructions such as revocation; evidence of that kind is an input to REQ-8. Record formats such as and record authorization decisions, permissions, cancellations, and receipts, and state their own limits, for example that a coverage check does not establish that every path was read, or that whoever keeps a log can leave out entries. The requirements here concern a different question: whether a capability, exercised or not, was usable at any point of an interval. Transparency services and transparency logs make the existence and order of registered statements verifiable. Non-inclusion of a statement in such a log supports an absence claim only when the log is known to contain every relevant event, which is a completeness property in the sense of REQ-4 rather than a property of the log. Remote attestation can support REQ-10 by providing evidence about the configuration of an enforcement point. Continuous access evaluation events , such as session revocation, signal that a session has been revoked; the event does not show that the session ended at every place it was in use. A token status list shows the status of the tokens it lists, not that no token was issued outside it. Both are useful inputs to REQ-8 and REQ-4, but neither is by itself evidence that those requirements are met.

Security Considerations The main risk addressed by this document is a false-safe outcome: a report that a capability was not usable when it was. Such a report can close an incident investigation early, misdirect responsibility, or support a compliance statement that is not true. The requirements in are aimed at preventing false-safe outcomes, at the cost of reporting INDETERMINATE more often. An ABSENT outcome holds only under its stated assumptions (REQ-12). It does not hold against an operator that fabricates evidence or omits evidence that the stated completeness property relies on, against compromise of the keys that protect the evidence, or against a compromised enforcement point. Evidence designs that limit the trust placed in any single party reduce these risks but do not remove them. Omissions of evidence fall into three kinds. Some are visible in the evidence itself, such as a gap in a record sequence or a failed inventory; they rule out ABSENT (REQ-5, T-7, T-11). Some cannot be seen in the evidence but are excluded by the stated assumptions, for example an omission that only a trusted signer could make; an ABSENT outcome holds only as long as those assumptions do (REQ-12). Any other omission means that the stated completeness property is not established, and the outcome is not ABSENT (REQ-4). PRESENT says nothing about whether a capability was exercised or misused. A relying party that reads PRESENT as misuse, or ABSENT as proof that no harm occurred through other means, overstates what the outcome says. Checkpoints depend on time sources and ordering. Clock error and delayed observation can move an event across a checkpoint boundary; evidence systems account for them when deciding which interval an event belongs to.

Privacy Considerations Evidence that one capability was absent can reveal information about other capabilities and principals. Deployments that share such evidence with external auditors consider what it discloses and may use selective-disclosure techniques. Absence evidence also links a principal to a resource and an interval and needs the same retention and access controls as other audit records.

IANA Considerations This document has no IANA actions.