Skip to content

Agent permissions

A human-created agent starts private unless its selected workspace has a different default. You do not need to create roles or grants to edit your own agent. The owner_id response field records the creator. A human creator owns the agent. A service-created agent follows workspace permissions; the person who issued its key does not become its owner.

Choose a workspace at creation with workspace_id or snug agent create --workspace-id ID. Omitting it selects the account's internal root; named workspaces are optional. Reads do not create workspaces or identity records.

VisibilityWho can read, in addition to explicit grants and the human creator
privateNo inherited content access
workspaceReaders of the selected workspace
organizationCurrent human members of the authenticated tenant

Organization visibility requires org_id to equal the authenticated tenant. It gives read/use access, not edit rights. Workspace editors and managers can edit agents that inherit workspace or organization access. Private agents remain private from broad workspace grants. All paths require current tenant eligibility.

Use the same grant API as other resources:

snug access grant --target agents --id AGENT_ID \
  --subject-kind user --subject-id USER_ID --role reader

snug access grant --target agents --id AGENT_ID \
  --subject-kind group --subject-id GROUP_ID --role editor

snug access revoke --target agents --id AGENT_ID \
  --subject-kind user --subject-id USER_ID --role reader

Reader grants allow get/list/resolve. Editors can change content or delete the agent. Managers can also change visibility and manage grants. Revoking a grant removes that path; independent ownership, group, or workspace paths can still allow access. Group membership is evaluated live, and removing/recreating a tenant membership denies access while absent; rejoining as the same user restores surviving ownership and grants.

GET /agents, get-by-ID, key resolution, batch resolution and user-profile agent expansions all apply the same stored permissions. List totals count visible rows. Disabled agents remain visible through get/list but do not resolve by key.

A service account needs explicit workspace creation rights and an appropriate credential scope. Creation does not imply read permission for the output. Disabling the service or revoking its credential blocks subsequent requests; the workspace retains authority over the agent.

Auth provisions the permission principal when issuing a personal or organization session. A newly joined member can therefore read an organization-visible agent without first creating another resource. The Agent query methods themselves do not perform identity bootstrap writes. External identity authentication also provisions its validated tenant principal during the existing shadow-user setup.