[Bug] Reference Guardian does not bind session context to agent identity #166

What is broken

The reference Guardian keys SessionContext state solely by metadata.session_id and does not bind that session state to the identity presented for the session. Requests using the same session_id but different agent_id and user_context values are accepted and appended to the same session context.

Where

reference-implementations/agt/packages/guardian/src/session-context-store.ts
reference-implementations/agt/packages/guardian/src/server.ts
reference-implementations/agt/packages/guardian/src/validate-envelope.ts

What the specification says, and what happens instead

The ACS Instrument specification says that sessionStart fires once per session and establishes the audit chain root, session-level identity and policy bindings, and the initial Intent before other steps/* hook traffic enters the session.

The identity concept defines a principal as the authenticated party initiating or acting within a session.

The reference Guardian does not establish or enforce an identity binding for the session. SessionContext is keyed by session_id, while agent_id and user_context are only schema-validated request metadata; no Guardian-side identity/session binding check was found.

Observed on integration at dc26547:

1. A request using session_id 176ed848-8582-43b7-9d40-2a1c93592697 and agent_id=victim-agent was accepted and persisted.

2. A second request using the same session_id but agent_id=attacker-agent was also accepted and persisted.

3. A third request using the same session_id and agent_id=attacker-agent supplied:
   user_id=victim-user
   roles=["admin"]
   authentication_method="test"

   This request received decision=allow and was persisted into the same SessionContext chain.

The observed requests used:

• seq=1: request_id=bbbbbbbb-bbbb-4bbb-8bbb-bbbbbbbbbbbb, agent_id=victim-agent
• seq=2: request_id=cccccccc-cccc-4ccc-8ccc-cccccccccccc, agent_id=attacker-agent
• seq=3: request_id=eeeeeeee-eeee-4eee-8eee-eeeeeeeeeeee, agent_id=attacker-agent, user_id=victim-user, roles=["admin"]

The resulting session-context log contains all three entries under the same session_id:

seq=1 victim request
seq=2 attacker request
seq=3 attacker request with victim-looking user context

All three entries have the same session_id and form one hash chain.

Impact on implementers

This allows activity from different agent identities to enter the same established session context. Because the Guardian stores and retrieves session state by session_id, a party presenting an existing session_id can append activity to that session without the Guardian detecting an identity mismatch.

This can undermine the integrity of session-level identity, audit context, and policy bindings. A downstream implementation relying on SessionContext as the authoritative session state could therefore observe activity from a different identity as part of the established session.

This report demonstrates cross-identity session-context injection. It does not claim authentication bypass or privilege escalation, because authentication and credential binding are deployment-defined and were not independently demonstrated here.

What needs to change

The Guardian should establish the authenticated identity associated with a session during the session-start/handshake lifecycle and enforce that binding for subsequent hook traffic.

A request using an existing session_id but presenting a different authenticated identity should not be allowed to append to the established session context.

The implementation should also ensure that session-level audit state and policy bindings cannot silently become shared across distinct authenticated principals merely because they supply the same session_id.

Suggested tests:

• Establish a session with identity A.
• Send a valid hook with identity A and verify it is accepted.
• Send a valid hook with the same session_id but identity B and verify it is rejected or isolated from A's session.
• Verify B's event is not appended to A's SessionContext chain.
• Verify user_context/roles changes cannot silently alter the established session identity.
• Verify separate session IDs remain independent.

Appears implementable in the AGT reference Guardian. The observed behavior is in the Guardian's session/context management layer and does not require an underlying AGT policy-engine capability. The missing behavior is establishing and enforcing an identity binding for SessionContext.

Current Priority Scope

Feeds the runnable Guardian reference implementation