Summary

PUT /api/v1/sessions/:sessionId/snapshot-url is allowJWT: true and authorizes on
write:sessions:<key> — the scope carried by the public access token every chat browser is handed.
It returns a 5-minute S3 presigned PUT for the session's durable chat snapshot.

Its sibling session-stream route deliberately refuses non-secret-key auth for the equivalent write
direction. This route has no such check, so an end user can overwrite the conversation state the
agent reads back as its own history.

Details

apps/webapp/app/routes/api.v1.sessions.$sessionId.snapshot-url.ts:

const routeConfig = {
  params: ParamsSchema,
  allowJWT: true,                                   // browser tokens reach this route
  corsStrategy: "all" as const,
  findResource: async (params, auth) =>
    resolveSessionByIdOrExternalId($replica, auth.environment.id, params.sessionId),
};

const route = createActionApiRoute(
  { ...routeConfig, method: "PUT",
    authorization: {
      action: "write",
      resource: (params, _, __, ___, session) => sessionResource(params.sessionId, session),
    } },
  async ({ authentication, resource: session }) => {
    if (!session) return json({ error: "Session not found" }, { status: 404 });
    const signed = await generatePresignedUrl(
      authentication.environment.project.externalRef,
      authentication.environment.slug,
      chatSnapshotStorageKey(session),
      "PUT"                                          // presigned WRITE
    );

mintSessionToken.server.ts:26-29 gives the browser token exactly
read:sessions:<key> + write:sessions:<key>, and buildJwtAbility
(packages/plugins/src/rbac.ts:223-240) matches write:sessions:<key> against
{ type: "sessions", id: <key> }. So the token authorizes the route.

The guarded sibling. apps/webapp/app/routes/realtime.v1.sessions.$session.$io.ts:41:

// `.out` is the agent→client channel. Only PRIVATE (secret key) auth —
// i.e. the agent run itself — may initialize it. Session-scoped JWTs carry
// `write:sessions:<key>` for `.in`; without this gate they could obtain
// credentials to forge assistant chunks on their own session's `.out`.
if (params.io === "out" && authentication.type !== "PRIVATE") { return 403; }

That comment is the invariant: a session JWT must not be able to write the agent's side of the
conversation. The snapshot is the durable form of exactly that data, and this route has no
authentication.type !== "PRIVATE" check at all.

The snapshot is read back to seed the agent's message history when no hydrateMessages hook is
configured — the default.

PoC

Verified in your own apps/webapp/test/ suite, driving the real buildJwtAbility() against the
exact scopes mintSessionToken.server.ts:26-29 puts in the browser's token, evaluating the exact
resource shape snapshot-url.ts:31-41 builds:

token scopes (mintSessionToken.server.ts:26-29):
  read:sessions:chat_ATTACKER_OWN
  write:sessions:chat_ATTACKER_OWN

resource built by snapshot-url.ts:31-41:
  [{"type":"sessions","id":"chat_ATTACKER_OWN"}]

PUT /api/v1/sessions/:id/snapshot-url declares:
  allowJWT: true                       (snapshot-url.ts:19)
  authorization: { action: "write" }   (snapshot-url.ts:47-50)
  authentication.type !== "PRIVATE" gate:  ABSENT

  ability.can("write", resource) -> true

CONTROL 1 — same token, the .out channel:
  ability.can("write", {type:"sessions", id}) -> true
  route gate  authentication.type !== "PRIVATE" -> rejects: true
  => the ability GRANTS it; only the route-level PRIVATE check stops it.
     snapshot-url.ts has no equivalent check.

CONTROL 2 — another user's session token against this session:
  ability.can("write", resource) -> false   <- correctly refused

vitest: 3 passed (3)

CONTROL 1 is the finding: the ability layer does not distinguish the two channels, so the .out
route needs its explicit PRIVATE gate — and this route, which presigns a write to the durable form
of the same data, does not have one. CONTROL 2 is why I report this as operator-vs-end-user and
not as cross-tenant.

Over HTTP the remaining step is the presign itself, which I did not execute (it needs a configured
object store); that is AWS SDK behaviour once authorization has already passed:

PUT /api/v1/sessions/<own session>/snapshot-url     (session public token only)
-> 200 { url: "https://<bucket>/...?X-Amz-Signature=..." }   5-minute presigned PUT

Impact

This is confined to the attacker's own session.