intent_bridge classifies malformed decision values as valid denial

[altrudev]

Problem

schema/pic-trace-bridge-v1.json restricts authorization.decision to exactly "allow" or "deny", but intent_bridge.verify_bridge() does not establish that enum at runtime before classifying the decision.

Current verifier logic is effectively:

if authorization["decision"] != "allow":
    raise AuthorizationDenied("the signed decision is not allow")

That means any correctly signed value other than the literal string "allow" is reported as AuthorizationDenied, including malformed values such as:

true
1
null
""
"reject"

Those values are not valid bridge decisions under the published schema. They should therefore be rejected through the bridge's malformed-input boundary, not represented as though the authorizer issued a legitimate signed denial.

Why the distinction matters

AuthorizationDenied means the bridge carried a valid authorization decision whose outcome was denial. IntentBridgeError is the module's malformed/untrusted/cannot-evaluate boundary. Conflating the two changes the fact reported to a caller and can route malformed producer output as a policy denial instead of a format defect.

This is also a schema/runtime consistency issue: a document rejected by the bridge schema can currently reach a semantic denial result in the direct runtime verifier.

Reproduction direction

Start from the existing valid fixture in tests/test_intent_bridge.py, replace only authorization.decision with each malformed value, re-sign the exact modified authorization using sign_bridge(), then call verify_bridge() at a valid fixed verification time.

Expected invariant:

• "allow" -> existing success path;
• "deny" -> AuthorizationDenied;
• any other primitive/value -> malformed bridge refusal, not AuthorizationDenied.

The re-sign step matters so the decision check, rather than signature failure, is load-bearing.

Proposed bounded direction

Establish the decision enum explicitly before applying allow/deny semantics. Preserve the existing AuthorizationDenied behavior for the literal valid "deny" value.

No wire-format, schema, signature, scope, digest, transcript, or authorization-policy change is required.

I searched the current TRACE issue tracker for an existing issue covering this exact decision-enum/runtime-classification boundary and did not find one.

AI-assistance disclosure: ChatGPT assisted with repository triage, duplicate search, reproduction design, and issue drafting. altrudev reviewed the bounded claim and remains responsible for the contribution.

[github-actions]

🔴 Contributor Check: HIGH

Check	Result
Profile	HIGH
Credential	LOW
Overall	HIGH

Automated check by AgenTrust Contributor Check.

[lywinged]

Right, and the repository already says so in two places; verify_bridge is where neither is followed.

I reproduced it on main the way you describe: each of true, 1, null, the empty string and "reject" re-signed with sign_bridge and verified at a fixed time inside the window. All five come back as AuthorizationDenied from line 155, whose test is != "allow".

The two places. docs/integration/pic-trace-bridge-v1.md states the contract this module is held to: "Malformed or unverifiable artifacts raise IntentBridgeError. A signed deny raises AuthorizationDenied." A signed true is not a signed deny. And the action-receipt conformance vector 16-decision-not-in-enum records the same rule for the sibling profile, "An unrecognised verb must not be read as either acceptance or rejection", with decision_invalid as the failure and the controller outcome unknown. So this is not a new principle for the repository. It brings the one verifier that reads an unrecognised verb as rejection into line with what the documentation and the receipt profile already hold.

On the shape. Every other authorization field in this module goes through a typed check that raises IntentBridgeError, through _object, _digest, _nonempty_string or _unique_nonempty_strings; decision is the one field that does not, so the check belongs beside them, before the allow or deny branch. Three things go with it: the AuthorizationDenied class docstring, "The signed decision is not an authorization to execute", is wide enough to be read as covering a malformed value and should name the literal deny; the regression tests should re-sign, as you describe, so that the enum check and not the signature is what fails; and a CHANGELOG.md entry under Unreleased, Fixed, in the shape the entries there use. sign_bridge validates none of the fields it signs, so this stays a verifier-side change in the pattern of the others rather than a reason to start validating on the producer side.

Welcome as a PR in the form of #318.