[Bug] Reference Guardian maps AGT escalate to ASK without required ask_details

[shivang-sec]

What is broken

The reference Guardian maps the AGT escalate verdict to an ACS ask decision, but does not synthesize or provide the required ask_details fields for the resulting ACS response.

As a result, an AGT escalation can produce an ACS ask decision without the required approver, question, and timeout information.

Where

reference-implementations/agt/packages/guardian/src/map-verdict.ts

What the specification says, and what happens instead

Specification requirement

ACS v0.1.0 defines the ask decision as a structured response that requires ask_details.

The ask_details object requires:

• approver
• question
• timeout_seconds

The approver itself requires:

• type
• id

The supported approver types are human, agent, and service.

Therefore, mapping an upstream decision to ACS ask requires the resulting response to contain the required ask_details information.

Current reference implementation

The production mapping in reference-implementations/agt/mapping.yaml maps:

escalate: { decision: ask }

However, the reference Guardian's AcsDecision type does not contain an ask_details field.

In packages/guardian/src/map-verdict.ts, mapVerdict() initializes the ACS decision with the mapped decision and synthesizes fields such as:

• reasoning
• reason_codes
• policy_references
• modifications for modify

There is currently no synthesis or population of ask_details when the mapped decision is ask.

The AGT bridge verdict also does not currently expose the required approver, question, or timeout_seconds fields that could be directly forwarded into ask_details.

Observed implementation behavior

The current implementation therefore has this path:

AGT verdict:
escalate
    ↓
mapping.yaml:
escalate → ask
    ↓
mapVerdict()
    ↓
ACS decision:
decision: ask

But there is no corresponding construction of:

ask_details:
  approver:
    type: ...
    id: ...
  question: ...
  timeout_seconds: ...

The existing mapping tests cover that escalate maps to ask, but do not verify that the resulting ACS response is schema-valid and contains the required ask_details.

Expected behavior

When an AGT escalate verdict is mapped to an ACS ask, the Guardian should construct a schema-valid ACS ask response containing the required ask_details fields.

If the required approver/question information cannot be obtained or synthesized, the implementation should follow the approver-incapable behavior described in ACS §9.2 rather than returning an incomplete ask response.

Actual behavior

The reference implementation maps escalate to ask, but mapVerdict() does not construct ask_details, and the current AGT bridge verdict shape does not provide the required approver, question, or timeout information.

As a result, the escalate → ask mapping is incomplete with respect to the ACS response requirements.

Impact on implementers

The issue affects interoperability and ACS conformance for implementations using the reference Guardian's AGT-to-ACS decision mapping.

An AGT escalate verdict is intentionally mapped to the ACS ask decision, but an ACS ask response requires additional structured information. Without ask_details, downstream ACS clients cannot reliably determine:

• who or what should approve the request;
• what question should be presented to the approver;
• how long the approval request should remain valid.

This is also important for implementations that validate ACS responses against the published response schema, because an ask response without the required ask_details does not represent a complete ACS ask decision.

What needs to change

The reference Guardian should handle the escalate → ask mapping explicitly.

A possible implementation path is:

1. Determine whether the required approver, question, and timeout information is available from Guardian-side policy metadata or another existing source.
2. If the information is available, synthesize a complete ask_details object when mapping escalate to ask.
3. Ensure the generated response validates against the ACS response schema.
4. If the reference implementation genuinely has no source for the required approver/question information, follow the approver-incapable behavior described in ACS §9.2 rather than returning an incomplete ask.
5. Add tests covering both the successful ask construction and the unavailable-approver fallback path.

AGT capability assessment

This appears to be a reference-implementation/bridge behavior issue rather than an AGT limitation by itself.

The current AGT bridge verdict shape does not expose approver, question, or timeout_seconds, so the first implementation question is whether these values can be obtained or synthesized from Guardian-side policy metadata.

If they cannot be obtained from AGT or the available Guardian policy context, that limitation should be documented explicitly in the README gaps table and the implementation should use the appropriate §9.2 fallback.

The current code does not appear to have an inherent AGT dependency preventing the Guardian from handling the mapping logic.

Current Priority Scope

Feeds the runnable Guardian reference implementation