• What failed: The disallowed-origin request should be rejected by auth, but it proceeds past origin validation and reaches downstream handling (for example, a project lookup failure) when the auth attempt returns no context in development/test mode.
• Impact: Security-focused origin checks can be bypassed during development/test verification, so hostile-origin requests are not reliably blocked where they should be. This weakens confidence in pre-production auth boundary testing and can mask origin-policy regressions.
• Introduced by this PR: No – pre-existing bug (code not changed in this PR)
• Steps to reproduce:
  1. Configure a web_client app with an allowed domain list.
  2. Send one request from an allowed origin and one from a disallowed origin using a valid bearer token and x-inkeep-app-id.
  3. Compare responses and observe that the disallowed-origin request is not rejected at auth and proceeds to downstream handling.
• Stub / mock context: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code analysis: I reviewed the app-credential auth flow and origin validator. tryAppCredentialAuth correctly flags disallowed origins, but in development/test middleware handling, any auth attempt without authResult falls back to createDevContext, allowing request processing to continue instead of returning an auth error.
• Why this is likely a bug: The code explicitly marks disallowed origins as auth failure, but the dev/test branch converts that failure into an executable default context, which contradicts origin enforcement behavior expected by the feature.

Relevant code:

agents-api/src/middleware/runAuth.ts (lines 605-614)

if (app.type === 'web_client') {
  const config = app.config as WebClientConfig;

  if (!validateOrigin(origin, config.webClient.allowedDomains)) {
    logger.warn(
      { origin, allowedDomains: config.webClient.allowedDomains, appId: app.id },
      'App credential auth: origin not allowed'
    );
    return { authResult: null, failureMessage: 'Origin not allowed for this app' };
  }

agents-api/src/middleware/runAuth.ts (lines 953-975)

// Development/test environment handling
if (isDev) {
  logger.info({}, 'development environment');

  const attempt = await authenticateRequest(reqData);

  if (attempt.authResult) {
    c.set('executionContext', buildExecutionContext(attempt.authResult, reqData));
  } else {
    logger.info(
      {},
      reqData.apiKey
        ? 'Development/test environment - fallback to default context due to invalid API key'
        : 'Development/test environment - no API key provided, using default context'
    );
    c.set('executionContext', buildExecutionContext(createDevContext(reqData), reqData));
  }
}

• What failed: The request returns 401 Invalid or expired token instead of degrading to the anonymous flow when allowAnonymous permits fallback.
• Impact: Clients presenting a stale or malformed asymmetric token cannot recover through the intended anonymous path. This causes avoidable auth failures and degraded chat availability.
• Introduced by this PR: No – pre-existing bug (code not changed in this PR)
• Steps to reproduce:
  1. Configure a web_client app with asymmetric auth keys and allowAnonymous enabled.
  2. Call POST /run/api/chat with x-inkeep-app-id: app_playground and an invalid or expired asymmetric bearer token.
  3. Observe the response status and error payload.
  4. Expected behavior is anonymous fallback, but actual behavior is 401 Invalid or expired token.
• Stub / mock context: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code analysis: I inspected the asymmetric verification branch in tryAppCredentialAuth. When asymmetric verification fails and anonymous is allowed, the code logs that it will fall through, but the subsequent anonymous JWT verification block throws 401 whenever auth keys are configured, effectively overriding the intended fallback.
• Why this is likely a bug: The fallback path is contradicted by a later unconditional unauthorized throw under hasAuthConfigured, so the implementation cannot satisfy its own allow-anonymous behavior.

Relevant code:

agents-api/src/middleware/runAuth.ts (lines 631-644)

if (!asymResult.ok) {
  const allowAnonymous = config.webClient.auth?.allowAnonymous !== false;
  if (!allowAnonymous) {
    logger.debug(
      { appId: app.id, reason: asymResult.failureMessage },
      'Asymmetric JWT verification failed, anonymous not allowed'
    );
    throw createApiError({ code: 'unauthorized', message: asymResult.failureMessage });
  }
  logger.debug(
    { appId: app.id, reason: asymResult.failureMessage },
    'Asymmetric JWT verification failed, falling back to anonymous'
  );

agents-api/src/middleware/runAuth.ts (lines 795-805)

} catch (err) {
  const errorType =
    err instanceof errors.JWTExpired
      ? 'expired'
      : err instanceof errors.JWSSignatureVerificationFailed
        ? 'signature_invalid'
        : 'unknown';
  logger.debug({ errorType, appId: appIdHeader }, 'Anonymous JWT verification failed');
  if (hasAuthConfigured) {
    throw createApiError({ code: 'unauthorized', message: 'Invalid or expired token' });
  }

• What failed: Anonymous chat for a global web_client app fails because auth context resolves to empty tenant/project values, instead of allowing non-user-scoped chat.
• Impact: Anonymous chat is broken for global web_client apps using this path. Integrations that rely on anonymous access can fail immediately at request validation.
• Introduced by this PR: No – pre-existing bug (code not changed in this PR)
• Steps to reproduce:
  1. Use a global web_client app such as app_playground.
  2. Call POST /run/auth/apps/app_playground/anonymous-session from an allowed origin and capture the returned token.
  3. Call POST /run/api/chat with Authorization: Bearer <anon_token> and x-inkeep-app-id: app_playground.
  4. Observe failure caused by missing tenant/project context instead of successful anonymous chat.
• Stub / mock context: No stubs, mocks, or bypasses were applied for this test in the recorded run.
• Code analysis: I reviewed the anonymous-session token issuance route and app-credential auth middleware. The token is signed with tid/pid taken directly from the app record (which is null for global apps), and the downstream anonymous auth path does not recover tenant/project scope from token claims for global apps, producing empty context.
• Why this is likely a bug: The code path for global apps can legitimately produce empty tenant/project execution context during anonymous auth, which directly explains the observed Missing tenantId runtime failure.

Relevant code:

agents-api/src/domains/run/routes/auth.ts (lines 230-235)

const token = await new SignJWT({
  tid: appRecord.tenantId,
  pid: appRecord.projectId,
  app: appId,
  type: 'anonymous',
})

agents-api/src/middleware/runAuth.ts (lines 782-787)

const { payload } = await jwtVerify(bearerToken, secret, { issuer: 'inkeep' });

if (payload.app !== appIdHeader) {
  if (hasAuthConfigured) {
    throw createApiError({ code: 'unauthorized', message: 'Invalid or expired token' });
  }

agents-api/src/middleware/runAuth.ts (lines 825-829)

return {
  authResult: {
    apiKey: bearerToken || appIdHeader,
    tenantId: app.tenantId || reqData.tenantId || '',
    projectId: app.projectId || reqData.projectId || '',