fix(api): refuse workspace keys and enforce personal_api_key.use on v1 audit logs

[waleedlatif1]

Summary

• v1 GET /api/v1/audit-logs and GET /api/v1/audit-logs/[id] authorized with rateLimit.userId, which for a workspace key is the key's creator — a workspace-scoped key created by an org admin/owner could read the whole organization's audit trail, including other workspaces
• Both handlers now go through validateV1EnterpriseAuditAccess, which refuses workspace keys (403) before any org lookup, matching workspaceApiKey: 'deny' on auditLogOperations and the v2 route
• Personal keys are now held to the user-global personal_api_key.use permission-group decision (the same one the v2 audit-log use case applies), via a new checkOrganizationPersonalKeyRefusal in the v1 middleware so the subject still resolves through capabilityGovernedUserId
• The group refusal runs after the admin-role check so a non-admin never learns how the org configured personal keys

Type of Change

• Bug fix

Testing

• Added route tests for workspace-key refusal on list + detail, wrapper tests (workspace key refused without DB access, admin allowed, group withhold refused, non-admin gets role error not group error), and middleware tests for the new refusal
• Confirmed the new tests fail with the guards removed
• type-check, lint, check:audits, docs-manifest:check pass

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated
docs	Skipped		Sep 19, 2026 7:39pm UTC

[greptile-apps]

Confidence Score: 5/5

The PR appears safe to merge; the changed authorization flow consistently rejects workspace keys and enforces personal-key policy without altering valid personal-key identity or audit scope.

Summary

This PR closes a privilege-boundary gap in both v1 audit-log endpoints by authorizing against the credential kind rather than treating a workspace key's creator as the acting user.

• Rejects workspace API keys before organization audit access is resolved.
• Enforces the user-global personal_api_key.use decision for personal keys.
• Preserves role-check ordering so non-admin users do not learn permission-group configuration.
• Adds wrapper, route, and middleware coverage for the new authorization behavior.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[v1 audit-log request] --> B[Authenticate and rate-limit API key]
  B --> C{Request allowed?}
  C -- No --> D[Return authentication or rate-limit response]
  C -- Yes --> E{Personal API key with user ID?}
  E -- No --> F[Return 403: personal API key required]
  E -- Yes --> G[Resolve enterprise audit access]
  G --> H{Organization admin or owner?}
  H -- No --> I[Return enterprise access refusal]
  H -- Yes --> J{personal_api_key.use withheld?}
  J -- Yes --> K[Return 403 capability refusal]
  J -- No --> L[Query organization-scoped audit logs]

Loading

_{Reviews (1) · Last reviewed commit: "fix(api): refuse workspace keys and enfo..."}

[cubic-dev-ai]

No issues found across 8 files

Confidence score: 5/5

• Automated review surfaced no issues in the provided summaries.
• No files require special attention.

_{Re-trigger cubic}