> ## 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.

# User → agent access

> How ownership, the public flag, and grants decide who can chat with, update, or delete an agent.

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.

<Warning>
  A soft-deleted agent is denied to everyone except through direct database recovery. No ownership, grant, or public flag overrides a deletion.
</Warning>

## What grants view and chat access

A user can reach an agent if **any** of these is true:

| Condition      | Description                                                  |
| -------------- | ------------------------------------------------------------ |
| Ownership      | The user created the agent                                   |
| Team ownership | The agent is assigned to a team the user belongs to          |
| `is_public`    | Anyone on the platform can reach it                          |
| Explicit grant | A grant names the user, their team, their department, or `*` |

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.

<Warning>
  **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.
</Warning>

## Managing grants

<Warning>
  **Enterprise feature.** Every command in this section (and "Managing an agent" below) is
  `nasiko-ee`. There's no equivalent in the plain `nasiko` CLI.
</Warning>

```bash theme={null}
# Grant a user, a team, and a department in one call
nasiko-ee access grant <agent-id> --user alice --team platform-eng --dept engineering

# Make the agent public
nasiko-ee access grant <agent-id> --public

# Revoke one user, leaving team/department grants intact
nasiko-ee access revoke <agent-id> --user alice

# Make the agent private again
nasiko-ee access revoke <agent-id> --public
```

`--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](/platform/acl).

Inspect current access:

```bash theme={null}
nasiko-ee access ls <agent-id>                   # resolved users + agent grants
nasiko-ee access visibility <agent-id>           # is_public + every raw grant by type
nasiko-ee access list-users <agent-id>           # every user with access
nasiko-ee access dept-grants <agent-id>          # departments with a grant
nasiko-ee access team-grants <agent-id>          # teams with a grant
nasiko-ee access accessible-agents <agent-id>    # agents this agent can reach
nasiko-ee access my-agents                       # agents you can reach
nasiko-ee access user-agents <user-id>           # agents a user can reach (admin only)
```

### Example: share with one team, private otherwise

```bash theme={null}
nasiko-ee access grant a1b2c3d4 --team platform-eng
nasiko-ee access visibility a1b2c3d4
```

```
Agent 'a1b2c3d4' visibility:
  Public: no

  user grants (0):
    (none)

  team grants (1):
    <platform-eng-team-id>

  department grants (0):
    (none)

  agent grants (0):
    (none)
```

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:

```bash theme={null}
nasiko-ee access rename <agent-id> "new-name"
nasiko-ee access owner <agent-id> <new-owner-user-id>
nasiko-ee access org <agent-id> --team platform-eng --dept engineering
```

Managing secrets follows the same rule, plus the `team_lead` threshold from the [overview](/onboarding/acl/overview). See [secret management](/platform/secret-manager/overview).

## Related

* [Access control overview](/onboarding/acl/overview)
* [User and org management](/onboarding/acl/user-management)
* [MCP access](/onboarding/acl/user-agent-mcp) — which external tools an agent may call
* [Secret management](/platform/secret-manager/overview)