NenjoNenjo Docs
Foundations

Scopes

Fine-grained, least-privilege permissions that grant agents the platform MCP tools for a resource family.

Scopes are how an agent gets access to platform resources. The platform exposes its operations as MCP tools, and a scope grants the specific tools for one resource family. Assigning agents:read to an agent, for example, gives it the list_agents and get_agent tools — and nothing else.

This follows a least-privilege model: an agent, ability, domain, API key, or organization member receives only the platform tools it actually needs.

How scopes map to tools

Each scope adds a fixed group of platform MCP tools. Write scopes imply read access for the same family, so agents:write includes the read tools plus the mutating ones.

ScopeGrants these tools
agents:read / agents:writelist_agents, get_agent / configure_agent
abilities:read / abilities:writelist_abilities, get_ability / configure_ability
domains:read / domains:writelist_domains, get_domain / configure_domain
projects:read / projects:writelist_projects, get_project, project task & execution reads / project, task & execution writes
routines:read / routines:writeRead or mutate routines
councils:read / councils:writeRead or mutate councils
context_blocks:read / context_blocks:writeRead or mutate reusable prompt-context assets
models:read / models:writeRead or mutate model records
knowledge:read / knowledge:writeSearch, traverse, and read Library knowledge / create and update knowledge packs and documents
notify:read / notify:writeRead notification sessions / send org push notifications

knowledge:read exposes the composite knowledge tools (list_knowledge_packs, search_knowledge, list_knowledge_neighbors, and read_knowledge_doc) when a pack is available. knowledge:write adds Library authoring and, like every write scope, also implies read access. See Knowledge Graphs.

Where scopes are assigned

Scopes attach to several surfaces, each bounding what that surface can do:

  • Agents — the platform tools the agent may call directly.
  • Abilities and domains — carry their own scopes, so a specialist run or an activated mode can have a tighter or broader tool surface than the calling agent.
  • API keys and organization members — bound the same way.

Who assigns them

Platform scopes are assigned by admin or platform-controlled surfaces, not by agent-facing creation tools. This boundary matters: an agent (or an ability or domain it authors) cannot grant or change its own scopes. Agents may recommend the minimum scopes needed, but assignment is always a user or platform operation.

On this page