Skip to main content
The access control guide covers the configuration model. This page covers where each check runs, the exact thresholds, and visibility scoping.

​
Two layers, checked in different places

​
User → agent

Every route touching a specific agent — proxying a chat request, updating, deleting, reading or rotating secrets — resolves access the same way: ownership, the public flag, or an explicit grant. A soft-deleted agent is denied unconditionally.
Enterprise feature. Team/department ownership and grants require nasiko-ee’s org hierarchy — the open-source edition’s can_access_agent check has only owner, is_public, and a per-user agent_grants row.
Mutating operations (update, delete, secrets, ACL changes) use a stricter check: neither a public flag nor an invoke-only grant confers the right to modify or destroy an agent. Only ownership or superuser does. The distinction matters because view access is granted far more often than manage access — conflating them would let a public flag double as a management grant.

​
Agent → agent

Whenever an authorized agent calls another agent, a separate check applies: is this hop allowed? Governed by an allowlist of explicit caller/target pairs.
Agent-to-agent access is default-deny, unconditionally. An agent with no allowlist entries cannot call any other agent. There’s no “unrestricted until the first rule” state. If you deploy an agent that calls another as part of its logic, add that pairing first or the call fails.
The check runs immediately before the target is invoked, in the same pass as the flow guard’s cascade limits. A rejection from either aborts the call before it reaches the target container. The allowlist rows live in the agent_acl table. In the open-source edition there’s no bundled endpoint for managing them yet — the corresponding grants router is defined but not mounted on the OSS server. nasiko-ee mounts its own richer version at /api/agents/{id}/grants/agents[/{target_agent_id}].
Enterprise feature. Managing this allowlist over the API is nasiko-ee only today.
Which agents a MAF workflow reaches is governed at authoring time — who can create a workflow and which agents they name — not by this allowlist.

​
Role hierarchy

Enterprise feature. This ranked role hierarchy is enforced by nasiko-ee’s auth layer. The open-source edition’s auth has no roles — can_deploy, can_manage_secrets, and can_manage_users all default to allow-all for every authenticated user.
Roles rank strictly: admin > department_manager > team_lead > team_member > member. An unrecognized role value ranks below all five rather than defaulting to trusted. Three capabilities are gated by a minimum role — anyone at or above qualifies: Role and superuser are independent. A superuser bypasses org-visibility scoping and unlocks platform-wide administrative routes regardless of role; promoting someone to admin does not grant superuser.
A role is a capability tier, not a grant on any agent. Meeting a threshold means you may attempt that class of action — whether you can act on a particular agent is still decided by the ownership and grant model above.

​
Org-scoped visibility

Enterprise feature. Visibility scoping by team/department hierarchy is nasiko-ee only — the open-source edition’s equivalent setting is unrestricted (every authenticated user can see every other user).
The platform also scopes which users a caller can see. A non-superuser’s visible set is bounded by their position in the hierarchy: a management role sees people within their own scope (their team, or their department and everything under it); a baseline user sees themselves and whatever their role otherwise entitles. Superusers see everyone. This is what keeps user-listing and user-search endpoints from leaking every organization’s roster to every signed-in account on a shared platform.

Access control overview

Roles, grants, and allowlists.

User → agent access

Ownership, public flags, and grants day to day.

Routing and flow limits

The flow guard checked alongside the allowlist.

MCP tool access

A parallel permission model for tool access.