Is your feature request related to a problem?
Currently, guardrails service authentication only uses a bearer token, which does not verify the tenant and can be spoofed. This poses a security risk since both tenant identification and authorization are not reliably enforced.
Describe the solution you'd like
- Change kaapi-guardrails to be internal-only, accepting requests solely from kaapi-backend.
- Each request should include a bearer token plus X-ORGANIZATION-ID/X-PROJECT-ID headers (set upstream).
- Limit requests to IPs within ALLOWED_IPS.
- Implement a check order: IP → token → tenant headers (respond with 403 → 401 → 422).
- Coordinate deployment to ensure kaapi-backend sends new headers and removes X-API-KEY/body-tenant before or with guardrails deploy.
- Note: No support for X-Forwarded-For, token-rotation overlap window, or per-route permissions/CIDR/mTLS at this time.
Additional context
https://docs.google.com/document/d/1UBp0MtzL6jaTraXicF8u7o4S3_PnB0OjW2oPMDkUZe8/edit?usp=sharing
Original issue
Which feature or component needs enhancement?
Guardrails authentication and authorization
Describe the current behavior
Bearer token proves who can call, not which tenant they can touch — tenant comes from caller-supplied query/body, so it can be spoofed. A second, separate X-API-KEY callback contract exists on other endpoints.
Describe the enhancement you'd like
Fix: kaapi-guardrails becomes internal-only, single caller (kaapi-backend). Every request carries bearer token + X-ORGANIZATION-ID/X-PROJECT-ID headers (set upstream, not by the caller) + must come from an IP in ALLOWED_IPS.
Why it's safe: tenant headers are only trustworthy because they arrive alongside a valid token from a whitelisted IP — a leaked token alone isn't enough, and a route can't be built without a tenant.
Check order: IP → token → tenant headers (403 → 401 → 422), IP first so bad-network callers never learn if their token works.
Breaking change: requires coordinated deploy — kaapi-backend must send new headers and drop X-API-KEY/body-tenant before or with the guardrails deploy.
Known limits: no X-Forwarded-For support (breaks behind a load balancer), no token-rotation overlap window, no per-route permissions/CIDR/mTLS (out of scope for now).
Why is this enhancement needed?
Single entry point for guardrails
Additional context
https://docs.google.com/document/d/1UBp0MtzL6jaTraXicF8u7o4S3_PnB0OjW2oPMDkUZe8/edit?usp=sharing
Is your feature request related to a problem?
Currently, guardrails service authentication only uses a bearer token, which does not verify the tenant and can be spoofed. This poses a security risk since both tenant identification and authorization are not reliably enforced.
Describe the solution you'd like
Additional context
https://docs.google.com/document/d/1UBp0MtzL6jaTraXicF8u7o4S3_PnB0OjW2oPMDkUZe8/edit?usp=sharing
Original issue
Which feature or component needs enhancement?
Guardrails authentication and authorization
Describe the current behavior
Bearer token proves who can call, not which tenant they can touch — tenant comes from caller-supplied query/body, so it can be spoofed. A second, separate X-API-KEY callback contract exists on other endpoints.
Describe the enhancement you'd like
Fix: kaapi-guardrails becomes internal-only, single caller (kaapi-backend). Every request carries bearer token + X-ORGANIZATION-ID/X-PROJECT-ID headers (set upstream, not by the caller) + must come from an IP in ALLOWED_IPS.
Why it's safe: tenant headers are only trustworthy because they arrive alongside a valid token from a whitelisted IP — a leaked token alone isn't enough, and a route can't be built without a tenant.
Check order: IP → token → tenant headers (403 → 401 → 422), IP first so bad-network callers never learn if their token works.
Breaking change: requires coordinated deploy — kaapi-backend must send new headers and drop X-API-KEY/body-tenant before or with the guardrails deploy.
Known limits: no X-Forwarded-For support (breaks behind a load balancer), no token-rotation overlap window, no per-route permissions/CIDR/mTLS (out of scope for now).
Why is this enhancement needed?
Single entry point for guardrails
Additional context
https://docs.google.com/document/d/1UBp0MtzL6jaTraXicF8u7o4S3_PnB0OjW2oPMDkUZe8/edit?usp=sharing