Tenants & RBAC

Argus is multi-tenant by default, built for MSSPs and for enterprises with subsidiaries. A tenant is the boundary everything else lives inside, and RBAC decides what each person can do within it.

Tenant isolation

Every record belongs to exactly one tenant: datastores, identities, alerts, policies, agents, audit entries, and settings. Queries are tenant-scoped at the data layer rather than filtered in the UI, so there is no cross-tenant view anywhere in the product, and no way to widen your own scope from inside it.

Your audit log is yours: tenant activity is recorded against your tenant and is never mixed with anyone else’s.

Tenant ownership

A tenant has exactly one owner. It is established once, when the tenant is first set up, and it is not a role you can assign, hand out, or hold alongside another.

That has a few practical consequences:

• The owner is not in the roles list. No amount of role editing produces another owner, and System Administrator, the most powerful assignable role, explicitly cannot manage owners.
• You cannot promote a colleague to owner from inside the tenant. There is no transfer action, by design: ownership is the one authority that cannot be granted by someone who already holds everything else, which is what stops it from being escalated into.
• If the owner loses access, the recovery path is a password or MFA reset on the existing owner account, not the creation of a second one. Contact support.

Plan for the owner account before you need it

Because ownership cannot be transferred from inside the product, an owner account tied to one person’s mailbox becomes a real operational risk when that person leaves. Point it at an address the organisation controls, and make sure more than one person can reach that mailbox and its MFA.

How a permission check works

Permissions are resource:action strings, for example datastores:scan or remediation:execute. A user holds the union of the permissions carried by their roles.

Resolution order:

1. Inactive users hold nothing. Deactivating an account revokes access immediately, whatever its roles say.
2. The tenant owner holds everything within the tenant.
3. Otherwise, the union of all permissions across the user’s roles must contain what the action requires.

There is also a wildcard permission (*) that satisfies any check. At the tenant layer it is effectively the owner’s capability.

Two kinds of permission

Most permissions gate an action. A distinct family of :view permissions gates visibility: whether a nav item and its page appear at all. That is why the sidebar differs between colleagues in the same tenant, and why a missing page is a permissions answer rather than a bug. Argus hides what you cannot use rather than showing it disabled. See Navigating Argus.

The permission catalogue

Grouped by module. Permissions marked dangerous are flagged as such in the role editor, so a role granting them is obvious at a glance while you are building it.

Module	Permissions
Security	view, read, write (dangerous), delete (dangerous), scan
Compliance	view, read, write (dangerous), approve (dangerous), export
Users	view, read, write (dangerous), delete (dangerous), invite, roles (dangerous)
Datastores	view, read, write, scan, remediate (dangerous)
Alerts	read, write
Incidents	read, write, manage (dangerous)
Policies	read, write, manage (dangerous)
Reports	read, write
Audit	read, self, export, search
System	admin (dangerous), config (dangerous), audit, api_keys (dangerous), monitoring
Cloud Accounts	view, read, write (dangerous), delete (dangerous)
Agents	view, read, write (dangerous), delete (dangerous)
Risk	read
Identity	read, write
Recommendations	read
Remediation	read, write, execute (dangerous), manage (dangerous)
Newsletters	read, write (dangerous)
Assistant	use

A few are worth calling out because their names undersell what they allow:

• audit:self lets someone see only their own activity, as opposed to audit:read for the whole tenant. It is how you give an analyst accountability without giving them visibility into everyone else.
• remediation:execute is the permission that changes your cloud. remediation:manage goes further: creating auto-run workflows, deleting workflows, and self-approving executions. Granting manage to the same person who authors workflows removes the second pair of eyes entirely.
• users:roles is the permission to define permissions. Treat it as the most powerful grant in the catalogue.

The six built-in roles

These ship with every tenant as system roles. They cannot be edited or deleted, which is deliberate: a known-good baseline you can always fall back to and compare against.

Role	Level	Intent
System Administrator	admin	Full tenant access, including user and role management and all of remediation
Security Manager	manager	Runs security operations, can invite users, can execute remediation but not author auto-run workflows
Security Analyst	user	Day-to-day analysis. Can design workflows but not execute them
Compliance Auditor	user	Read and export across compliance, security, and audit. No write anywhere
Data Protection Officer	manager	Compliance approval authority, and can execute remediation, without broad security write
Read-Only Viewer	viewer	Sees dashboards and reports, changes nothing

Two design choices in there are worth copying if you build custom roles:

Analyst designs, Manager executes

Security Analyst holds remediation:write but not remediation:execute. Someone can build and refine a fix without being able to fire it at production, and the person who approves it is a different person.

That split is the whole reason the approval gate is worth having. If you grant write and execute to the same role, the gate becomes a formality that person clicks through on their own work.

System Administrator is not the tenant owner. It is the most powerful assignable role, but it explicitly cannot manage tenant owners and does not carry system:admin. Ownership is a property of the account rather than a role, and there is only ever one of them.

Custom roles

Create a role, or clone a system role and adjust it. Cloning is usually the better start: you inherit a coherent permission set instead of assembling one from 60-odd checkboxes and discovering later that you missed a :view.

System roles are read-only in the editor. Custom roles can be edited, and can be deleted only when no users are assigned to them, so deleting a role can never silently strip someone’s access.

Roles are managed on the Roles tab of User Management, which requires users:roles.

The escalation guards

Two rules govern who can grant what, and both exist to stop privilege escalation by proxy.

Only tenant owners can assign admin-level roles. A System Administrator cannot mint another admin.

You cannot grant a permission you do not hold, even indirectly

Granting a role grants everything inside it, so checking only the role’s level is not enough. A non-admin role can still carry permissions the caller lacks.

The attack it prevents is concrete: a user with users:write attaches a role containing remediation:execute to a second account they control, logs in as that account, and now holds a permission nobody gave them. Argus compares the union of the target roles’ permissions against what the caller actually holds and refuses the assignment if it would exceed it.

The practical implication: if a role assignment is rejected and the role looks harmless, check what is inside it against your own permissions.

Who can see whom

The user list is filtered by your own standing, not just by tenant:

• Non-owners cannot see tenant owners at all.
• Users without an admin-level role cannot see admin-level users.

So your colleague’s user list may be shorter than yours. This is intentional: it keeps the administrative hierarchy from being enumerable by someone lower in it.

Teams

Teams group users so work can be assigned to a group rather than an individual. Alerts, incidents, policies, and violations can all be owned by a team, which is how work survives someone being on holiday. Teams are managed on the Teams tab and carry a name, a description, and members.

Assigning to a team rather than a person is the better default for anything with an SLA. See Alerts & Incidents.

Where to go next

• Users & Roles for inviting people and the day-to-day of managing accounts.
• Audit Log for what gets recorded, including every role change.