When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

• What failed: A mismatched appId/JWT combination was accepted (200) when the expected behavior is a 4xx rejection tied to app/token binding.
• Impact: This weakens app isolation in the auth boundary and can let a token validated under one app context be replayed under another app header when keys/claims still verify. It increases the risk of cross-app authorization confusion.
• Introduced by this PR: No – pre-existing bug (code not changed in this PR)
• Steps to reproduce:
  1. Obtain a valid playground JWT for app A.
  2. Send POST /run/api/chat with that JWT but set x-inkeep-app-id to app B.
  3. Observe the request is accepted instead of rejected.
• Stub / mock context: This run used local fixture app identities and temporarily bypassed proof-of-work checks in the run auth paths so adversarial requests could be exercised deterministically in local development. No route interception was used for this case.
• Code analysis: I inspected the app credential auth flow in runAuth.ts; the asymmetric verification path validates signature and standard claims but does not verify token app binding against x-inkeep-app-id, while the anonymous JWT fallback path does enforce app claim matching.
• Why this is likely a bug: The code enforces app claim binding only in one token path, leaving the asymmetric path without an equivalent appId consistency check despite handling the same app-scoped trust boundary.

Relevant code:

agents-api/src/middleware/runAuth.ts (lines 532-581)

const verifyOptions: Parameters<typeof jwtVerify>[2] = {
  clockTolerance: 60,
};
if (audience) {
  verifyOptions.audience = audience;
}

let payload: Record<string, unknown>;
try {
  const result = await jwtVerify(bearerToken, cryptoKey, verifyOptions);
  payload = result.payload as Record<string, unknown>;
} catch (err) {
  if (err instanceof errors.JWTExpired) {
    return { ok: false, failureMessage: 'Token expired' };
  }
  ...
}

if (!payload.sub) {
  return { ok: false, failureMessage: 'JWT missing required sub claim' };
}

...

return {
  ok: true,
  endUserId: payload.sub as string,
  kid: matchedKey.kid,
  claims: payload,
};

agents-api/src/middleware/runAuth.ts (lines 783-790)

if (payload.app !== appIdHeader) {
  if (hasAuthConfigured) {
    throw createApiError({ code: 'unauthorized', message: 'Invalid or expired token' });
  }
  return {
    authResult: null,
    failureMessage: 'JWT app claim does not match request app ID',
  };
}

• What failed: Invalid/tampered scope headers produced a 500 Context validation failed response instead of a controlled client-facing 4xx denial.
• Impact: Clients receive an internal server error for invalid request scope instead of a deterministic authorization/validation response. This degrades reliability and obscures correct caller remediation behavior.
• Introduced by this PR: No – pre-existing bug (code not changed in this PR)
• Steps to reproduce:
  1. Send a valid authenticated run request.
  2. Tamper x-inkeep-tenant-id, x-inkeep-project-id, and x-inkeep-agent-id to unauthorized values.
  3. Observe the server response code.
• Stub / mock context: The same local run configuration kept proof-of-work checks bypassed in development while sending deliberately unauthorized scope headers to verify denial behavior. The request path itself was exercised directly without response mocking.
• Code analysis: In contextValidationMiddleware, invalid headers are correctly converted to a bad request error first, but the broad catch block then converts that expected API error into internal_server_error, causing a 500 for client-caused validation failures.
• Why this is likely a bug: The middleware constructs a client-correct bad_request for invalid headers and then unconditionally masks it to internal_server_error, which is incorrect error classification for a known validation failure.

Relevant code:

agents-api/src/domains/run/context/validation.ts (lines 417-421)

const errorMessage = `Invalid headers: ${validationResult.errors.map((e) => `${e.field}: ${e.message}`).join(', ')}`;
throw createApiError({
  code: 'bad_request',
  message: errorMessage,
});

agents-api/src/domains/run/context/validation.ts (lines 436-446)

} catch (error) {
  logger.error(
    {
      error: error instanceof Error ? error.message : 'Unknown error',
    },
    'Context validation middleware error'
  );
  throw createApiError({
    code: 'internal_server_error',
    message: 'Context validation failed',
  });
}

agents-api/src/domains/run/routes/chatDataStream.ts (lines 99-100)

// Apply context validation middleware
app.use('/chat', contextValidationMiddleware);