> ## Documentation Index
> Fetch the complete documentation index at: https://docs.nasiko.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Access control reference
> How the two ACL layers are enforced, the exact capability thresholds, and org-scoped visibility.
The [access control guide](/onboarding/acl/overview) 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](/platform/orchestrator#the-flow-guard) 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](/platform/maf) 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:
| Capability | Minimum role | Covers |
| ------------------------- | ------------ | -------------------------------------------------------------- |
| Deploy and run agents | `member` | The baseline for every authenticated user |
| Manage an agent's secrets | `team_lead` | Viewing which secrets are set, rotating, injecting |
| Manage platform users | `admin` | Creating accounts, changing roles, moving people between teams |
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.
## Related
Roles, grants, and allowlists.
Ownership, public flags, and grants day to day.
The flow guard checked alongside the allowlist.
A parallel permission model for tool access.