Settings
Settings holds the tenant-wide configuration: everything that applies to your whole organisation rather than to one datastore or one person. Personal preferences live under Profile, not here.
Four sections in a side nav. Two are admin-only and simply do not appear otherwise:
| Section | Contains | Who sees it |
|---|---|---|
| General | Organisation details, notification defaults, tenant subscriptions | Everyone |
| Integrations | AI assistant, SSO | system:config |
| Security | Security policies, scan configuration, lifecycle, incident SLA, remediation, auto-assignment | Everyone (cards gate individually) |
| Agents | Agent runtime defaults | Agent permissions |
Cards inside a section are gated separately from the section itself, so two people who can both open Security may see different cards. As everywhere in Argus, what you cannot use is hidden rather than shown disabled. See Tenants & RBAC.
General
Section titled “General”Organization
Section titled “Organization”Read-only: tenant name, domain, and subscription tier.
Notification Defaults
Section titled “Notification Defaults”The default channel for each notification type across your organisation, editable by an admin.
The important control here is the lock. A locked row cannot be overridden by an individual, so it is how you guarantee that something is always delivered, no matter what a user has turned off in their own preferences. Everything unlocked is a default that people can change for themselves.
Lock sparingly and deliberately. A tenant that locks everything has taken away the only mechanism people have for managing their own noise, and the usual result is that they stop reading notifications altogether.
See Notifications & Subscriptions.
Notification subscriptions
Section titled “Notification subscriptions”Admin-only. Routes alerts and scan events to a specific user or team for the whole organisation. This is the tenant-level counterpart to a person’s own rules under Profile, and the two are deliberately separate surfaces. Covered in full in Notifications & Subscriptions.
Integrations
Section titled “Integrations”Requires system:config.
AI Assistant
Section titled “AI Assistant”Enables the in-product assistant. When off, the assistant icon does not appear in the top bar.
Single Sign-On (SSO)
Section titled “Single Sign-On (SSO)”OIDC identity providers for your organisation, with a connection test before you commit.
Editable by the tenant owner only. Not by a System Administrator, and not by anyone holding
system:config. That is deliberate: SSO configuration decides who can authenticate at all, so a
mistake or a malicious change is an account-takeover path rather than a misconfiguration. It is
held at the one authority that cannot be granted. See
Tenants & RBAC.
Security
Section titled “Security”Security Policies
Section titled “Security Policies”Read-only, showing the session controls that apply to everyone: session timeout, idle timeout, refresh-token validity, and invitation expiry. The reasoning behind these values, including why a full working day ends in a re-authentication prompt, is in API reference.
Scan Configuration
Section titled “Scan Configuration”Tenant-wide defaults that individual cloud accounts inherit unless they override them:
- Scan intensity - low, medium, or high. Trades coverage against time and cost. See Sampling & extrapolation.
- Data scan interval - how often contents are re-scanned.
- IAM discovery interval - how often the discovery sweep runs.
These are the fallbacks. A cloud account can pin its own intervals, and the account’s schedule dialog shows you which value you would inherit. See Cloud Accounts.
Inactive Item Lifecycle
Section titled “Inactive Item Lifecycle”The inactive grace period: how long a resource that has disappeared from your cloud, or an alert that has gone inactive, stays visible before receding from default views.
One knob covers both deliberately, so there is one mental model rather than two competing ones. The platform default is 24 hours. Raising it keeps deleted resources visible longer, which is useful during a migration when things legitimately vanish and come back; lowering it declutters faster at the cost of noticing a deletion later. Nothing is destroyed either way, and a reappearing resource is restored with its alerts and violations reactivated. See Discovery & scanning.
Incident SLA Targets
Section titled “Incident SLA Targets”Response and resolution time targets per priority, P1 through P4. These drive the On Track, At Risk, and Breached states on incidents.
Response and resolution are tracked as two independent clocks, which is what lets an incident breach its response SLA while still comfortably inside its resolution target. That combination, nobody looked at it in time, is usually the one worth catching. See Alerts & Incidents.
Automated Remediation
Section titled “Automated Remediation”The tenant-level switch that decides whether Argus may change your cloud at all.
This is the first of the two gates on every remediation run: the tenant switch here, and
remediation:execute on the person. Both are required, independently. Keeping it off lets you run
Argus in read-only mode indefinitely and get full value from discovery, classification, and
compliance, then enable writes once you trust it. See Remediation.
Auto-assignment rules
Section titled “Auto-assignment rules”Admin-only. Automatically assigns new alerts and violations to a user based on filter criteria.
Rules are evaluated in priority order and the first match wins, so ordering is the rule, not a tiebreak. A broad rule sitting above a specific one will swallow everything the specific rule was meant to catch, and the specific rule will look broken rather than shadowed. Put your narrowest rules first.
Auto-assignment and notification subscriptions share the same filter engine and the same user-or-team targeting. They differ only in what they do on a match: assignment sets an owner, a subscription sends a notification.
Agents
Section titled “Agents”Agent runtime defaults for the fleet: log level, concurrent jobs, poll and heartbeat intervals, CPU and memory throttles, and whether to skip claiming work while over throttle.
These are the tenant defaults. An individual agent can override them, and your tenant can forbid per-agent overrides entirely, in which case the agent drawer says so and points back here. The resolution order, which is worth knowing before you debug a setting that will not stick, is environment seed, then tenant default, then agent override. See Agents.
What is not here
Section titled “What is not here”- Your own notification preferences and personal subscription rules live under Profile > Notifications, not Settings. Settings is organisation-wide.
- Users, roles, and teams live under Users & Roles.
- Per-account scan schedules live on the account itself in Cloud Accounts; this page only sets the tenant default.