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.
| Visibility | Who can read, in addition to explicit grants and the human creator |
|---|---|
private | No inherited content access |
workspace | Readers of the selected workspace |
organization | Current 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 readerReader 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.
