Skip to main content
Every check against an agent asks one of two questions:
  1. Can this user reach the agent? — chat with it, view it in a catalog, list its details.
  2. Can this user change or destroy it? — update its config, delete it, view or rotate its secrets.
Only the agent’s owner or a superuser can do the second. Publishing an agent or granting a department access to it hands out no management rights.
A soft-deleted agent is denied to everyone except through direct database recovery. No ownership, grant, or public flag overrides a deletion.

​
What grants view and chat access

A user can reach an agent if any of these is true: Grants are additive — an agent can stay privately owned and still be reachable by a whole department. is_public extends to anyone the platform’s routing surfaces reach; an organization-wide grant is scoped to your authenticated users.
Enterprise feature. “Team ownership” and team/department-scoped grants require nasiko-ee’s org hierarchy. The open-source edition’s access model has only three conditions: ownership, is_public, and a per-user grant — there’s no team or department concept to grant against.

​
Managing grants

Enterprise feature. Every command in this section (and “Managing an agent” below) is nasiko-ee. There’s no equivalent in the plain nasiko CLI.
--user, --team, and --dept accept multiple values and combine in one call. An agent can also be granted to another agent. This controls whether a human acting through that agent’s context can reach this one — not whether the two agents may call each other programmatically. That’s the agent-to-agent allowlist. Inspect current access:

​
Example: share with one team, private otherwise

The agent stays private, but every platform-eng member can chat with it.

​
Managing an agent

These require ownership or superuser — view/chat access is not enough:
Managing secrets follows the same rule, plus the team_lead threshold from the overview. See secret management.