Server edition: auth.MaxTokens is a global 100-token cap, so one tenant can exhaust agent-token slots for the whole deployment #1177

Summary

auth.MaxTokens (internal/auth/agent_token.go:32) is 100 and is enforced as a deployment-wide count in internal/storage/agent_tokens.go:56, with no per-owner quota. In the server edition every user can mint their own tokens at POST /api/v1/user/tokens, so a single tenant can consume all 100 slots and lock out every other tenant, including the admin.

Impact

Denial of service across a tenant boundary, available to any authenticated user, with no privileged access required. It is not a disclosure — the work on #1168 made the error a typed sentinel that surfaces as a generic status rather than a name-leaking 409 — but the exhaustion itself is untouched.

Suggested fix

A per-owner quota checked alongside the global cap. The global cap can stay as a backstop; it just cannot be the only limit on a multi-tenant surface. Worth deciding at the same time whether the global 100 is still the right number once per-user quotas exist.

Found during the #1168 work; deliberately not bundled, since a quota is a product decision rather than a security fix.