Access Control

AgenFleet uses a layered access control model. Permissions are enforced at three levels: portal users (who can do what in the dashboard), agents (what each agent is allowed to do), and tools (which capabilities each agent can invoke).

Portal user roles

Every user in your AgenFleet workspace has one of three roles:

Role	What they can do
Admin	Full access — billing, team management, all agents, all settings, delete operations
Manager	Create and manage agents, configure cron jobs, manage integrations — no billing or delete access
Viewer	Read-only access — view agents, sessions, fleet status, and cron history — no configuration

Assigning roles

Go to Settings → Team to invite users and assign roles. Roles can be changed at any time by an Admin.

What Viewers cannot do

Viewers are intentionally scoped to read-only — not configure. They cannot:

Create, edit, or delete agents
Modify cron jobs
Change notification settings
View or export audit logs
Access billing information
Invite or remove team members

This makes the Viewer role safe for client-facing or stakeholder access — they can observe the agent fleet without being able to alter it.

Agent-level permissions

Each agent has an independent permission scope. An agent can only do what its configuration explicitly allows.

Tool restrictions

The tools.allowed list controls which tools an agent can invoke. This is enforced at the platform level — the agent cannot call a tool it wasn’t granted, even if it tries.

"tools": {
  "allowed": ["web_search", "memory_search", "send_message"]
}

An agent without http_request in its allowed list cannot make external API calls. An agent without run_script cannot execute code. This is not advisory — it is enforced.

Why this matters

If an agent is ever manipulated by a malicious prompt (prompt injection), it can only do damage within the bounds of its granted tools. An agent that only has memory_search and send_message cannot exfiltrate data via http_request because that tool is simply not available to it.

Principle of least privilege at the tool level is one of the most important security configurations you can make.

Session access

Sessions are scoped to the agent that owns them. Users with portal access can view session history for agents they have access to, but:

Members can only see their own sessions (conversations they initiated)
Admins and Owners can view all sessions for all agents
No cross-tenant session visibility is possible — this is enforced by row-level security at the database layer

Credential isolation

When you configure an agent to use a tool that requires credentials (e.g., http_request with an API key), credentials are:

Stored in the secrets vault, not in the agent config
Referenced by name in the agent’s environment variables
Injected into the agent’s container at runtime — never written to disk
Not visible in logs, audit trails, or the portal UI

An agent can use a credential to make an API call but cannot read or exfiltrate the raw credential value.

Multi-tenant isolation

In multi-tenant deployments (Enterprise plan), access control extends to the tenant level:

Each tenant’s agents, sessions, and data are isolated in a separate database schema
Row-level security policies ensure queries can only return data belonging to the authenticated tenant
One tenant’s Admin cannot see, modify, or interact with another tenant’s agents — even if they somehow obtained a valid JWT for the wrong tenant

See Data Isolation for the full architecture details.

Session token security

Portal authentication uses signed session tokens with a limited validity window. Tokens are invalidated on explicit logout and account deletion. AgenFleet is actively hardening the session token implementation — improvements including shorter token lifetimes, HTTP-only cookie storage, and automatic invalidation on role or password changes are on the active engineering backlog.