# Managing access and risk controls in Paver Understand how Paver handles authentication and access control, stores secrets, assesses risk with Paver Guard, and limits changes with Safe mode. IBM® Paver inherits its authentication and access control from the host offering that delivers it, and provides additional runtime controls such as secrets management, risk assessment, and safe mode that you configure to match your environment's risk profile. ## Authentication and identity ### Identity and login Paver authentication is handled by the host offering or platform that delivers Paver to you. There is no separate Paver identity or password. All session policies, including password requirements, session duration, and multi-factor authentication (MFA), are governed by the identity system of the host offering. - Multi-factor authentication (MFA) is controlled by the host offering's identity and access management configuration. - Session expiry follows the session policy that is defined by the host offering. ### Paver runs as the user Paver acts on behalf of the authenticated user by using their credentials. It does not use a shared service account. Actions that are taken by Paver against resources are performed as that user, which is the same as if the user had performed those actions directly through the product's CLI or console. This means: - Paver can't exceed the permissions of the authenticated user. - Revoking a user's access in the host offering immediately prevents Paver from acting on their behalf. - The principle of least privilege applies. Users should be granted only the roles and permissions they need, and Paver is bounded by those permissions. ### Access control User access to Paver is managed through the access control mechanism of the host offering. There are no Paver-specific user accounts or role assignments to maintain separately. Administrators should use the host offering's access management to control who can use Paver and what actions they are permitted to take. ## Secrets management Paver stores user-supplied credentials, such as bearer tokens, API keys, and SSH keys, in an encrypted keyring scoped to the authenticated user. Secrets that are stored in the keyring are used by Paver to authenticate to target systems on the user's behalf and are not shared across users. Follow the best practices for managing secrets: - Store only the minimum set of credentials that are required for your workflows. - Use credentials with the minimum permissions that are required for the tasks you intend to perform. - Rotate credentials that are stored in the Paver keyring on the same schedule as your other credentials. - Remove credentials from the keyring when they are no longer needed. ```text paver keyring remove KEY_NAME ``` ## PaverGuard risk assessment Every action Paver proposes to take against a resource on behalf of the user is evaluated by Paver Guard, a secondary AI agent that classifies the risk of the action as low, medium, or high before execution. Risk is assessed based on both the nature of the operation and the context of the conversation: | Risk level | Typical operations | | ---------- | ----------------------------------------------------------------------------------------------------------------------------------- | | **Low** | Read operations such as listing, describing, or querying resources | | **Medium** | Modifications such as creating, updating, or reconfiguring resources | | **High** | Operations that can cause data loss or service interruption such as deleting resources, stopping services, changing access policies | Context matters significantly. Paver Guard considers the full conversation context when assigning risk. Tor example, deleting a blank test resource that was just created in the same conversation might be rated medium risk, while deleting a production resource hosting live workloads would be rated high risk. Users can configure a risk threshold policy: - **Prompt on medium or high risk (default)**: Paver pauses and asks for explicit confirmation before proceeding with any medium- or high-risk action. - **Auto-deny high risk**: If Paver identifies a high-risk action, it first attempts to find an alternative approach. After several unsuccessful attempts, if no lower-risk path exists, Paver returns to the user and asks for permission to proceed. - **Auto-deny medium or above**: The same behavior as auto-deny high risk, applied to both medium- and high-risk actions. Auto-deny policies are best understood as a strong preference not an absolute block. Paver exhausts alternatives before escalating back to the user. To prevent Paver from changing your environment, use Safe mode instead. ## Safety mode Safe mode controls whether Paver can make changes in your environment. You choose between two modes: Safe mode and Edit mode. In Safe mode, Paver can't make changes in your environment. It can read, query, analyze, and report, and it can read and write files in the sandbox, such as scripts or Terraform for a plan. It can't create, update, or delete anything outside the sandbox. Safe mode is the appropriate control when you want a hard guarantee that Paver won't make changes. Users can switch modes explicitly during an interactive chat session: ```text /safe ``` ```text /edit ``` Edit mode remains active for the session and all actions in Edit mode are still subject to Paver Guard risk assessment. > **Recommended practice for shared or sensitive environments** > > Keep Paver in Safe mode and consciously switch to Edit mode when changes are intended. ## Administrative best practices Review the following administrative best practices: - Train users on the difference between safe mode and edit mode and when each is appropriate. - Use the host offering's access control to restrict what resources users can modify. Because Paver acts with the permissions of the authenticated user, restricting user permissions directly limits what Paver can do. - Review conversation history periodically to audit what actions Paver has taken on behalf of your users. See [Logging, audit, and data retention in Paver](https://paver.ibm.com/docs/security/logging-and-data.md).