Severity: Critical — this fix is directionally correct but incomplete, and will break global app anonymous sessions.

The vulnerability is real: commit 704026c introduced a header injection vector where unauthenticated callers can mint anonymous JWTs with arbitrary tid/pid by supplying x-inkeep-tenant-id / x-inkeep-project-id headers. This PR correctly removes that fallback.

However, the removal also disables the legitimate functionality 704026c was trying to enable — global apps (where appRecord.tenantId is null) need tid/pid populated from somewhere. After this PR, global app anonymous JWTs will have tid: null, pid: null, and when used downstream in runAuth.ts:832-833 the execution context will resolve to tenantId: '', projectId: '' — effectively breaking scope resolution for global app anonymous sessions.

The proper fix requires a different approach for populating tid/pid on global app anonymous sessions that doesn't trust raw request headers. For example:

• Require the caller to obtain an anonymous session through the authenticated path (asymmetric JWT with tid/pid claims) rather than the anonymous path for global apps.
• Reject anonymous session creation entirely for global apps (!appRecord.tenantId) and require all global app users to authenticate with a signed JWT containing scope claims.

As-is, this PR trades a security vulnerability for a functional regression on global apps. Both need to be addressed together.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using Claude Opus ｜ 𝕏}

PR Review Summary

(1) Total Issues | Risk: Low

🔴❗ Critical (0) ❗🔴

None.

🟠⚠️ Major (1) 🟠⚠️

🟠 1) auth.test.ts Missing regression test for header injection vulnerability

Issue: No test validates that x-inkeep-tenant-id / x-inkeep-project-id headers cannot inject arbitrary claims into anonymous session JWTs. The fix removes the header fallback for global apps (where appRecord.tenantId/projectId is null), but no test guards this security boundary.

Why: Without a regression test, a future developer could reintroduce the header fallback pattern (e.g., for "convenience" or when refactoring), re-enabling the authorization bypass. This is a security vulnerability that could enable tenant impersonation and cross-tenant data access.

Fix: Add a test that:

1. Creates a global web_client app with null tenantId/projectId (may require direct DB insertion or modifying createTestWebClientApp helper)
2. Makes an anonymous-session request with malicious x-inkeep-tenant-id: 'attacker-tenant' and x-inkeep-project-id: 'attacker-project' headers
3. Verifies the issued JWT's tid/pid claims are null (matching the app) and NOT the attacker-supplied values

it('should not allow request headers to inject tenant/project claims for global apps', async () => {
  // Setup: Create global app with null tenantId/projectId
  const globalApp = await createTestWebClientApp({ 
    tenantId: null, 
    projectId: null,
    allowedDomains: ['https://example.com'] 
  });

  const response = await app.request(
    `/auth/apps/${globalApp.id}/anonymous-session`,
    {
      method: 'POST',
      headers: {
        Origin: 'https://example.com',
        'x-inkeep-tenant-id': 'attacker-tenant',
        'x-inkeep-project-id': 'attacker-project',
      },
    }
  );

  expect(response.status).toBe(200);
  const { token } = await response.json();
  const decoded = decodeJwt(token);
  
  // Critical assertion: headers must NOT influence JWT claims
  expect(decoded.tid).toBeNull(); // NOT 'attacker-tenant'
  expect(decoded.pid).toBeNull(); // NOT 'attacker-project'
});

Refs:

• agents-api/src/tests/run/routes/auth.test.ts
• OWASP Testing Guide - Authorization Bypass

🟡 Minor (0) 🟡

None.

💭 Consider (1) 💭

💭 1) auth.test.ts Additional defense-in-depth test for bound apps

Issue: The existing tests verify that tid/pid claims match app record values, but none explicitly test that supplying conflicting headers does not override them.

Why: Adds defense-in-depth to prove headers are completely ignored even when apps have bound tenant/project values.

Fix: Add a test that creates a normal web_client app bound to tenant-A/project-A, makes a request with conflicting headers, and verifies the JWT uses the app's bound values, not the headers.

Summary: This is a well-targeted security fix that correctly closes an authorization bypass vulnerability. The code change is minimal, precise, and addresses the root cause. The fix removes the ability for unauthenticated callers to inject arbitrary tenant/project claims into anonymous session JWTs via HTTP headers.

Security assessment: ✅ The fix is sound. JWT tid/pid claims now only come from trusted sources: the app record binding or a previously-validated refresh token's claims. The vulnerability analysis confirms this is part of a coordinated fix series (PRs #2922, #2924, and this one).

The one gap is test coverage: Adding a regression test for the header injection attack vector would prevent reintroduction of this vulnerability. This is the main recommendation before merging.