What should happen when the Guardian is not there?

[President]

Today there are two options, and I do not like either.
proceed runs the agent with no checks at all.
refuse stops the agent.

What I want is both things at once: the control point stays outside the agent, and the agent keeps working.
That is not possible, so I would like to discuss the trade.

Three ways I can see.

1. The Guardian must always be up.
   Clean, but it is now a single point of failure.
   When it is down, the agent does nothing at all.

2. Graceful degradation, declared by the agent author.
   He writes what still runs without the Guardian, and the list can be narrow: talk to the user, read memory, no tools.
   The agent keeps part of its work instead of stopping, and the author is the one who knows the risk of each tool.
   But the same author can declare everything, and nobody outside can check which of the two lists he wrote.

3. The rules run next to the agent, signed.
   The agent holds a signed rule set and writes a signed record for every step.
   That shows which rules it had and what it decided.
   This one survives an outage and keeps the control outside the agent.
   But it does not show that the agent asked before acting (or can we invent some crypto proof here?)

I do not have an answer. This is to discuss.
Which one should ACS aim at, and why?

[rocklambros]

The three options here all answer the same question, which is what the agent does when the Guardian is gone. There is a prior question worth settling first, and your own objection to option 2 is the thing that surfaces it: "the same author can declare everything, and nobody outside can check which of the two lists he wrote."

That verification problem is not specific to graceful degradation. It already applies to the posture the spec has today.

The spec splits failure into two cases and treats them very differently.

When the Guardian is reachable and a decision fails, on_decision_failure governs. It is negotiated in the handshake, it lives in handshake.json, and both ends therefore agree on it.

When the Guardian was never reachable, §4.1 governs, and it says this:

on_decision_failure is negotiated in the handshake, so it cannot govern a handshake that never completes. When handshake/hello fails ... the Observed Agent applies its startup posture, configured out of band: proceed starts the session unguarded, refuse does not start it. The default is proceed, matching on_decision_failure, so a Guardian outage does not block new sessions.

startup_posture appears in zero of the 44 schemas. It has no wire representation at all.

So the asymmetry runs backwards. The case where a Guardian exists to observe the posture gets a negotiated value. The case where no Guardian exists gets an out-of-band setting that nobody outside the deployment can read. And §4.1 is explicit about where the evidence ends up:

A session started unguarded MUST be recorded in the deployment's own audit log — there is no Guardian to receive the event

The record of running unguarded is held solely by the party that ran unguarded. That is the same structure you objected to in option 2, one level down and already shipped.

Two things follow for the trade you are describing.

Not proposing a different default. proceed versus refuse is a deployment's risk decision and the spec picking it for them breaks permissive-on-implementation. A standard that forces fail-closed gets disabled by the deployments that cannot afford an outage, and then the control is gone entirely rather than merely weak.

Proposing it be discoverable. A deployment that advertises enforcement should not be able to fail open at startup with nothing a counterparty can read. Today a client can claim ACS-Core conformance, run startup_posture: proceed, never reach a Guardian, and present exactly the same external evidence as a deployment that refuses. Whatever posture a deployment picks is legitimate. Picking it invisibly is what makes a conformance claim mean less than it appears to.

That also sorts your three options by a criterion other than preference. Option 3, signed rules plus a signed record per step, is the only one that survives the verification test, because it produces evidence a third party can check rather than evidence the agent author attests to. It is essentially ACS-Crypto plus ACS-Audit applied to the offline case. Worth noting that @nathan-gs reached the same conclusion from the opposite direction on #106: a Guardian operated by someone other than the deployment cannot hold the deployment's symmetric key, so asymmetric signing is what makes an externally-operated Guardian possible at all. Same machinery, and in both cases it is what makes a claim checkable by someone who was not there.

Adjacent and already open: #32 argues §6.4 conflates Guardian refusal with decision failure and that refusals are attacker-reachable, and #37 notes the mandatory fail-open audit event has no conformant shape, so the fail-open rate is unmeasurable today even inside one deployment.

[President]

Rock - agree, no new default, just make it visible (at least to the level we can).

If the agent reaches the Guardian, it declares its startup posture in the ClientHello, and the Guardian records it in the chain.
Small win: we know in advance what this agent does when we are gone.
BUT if the very first handshake fails, the Guardian never learns the agent exists! That case is covered by the conformance claim - #168 (section 5) already has a startup posture row, so it is visible even where no Guardian ever saw the agent.

P.S. The real fix could be an enforcement point outside the agent (I touched it here: #16 (comment)), but that is a separate topic - not for now.