Does kagent have RBAC for OIDC users? How to restrict agent access?

Question

Does kagent (kagent-dev/kagent) support RBAC or authorization for OIDC-authenticated users? We run it as a shared multi-team platform and today every authenticated user can list, invoke, edit, and delete every Agent, ModelConfig, and ToolServer across all namespaces. We also hit nginx 400 errors on OIDC login when large group claims made the cookie too big. What is the current status and are there workarounds until RBAC ships?

Originally asked on GitHub: https://github.com/kagent-dev/kagent/issues/1270

AgentArmor team · Accepted Answer

RBAC authorization for kagent is still an open issue as of the last thread activity (July 2026) — no authorizer has shipped. The controller ships with `NoopAuthorizer`, so every authenticated user can list, invoke, edit, and delete every Agent, ModelConfig, and ToolServer across all namespaces; enabling OIDC via oauth2-proxy gives authentication only, not access control.

The plumbing is ready: the `Authorizer` interface is wired into all handlers and `ProxyAuthenticator` passes the full JWT claims to it, so what's missing is a real authorizer implementation. The issue body proposes Casbin-based RBAC with `admin`/`readonly` roles, but the direction isn't committed. One contributor proposed CEL as the default policy engine (cel-go is already in the dependency tree), with the `Authorizer` interface kept as a pluggable seam for OPA or external services; another adopter noted that namespace-level visibility filtering is still out of scope (a `readonly` user would still list every resource) and recommended default-deny instead of the proposed default-to-admin. No maintainer decision has been announced, and commenters are asking for one.

Until RBAC ships, one workaround from the thread: a separate Operator that injects UI filters mapping OIDC groups to namespaces (declarative mappings, with Platform Engineering teams mapped to admin). The same user added Redis in front of OIDC login to improve nginx 400 errors from oversized cookies with large group claims, and reported remaining issues: logout/re-login is buggy and there is no landing page for unauthenticated users.

Security note: until an authorizer lands, treat kagent as trusted-users-only — any authenticated user has full admin capability.

AgentArmor team · Answer

**What @marcellodesales tried on GitHub** (Partly worked)

Built a separate Operator that adds UI filters mapping OIDC groups to namespaces, with declarative mappings (Platform Engineering teams mapped to admin). Added Redis in front of OIDC login to improve nginx 400 errors caused by oversized cookies. Reported remaining problems: buggy logout with re-login and no unauthenticated landing page.

Source: https://github.com/kagent-dev/kagent/issues/1270#issuecomment-5052525900

AgentArmor team · Answer

**What a GitHub user tried on GitHub** (Outcome unclear)

The issue body proposed Casbin-based RBAC with admin/readonly roles, default admin policy, secret masking for readonly users, and API-level enforcement. It's a design proposal; no implementation landed, and a later contributor proposed a different CEL-based direction.

Source: https://github.com/kagent-dev/kagent/issues/1270

Does kagent have RBAC for OIDC users? How to restrict agent access?

3 answers

Add your answer or comment

Does kagent have RBAC for OIDC users? How to restrict agent access?

3 answers

Add your answer or comment

Related questions