> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.method.security/llms.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.method.security/_mcp/server. # Security administration > Manage security settings in the Method Platform. This page describes the permissions, account lifecycle procedures, and security settings available in the Method Platform. --- ## Permission management The Method Platform uses Relationship Based Access Control (ReBAC) to specify which level of access each group has in relation to different platform resources. This is a similar authorization model to Role Based Access Control (RBAC), but is more flexible and granular, as a group can be granted different levels of access to different resources. For example, a group can be granted read permissions on some Environments, edit permissions on others, and denied access to the rest. A user's permissions are derived from those of the groups to which they belong. Please see the [Managing permissions](/guides/administration/permissions/managing-permissions) page for details on using the Administration app to manage the permissions and settings described here. ### Platform administration Members of the **Method Platform Administrators** group can perform the following actions, which are not available to other users. User and group modification are not available if users and groups are synchronized from an identity provider via SCIM. * Create user accounts * Create, delete, and rename groups * Add and remove users from groups * Specify the access levels for other groups in relation to platform resources such as Environments * Create and manage SCIM integrations and tokens Method configures the initial administrative group during platform onboarding. Existing administrators can add other users to the Method Platform Administrators group and/or remove themselves from it. ### Permissions for Environments For each Environment in the Method Platform, a group can be a Viewer, an Editor, an Owner, or none of the above. The same group can have different access levels in relation to different Environments. The Method Platform Administrators group is an Owner for each Environment by default. Additionally, a group can be an **Environment Administrator** for the platform, which makes members of the group Owners for all Environments. This can be used to separate management of the platform from management of Environments. The following table specifies the Environment-level permissions associated with each access level. | Action | Owner | Editor | Viewer | | --------------------------------------- | ----- | ------ | ------ | | Manage Environment access | ✅ | | | | Configure Environment No-Strike List | ✅ | | | | Configure Environment network type | ✅ | ✅ | | | Create Jackals | ✅ | ✅ | | | Run Tasks | ✅ | ✅ | | | Configure Operation Rules of Engagement | ✅ | ✅ | | | Create Targeting Packages | ✅ | ✅ | | | Run Research Agents | ✅ | ✅ | | | Run Pentest Agents | ✅ | ✅ | | | Run Compromise Agents | ✅ | ✅ | | | View and export Ontology Objects | ✅ | ✅ | ✅ | | View and export Findings | ✅ | ✅ | ✅ | | View and export Reports | ✅ | ✅ | ✅ | | View Targets | ✅ | ✅ | ✅ | ### Permissions for Operations Operations and Overwatch sessions have additional levels of access which are also granted to groups. These include Operations Viewer and Operations Runner. In addition to these access levels, a user must have Viewer access to the Environment that an Operation or Overwatch session is in to see it, and must have Editor access to an Environment to run an Operation or Overwatch session in that Environment. This enables an administrator to control which users can view and run Operations and Overwatch sessions without denying their access to other Environment data and actions. For example, you may want to allow users to view Ontology Objects and Reports resulting from Operations and Overwatch sessions, but not the Operations or Overwatch sessions themselves. | Action | Minimum Environment access | Operations Viewer | Operations Runner | | ----------------------- | -------------------------- | ----------------- | ----------------- | | View Operations | Viewer | ✅ | ✅ | | Run Operations | Editor | | ✅ | | View Overwatch sessions | Viewer | ✅ | ✅ | | Run Overwatch sessions | Editor | | ✅ | For details on managing Environment permissions, see [Managing permissions](/guides/administration/permissions/managing-permissions#permission-management). ## Administration app The Administration app provides centralized management for platform configuration. It includes sections for Environments, Tags, Issue Types, Jackals, Alerts, Cloud integrations, SCIM integrations, AI Inference, OAuth clients, API tokens, and platform settings. The API enforces actions that require administrative privileges. For an overview of all capabilities, see [Administration](/platform/core-platform/administration). --- ## Account creation The platform supports the following methods for creating user accounts. **SCIM provisioning (recommended)** User accounts may be provisioned through your identity provider via SCIM. In this case, users and group membership are all managed by your identity provider, and synchronized to Method. Users do not have separate Method credentials, and log in via your IdP. Supported identity providers for SCIM integrations are Okta and Microsoft Entra ID. For setup instructions, see the [Okta SSO guide](/guides/administration/sso/okta) or [Entra ID SSO guide](/guides/administration/sso/entra-id). **SSO without SCIM** It is also possible to configure SSO without SCIM. In this case, users log in via your identity provider and do not have separate Method credentials. However, users and group membership are not synchronized to Method, so account creation and group membership must still be managed within Method. For setup instructions, see the [Okta SSO guide](/guides/administration/sso/okta) or [Entra ID SSO guide](/guides/administration/sso/entra-id). **Manual account creation** Platform administrators can create user accounts from the Users section of the Administration app by providing a first name, last name, and email address. The platform generates a one-time temporary password that must be securely shared with the user. This password is displayed once and cannot be retrieved afterward. On first login, the user must: 1. Change their temporary password 2. Configure TOTP-based multi-factor authentication Login is blocked until both steps are complete. No role or group assignment occurs at account creation time. ### MFA requirements * **SCIM-provisioned accounts**: MFA is enforced by your identity provider. Configure MFA policies in Okta, Entra ID, or your chosen provider. * **Manually created accounts**: The platform requires TOTP-based MFA for all users. Enrollment is mandatory during first login and cannot be bypassed or disabled. ## Session management Users can view their active sessions and terminate all sessions from the platform. Session termination logs the user out across all clients and devices immediately. ### Decommissioning administrative access To remove administrative privileges from a user, remove them from the administrative group. The user retains their account but loses admin-specific permissions. To fully decommission a user account: * **SCIM-provisioned accounts**: Deactivate or unassign the user in your identity provider. The platform disables the account but does not permanently delete it, preserving the ability to reactivate if the user is re-provisioned. To permanently remove all users and groups from a SCIM integration, delete the integration data from the SCIM Integrations section of the Administration app. * **Manually created accounts**: Contact your Method representative to decommission the account. --- ## Security settings reference The following tables describe admin-controlled security settings available in the Method Platform, organized by category. ### Authentication and credentials | Setting | Function | Security impact | Recommended configuration | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------- | | SSO identity provider | OIDC or SAML authentication through an external identity provider, configured during onboarding with Method | Centralizes authentication and enables enforcement of organizational security policies, including MFA | Enable SSO with MFA enforced at your identity provider. See [SSO overview](/guides/administration/sso/overview). | | SCIM integration tokens | Bearer tokens that authorize your identity provider to provision and deprovision users and groups. Managed in the Administration app. | A compromised token allows unauthorized user provisioning. Token values are displayed once at creation. | Set the shortest practical expiry (maximum 365 days). Rotate before expiration. Revoke unused tokens immediately. | | API tokens | Personal access tokens for authenticating to the Method API. Managed in the Administration app. | A compromised token grants API access with the permissions of the token owner. | Set the shortest practical expiry (maximum 90 days). Revoke tokens when no longer needed. | | OAuth client credentials | Client ID and secret for machine-to-machine API authentication. Managed in the Administration app. | Compromised credentials grant API access to the platform. | Rotate client secrets regularly. Delete unused clients. Secrets are displayed once at creation. | ### Access control | Setting | Function | Security impact | Recommended configuration | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------- | | Group membership | For Method instances that do not use SCIM, users can be added to or removed from groups. | Controls which groups each user is part of. | Follow least privilege. Assign users to groups only as needed. | | Environment access | Viewer, Editor, and Owner grants to groups for each Environment. | Controls access to Environment data, actions, and settings. | Follow least privilege. Grant only the access each group needs for each Environment. | | Operations access | Operations Viewer and Operations Runner grants to groups for each Environment. | Viewing Operations also requires Environment Viewer, Editor, or Owner access. Running Operations also requires Environment Editor or Owner access. Required grants can come from different groups you belong to. | Grant Operations access only to groups that need it. Review All Users grants when restricting access. | | Default access groups | Groups that receive Viewer, Editor, and Operations Runner grants on new Environments. Viewer and Editor defaults apply when you do not specify groups at creation. | Unconfigured defaults fall back to All Users. Changing defaults does not reassign access on existing Environments. | Choose defaults that match your access requirements. Review existing Environment grants separately. | ### AI and automation | Setting | Function | Security impact | Recommended configuration | | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Model Provider authentication | API keys or credentials for connecting to LLM endpoints. Managed in the Administration app. | Compromised credentials could be used to access your LLM provider account. | Use scoped API keys with minimal permissions. Validate authentication before enabling. See [Add a model provider](/guides/administration/model-providers/add-a-model-provider). | | Model Defaults | Assigns which LLM handles Large, Medium, and Small AI requests. Managed in the Administration app. | Determines the capability and cost of AI features. Changing a default redirects all callers of that size class immediately. | Select models appropriate for your workload. See [AI Inference](/platform/core-platform/administration/ai-inference). | | Agent Policies | Allow, Deny, or Require Approval rules governing Agent actions with MCP Tools. | Controls the scope of autonomous AI Agent behavior. Without a matching Policy, all Agent actions default to Require Approval. | Default to Require Approval. Explicitly Allow only well-understood, low-risk actions. Scope Policies to specific Agents, Environments, or Tool risk levels. | | Issue severity overrides | Override default Issue severity at the platform, tag, or Environment level. Managed in the Administration app. | Affects how Issues are prioritized and triaged. | Align with your organization's risk tolerance and incident response procedures. | | Agent auto-triggers | Enable or disable Agents that run automatically when Issues are discovered. Configured per Issue type in the Administration app. | Controls the scope of automated AI response to security findings. | Enable selectively. Review Agent behavior before enabling in production Environments. | ### Platform operations | Setting | Function | Security impact | Recommended configuration | | -------------------- | ----------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------- | | Alert channels | Slack and Teams webhook URLs for platform event notifications. Managed in the Administration app. | Controls where notifications for new Issues, completed Task runs, and other events are delivered. | Configure alerts for all critical event types. Protect webhook URLs as sensitive credentials. | | Cloud integrations | AWS IAM connections for cloud resource discovery and assessment. Managed in the Administration app. | Grants the platform access to your cloud environment. | Follow least privilege when configuring IAM roles. See the [AWS integration guide](/guides/integrations/cloud/aws/overview). | | Jackal configuration | Execution mode, exfiltration parameters, workflow execution, and C2 parameters per Jackal. Managed in the Administration app. | Controls the behavior and network footprint of deployed security agents. | Configure per your operational requirements and Rules of Engagement. | --- > **Note** > > For SSO configuration, see [SSO overview](/guides/administration/sso/overview). For permission management, see [Managing permissions](/guides/administration/permissions/managing-permissions). For AI model configuration, see [Add a model provider](/guides/administration/model-providers/add-a-model-provider). To report a security concern, see [Reporting security concerns](/platform/security-governance/reporting-security-concerns).