Granular permissions for agent creation beyond feature enablement

[paullizer]

GitHub Issue: Granular permissions for agent creation beyond feature enablement

Summary

Right now, agent capabilities appear to be governed primarily by feature toggles (for example: enable personal agents, enable group agents). We should add finer-grained permissions so admins can control who can create/manage agents once a capability is enabled.

Problem

Enabling an agent capability is too coarse:

• If Group Agents is enabled, there is no way to restrict which groups can create group agents.
• If Personal Agents is enabled, there is no way to restrict which users/roles can create personal agents.

This creates governance gaps (especially for larger orgs) where admins want the capability available, but only for specific groups, roles, or pilot users.

Proposed Solution

Introduce a permissions layer on top of agent feature flags.

Add configuration controls (admin-configurable):

• Group Agent creation policy

  • Allow list: which groups can create group agents
  • Optionally role-based: only group owners/admins can create on behalf of a group

• Personal Agent creation policy

  • Allow list: which users (or roles) can create personal agents

Behavior

• Feature toggle still acts as the master switch.
• If enabled, creation is permitted only if the caller passes the policy check.
• UI should hide or disable creation actions when user lacks permission, and API should enforce it regardless.

Acceptance Criteria

• When Group Agents is enabled:

  • Users can create group agents only for groups permitted by policy.
  • Unauthorized attempts are blocked server-side with a clear error.
  • UI clearly indicates lack of permission (disabled CTA or informative message).

• When Personal Agents is enabled:

  • Only permitted users/roles can create personal agents.
  • Unauthorized attempts are blocked server-side with a clear error.
  • UI reflects permissions.

• Permissions are auditable (logged decision: allowed/denied, user, group, timestamp, policy rule matched).

• Defaults are sensible for existing tenants (backward compatible).