Agent Access Control

Thallus uses a 4-tier hierarchy to control which agents and tools are available to each user. Administrators can configure access at the platform, organization, group, and individual user level. The most specific explicit setting always wins.

The 4-tier hierarchy

Platform
Superadmin · Applies to all organizations
↓ inherits down
Organization
Org Admin · Applies to all org members
↓ inherits down
Group
Org Admin · Applies to group members
↓ overrides above
User Override
Org Admin · Applies to one specific user

The most specific explicit setting wins. If a user override says "allow", it overrides a group or org "deny".

Each tier serves a different purpose:

Tier Set by Scope Use case
Platform Superadmin All organizations Disable an agent system-wide (e.g., during maintenance)
Organization Org admin All members of one org Restrict data agents to orgs with data governance policies
Group Org admin Members of a specific group Give the analytics team access to data_analyzer
User Override Org admin One specific user Grant a power user access to an agent their group denies

Permission values

Every setting at every tier uses one of three values:

allow Explicitly permitted
deny Explicitly blocked
inherit Use next level up
  • allow — The agent or tool is explicitly enabled at this tier
  • deny — The agent or tool is explicitly blocked at this tier
  • inherit — No opinion at this tier; defer to the next level up

When no tier has an explicit allow or deny, the default is allowed — agents are available unless someone explicitly restricts them.

How resolution works

When Thallus checks whether a user can access an agent, it walks the tiers from most specific to least specific, stopping at the first explicit (non-inherit) value:

Example: Can user Alice use web_research?
User Override: allow
✓ Most specific — this wins
Group (Sales): deny
Overridden by user level
Organization: inherit
Overridden by user level
Platform: allow
Overridden by user level

In this example, Alice's Sales group denies web_research, but her user override explicitly allows it — so she can use it.

Multi-group resolution

If a user belongs to multiple groups, any explicit "allow" across their groups wins. This is a permissive approach: being in one group that allows an agent is enough, even if another group denies it.

Agent-level vs. tool-level control

Access control operates at two levels of granularity:

Agent-level

Controls whether an entire agent is available. When an agent is denied, the planner won't assign any work to it. The resolution uses the 4-tier hierarchy described above.

Tool-level

Controls individual tools within an agent. This lets you enable an agent but restrict specific capabilities — for example, allowing the Slack agent for reading but disabling slack_send_message.

Tool-level access adds a fifth tier at the top: User Preference. This is a setting the user controls themselves (not admin-set), giving individuals control over which tools they're comfortable with.

Priority Tier Who sets it
1 (highest) User Preference The user themselves
2 User Override Org admin
3 Group Org admin
4 Organization Org admin
5 (lowest) Platform Superadmin

User preferences let individuals opt out of specific tools without needing an admin. For example, a user could disable google_send_email while keeping the rest of the Google agent's tools active.

Practical scenarios

Scenario Configuration Result
Disable data agents for the whole org Org: deny data_router, data_analyzer, data_explorer No one in the org can use data agents
Analytics team gets data access Org: deny data agents, Group (Analytics): allow Analytics members can use data agents, others can't
One user needs an exception Group: deny web_research, User Override: allow That specific user can use web_research despite group deny
User doesn't want email sending User Preference: deny google_send_email Google agent available but can't send emails for this user
Platform maintenance Platform: deny data_router No organization can use data_router until re-enabled

What happens to denied agents

When an agent is denied for a user:

  • It's excluded from the available agents list during planning
  • The planner never assigns work to it — it simply doesn't exist from the planner's perspective
  • If the only agent that could handle a task is denied, the planner works around it with remaining agents or reports that it can't complete that part of the query

This is different from an agent being unavailable due to a missing connection. Denied agents are intentionally restricted; unavailable agents are just not configured yet. See Turning Agents On/Off for more on availability states.

Next steps