Skip to main content
Nasiko has two independent access-control mechanisms, checked separately:
  1. User → agent — which people can view, chat with, update, delete, or manage an agent’s secrets.
  2. Agent → agent — which agents may call which other agents.
Neither implies the other. A department can chat with a research agent while that agent’s ability to call a billing agent stays locked to an explicit allowlist.

User and org management

Create users, assign roles, build teams and departments.

User → agent access

Ownership, the public flag, and explicit grants.

Agent → agent MCP access

Per-agent connector and tool permissions.

Platform reference

Full technical reference.

Roles

Enterprise feature. The ranked role tiers below (admin through member) are enforced by nasiko-ee’s auth layer. The open-source edition has no role hierarchy — every authenticated user passes the equivalent of every capability check below by default (deploy, manage secrets, manage users are all unrestricted in OSS). If you’re running plain nasiko, skip this section.
Every user has exactly one role. Each tier includes everything below it. A role sets what kind of action a user may attempt. Whether they can act on a specific agent is decided by user → agent access.
Role is not superuser. Superuser is a separate flag. It bypasses organization-visibility scoping and unlocks platform-wide routes: creating users, creating departments and teams, OIDC group mappings, directory sync. Setting role to admin does not grant it — see user and org management.
Enterprise feature. “Creating departments and teams,” “OIDC group mappings,” and “directory sync” above are all nasiko-ee only.

Where each mechanism applies

Agent-to-agent calls are default-deny. Both the caller and the target need an explicit allowlist row. If a workflow between two agents fails, check for a missing allowlist entry first.