Identity and access
Configure roles, group boundaries, SSO, service accounts, approval grants, and emergency access.
Guard authorizes each request using organization membership, role, allowed asset groups, and any required special grant. API-key scopes narrow those permissions; a broad scope cannot expand the key owner's role.
Roles and sensitive grants
Each role supplies the following authority within its permitted asset groups:
| Role | Typical authority |
|---|---|
| Owner | Membership, billing, organization settings, and delegation |
| Administrator | Assets, policies, integrations, and protection configuration |
| Analyst | Detections, findings, incidents, and non-disruptive investigation |
| Responder | Analyst work plus permitted response requests |
| Auditor | Read approved reports and audit records |
Evidence download, employee-sensitive detail, response approval, and retention-hold management require separate grants. Assign them at Organization → Members → Member → Access. The Responder role alone does not authorize approval of a disruptive action.
Installation operators administer deployment health. To read organization data, they also need explicit organization membership and the required grants.
At Organization → Members → Member → Access, choose the role and permitted groups. Organization-wide resources require organization-wide authority. A report spanning several groups requires access to all of them; Guard rejects a broader request instead of silently returning a complete-looking partial report.
Sign-in and lifecycle
Open Organization → Authentication → Add identity provider. Use the supplied callback URL and metadata in your SAML or OIDC provider, map groups to existing roles, and test a second account before requiring SSO. Keep a recovery Owner with a tested sign-in path and strong authentication. Require MFA at Organization → Authentication → Session policy.
At Organization → Members → Member → Revoke sessions, terminate console access after a role change or suspected compromise. Disable the identity in the upstream provider as well. Guard access revocation does not revoke unrelated provider tokens or end an already applied endpoint isolation state.
Automation identities
Create a dedicated principal under Organization → Service accounts → Create. Select its permitted groups, API scopes, and key expiry. Copy the key into the automation system's secret manager when it is displayed; Guard shows its plaintext once. Use a separate account for each task, such as inventory or response, so its access can be changed independently.
To rotate a key, open Organization → Service accounts → Account → Create key. Install the replacement in the client and confirm that its required requests succeed before selecting the old key and choosing Revoke. Expired or revoked keys return 401; a valid key without the required permission returns 403.
Do not use an agent enrollment token as a management API key. Agent and gateway identities authorize their own reports and configuration channel, not organization administration. See API authentication.
Approval and audit
Set response approval rules at Organization → Response controls → Approval rules. Broad isolation, restoration, and access changes can require a second authorized person. Approval binds the exact action revision, targets, parameters, and expiry; changing those inputs requires new approval. Review access and approval changes under Organization → Audit using audit records.