Mission-log completeness under agent–PS partition: a gap §14.16 and §12.7.4.1 don't close

[ZeeshanKhanSA]

v08's §14.16 (non-repudiation after key rotation) and §12.7.4.1 (freshness and replay) close the request-level cases well: archive-at-verification preserves "key K signed request R at time T," and the created-window replay cache rejects duplicate request tuples. Both operate on the signed HTTP request at the resource/verifier. I want to surface a residual case they don't reach, at the mission-governance layer, when the agent is partitioned from its PS — a long-running, intermittent, or workload/self-hosted (§16.9) agent acting across a network gap.

The setup: §7.5.2 keeps audit fire-and-forget ("the agent SHOULD NOT block on the response"), and approved_tools (§7.4, §8.2) let the agent act locally without reaching the PS per action. §8.3 keeps the asymmetry — the mission description is s256-immutable, but the mission log is a PS-maintained ordered record with no expected-sequence integrity of its own. Two cases follow:

1. Suppression / tail-truncation. A partitioned agent performs approved_tools actions and never emits the corresponding audit records. §14.16's archive-at-verification doesn't help here: the agent made no request to any verifier while disconnected, so there's nothing to archive. The PS can't distinguish "agent did nothing during the gap" from "agent acted and didn't report it," because the log has no issued sequence the agent must account for. (This is the tail-truncation @jagmarques flagged in Non-repudiation and key rotation: audit trail considerations? #3 — an external witness catches mid-log edits but not a silently short tail.)
2. Stale-mission replay. Distinct from §12.7.4.1's request replay. The agent re-presents an earlier validly-signed mission state as current after the surrounding context moved on — e.g. the mission was revoked per §8.5/§12.6 during the partition. s256 still verifies (the mission is immutable by design), and §12.7.4.1's cache is scoped to the created window (default 60s) and to duplicate request tuples, so neither signals that the mission state is stale at the multi-hour timescale of a partition.

The distinction I'd want explicit: §14.16 gives durable evidence of requests that were made and verified; §12.7.4.1 bounds replay of a single signed request within its window. Neither makes a gap in what the agent should have logged, or a replayed-stale mission state, detectable after reconnection. Closing those needs something at the agent↔PS contract level — a per-mission monotonic counter or pre-issued jti/nonce range the PS issues and the agent must consume in order, so a missing index is detectable rather than invisible. That's wire surface (what the PS hands the agent), not PS storage internals — which is why I think it's protocol-shaped rather than the kind of PS-implementation detail that closed PR #10.

So, concretely: (a) Is offline/deferred governance in scope — may an agent perform approved_tools actions while it can't reach the PS, or is the model strictly online? (b) If deferred governance is in scope, does the expected-sequence contract belong in the §8.5 companion spec for mission state transitions, or is mission-log completeness considered out of protocol scope entirely (as PR #10's chaining was)? Genuinely unsure where the line sits, which is why I'm asking. Happy to write the partition cases up as concrete sequences.

[dickhardt]

Thanks for the detailed analysis — the distinction between request-level integrity (§14.16, §12.7.4.1) and mission-log completeness is drawn precisely, and the two cases are worth addressing directly.

On (a): offline deferred governance is in scope. approved_tools is explicitly designed for agents that act without per-action PS contact — headless workloads, intermittently-connected agents, and self-hosted deployments are first-class use cases. An agent performing approved tools while partitioned from its PS is expected behavior, not an edge case.

On tail-truncation (case 1): The audit endpoint is governance signaling, not a tamper-evident complete log, and the spec doesn't claim completeness. The accountability line sits at the PS's trust decision when it grants approved_tools — the PS is asserting that it trusts the agent enough to act offline without per-action confirmation. An agent that silently drops audit records is outside that trust model; an agent with that threat profile shouldn't be granted approved_tools in the first place. A PS that needs strong audit coverage for every approved-tool action can decline to grant approved_tools and require per-action permission calls instead — that's an always-online governance model and it works fine for that deployment.

A sequence-counter or pre-issued nonce range would enforce completeness technically, but it would change the interaction model significantly: the PS would have to issue "work permits" before the agent acts, which undermines the offline use case that approved_tools enables. For PSes that want stronger guarantees, this is implementable internally without protocol changes — the PS issues nonces alongside the approved-tool grant and tracks consumption — but mandating it in the protocol would overconstrain the common case.

On stale-mission replay (case 2): Resource tokens have a maximum 5-minute lifetime. After the PS marks a mission revoked, it denies all new token requests referencing that mission's s256. A partitioned agent continues acting only until its outstanding tokens expire, at which point it must contact the PS for new ones and gets a mission-status error. The window is bounded by token lifetime — the same acknowledged tradeoff in any token-based system.

On (b): Sequence-counter mechanics belong at the PS implementation level, not the protocol level, for the same reason PR #10's log chaining did: the PS controls token issuance and can track what it issued without needing wire-level protocol changes. Nothing in the protocol prevents a PS from adding this.

One thing worth adding to the spec is an explicit note in the approved_tools section: that granting approved_tools is a trust decision about offline accountability, and PSes that require complete audit coverage should either not grant approved_tools or enforce connectivity requirements at the deployment level. That surfaces the design tradeoff without a protocol change.

If you see a gap in that reasoning — particularly around the stale-mission case or a scenario where the token-lifetime bound doesn't hold — please follow up and we can dig into it further. Otherwise I'll plan to close this in two weeks.

[ZeeshanKhanSA]

This resolves it for me, with one residual question on case 2.

On case 1 — agreed, and I think you've put it in the right place. Completeness as a trust-model boundary at the approved_tools grant, rather than a wire mechanism, is the coherent call: the PS asserting offline trust and an agent that silently drops records being outside that trust model is a cleaner accountability line than a mandated counter would be. And you're right that a PS wanting guaranteed coverage has two honest options already — decline approved_tools, or issue-and-track nonces internally alongside the grant. That's PS-internal, same boundary as PR #10; I shouldn't have implied otherwise given I'd already called it wire-surface. The proposed approved_tools spec note — making the offline-accountability tradeoff explicit — is exactly the right resolution, and it's a better outcome than a protocol change.

On case 2, one thing I want to make sure I'm reading correctly. The 5-minute bound is clear for resource access — no live auth token, no resource call, and revocation denies new token requests. What I'm less sure about is a local approved_tools action during the partition. A pre-approved tool call — a file write, a local action, sending a message — doesn't consume a resource token or require a PS round-trip; that's the point of pre-approval. So if the mission is revoked mid-partition, what bounds the agent's continued execution of locally-authorized actions? It isn't the resource-token lifetime, since those actions don't take resource tokens — it seems to be time-to-next-PS-contact, which under partition is unbounded by design. Resource access fails safe offline; local governed action doesn't seem to have the same expiry.

If the answer is that approved_tools blast radius is bounded by what local tools can do — which the PS accepted when it granted them offline — then case 2 collapses into the same trust-model boundary as case 1, and I'm satisfied. I just want to confirm that's the intended reading rather than the token-lifetime bound, since they come apart exactly on the offline-local path. Either way, agreed on closing — the spec note covers the substantive gap.