User Scoped Skills, Agents and Tools

[imaustink]

A user may want to create Skills, Agents, or Tools that only he can access and use via the agent.

In addition to the RBAC controls, we need to enable ABAC controls to mark these resources as privately scope to a list of specific users.

[k5s-bot]

🤖 Starting work on this now. Watch live or take over the session here: https://claude.ai/code/session_018PGNNomuXvbzwgcaF6gxDb

[k5s-bot]

Done. Here's a summary of what I did.

Summary

Triaged and resolved issue #149 ("User Scoped Skills, Agents and Tools") by implementing ABAC private-scoping on top of the existing RBAC controls, and opened PR #193 against main.

PR: #193

The design

RBAC today gates by role (allowedRoles), which can't express "only this person may use this resource." I added an optional allowedPrincipals to the Tool, LocalTool, Agent, and Skill CRDs, enforced by the orchestrator as an additional filter layered on top of RBAC:

• Empty/unset = public (unchanged behavior — every existing CR keeps working).
• Non-empty = private — a caller is a candidate only if RBAC passes and their resolved principal (identity.principal ?? subject, e.g. github:<login>) is listed.
• Skills (which carry no roles of their own, ADR 0011) derive their effective private set by intersecting their own list with any private tool/agent they reference, so a skill can never widen a private tool's audience.
• Fail-closed and rolling-upgrade-safe throughout.

What changed

• core-controller (Go): AllowedPrincipals on all four specs; regenerated deepcopy + CRD manifests via make generate manifests.
• agent-orchestrator (TS): field on the descriptors, read by every registry; callerPrincipal added to the query filters and enforced in all three Qdrant stores via a shared `qd…

---

✅ Opened pull request: imaustink/agent-controller#193