> For the complete documentation index, see [llms.txt](https://docs.konvu.com/konvu/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.konvu.com/konvu/administration/assessment-settings.md). # Assessment Settings Configure AI assessment settings, bring your own OpenAI key, and control which repositories Konvu assesses and at which severities. You configure AI assessment settings from **Agents > Coverage** in the dashboard. This page covers OpenAI configuration (BYOK), code evidence collection, per-repository assessment control, secret scanning, and the severities each repository is assessed for. ## OpenAI configuration (BYOK) By default, Konvu uses its own OpenAI API keys to run AI-powered triage assessments. If your organization requires using your own OpenAI keys (for compliance, cost control, or to use a custom endpoint) you can configure this at the organization level. The BYOK configuration accepts three fields: | Field | Required | Description | | --------------------------- | ---------------------- | -------------------------------------------------------------------------------------------------------- | | **OpenAI API Key** | Yes (for BYOK) | Your OpenAI API key. Stored encrypted at rest. | | **API URL** | Only with custom model | Custom endpoint URL (e.g., for Azure OpenAI). Requires an API key and model name. | | **Model / Deployment Name** | Only with custom URL | The model to use (e.g., `gpt-4`, `o4-mini`, or your Azure deployment name). Requires an API key and URL. | {% hint style="warning" %} When you provide a custom API URL, both the API key and model name are required. Konvu enforces this to prevent sending the platform key to a custom endpoint. {% endhint %} To clear your BYOK configuration and revert to Konvu's managed keys, remove the API key from the configuration modal. ## Collect code evidence The **Collect Code Evidence** toggle controls whether AI triage assessments include source code snippets in evidence bundles. When disabled, assessments only collect metadata (file paths, line numbers). No code is stored. This setting applies to all repositories in your organization. ## Repository assessment The bottom section of the AI Triage page lists all repositories with SCM integrations. You enable or disable AI assessments per repository using the checkboxes. Only repositories with assessment enabled will consume [assessment credits](/konvu/administration/assessment-credits.md) when findings are assessed. {% hint style="info" %} New organizations can also configure which repositories to assess during the onboarding welcome flow, which limits initial assessment to up to 3 repositories. {% endhint %} ## Secret scanning Enable secret scanning for repositories whose credentials you want to review: 1. [Connect your source code](/konvu/get-started/connect-your-environment/source-code.md) through managed or self-hosted analysis. 2. Open **Agents > Coverage**. In the repository table, open **Enable…** for a repository and select **Secret scanning**. 3. After analysis runs, open **Triage > Secrets > Konvu detections**. See [Triage Secrets](/konvu/triage-and-remediation/finding-types/secrets.md) for the review workflow. Secret scanning is separate from the CVSS severity scope below. Detection checks the repository checkout; it does not establish that every historical commit or previously distributed copy is free of secrets. If Secrets is unavailable in your organization, contact to check enablement. ### Provider validation Provider validation can make live requests to a detected credential's provider to check whether it accepts the credential. Detection can continue with provider validation disabled. This policy is controlled at the organization level. Its default is enabled for managed workspaces and disabled for on-premises workspaces, unless explicitly overridden. Contact the Konvu team to confirm or change your organization's policy. Validation support and evidence vary by provider. A disabled, unsupported, or inconclusive check can leave validity **Unknown**. See [Secrets data handling](/konvu/reference/data-collection-and-security.md#secrets-data-handling) for details on outbound requests and masked findings. ### Import GitHub Secret Scanning alerts The **GitHub alerts** tab displays alerts imported through your existing GitHub App. The App needs **Secret scanning alerts** read permission and access to the relevant repository's alerts. If the tab is empty, check those permissions and whether GitHub has alerts available to import. ## Scope assessments by severity By default, AI Assessment runs on findings of every severity. You can restrict it — for example, to only `CRITICAL` and `HIGH` — at two levels: an **organization-wide default** that new repositories inherit, and **per-repository overrides**. Findings outside the selected severities are never assessed and never consume [assessment credits](/konvu/administration/assessment-credits.md). Konvu uses the CVSS severity attached to each vulnerability: | Severity | API value | | -------- | ---------- | | Critical | `CRITICAL` | | High | `HIGH` | | Medium | `MODERATE` | | Low | `LOW` | A finding is assessed only when its severity is in the repository's selected set. Findings whose severity is unknown are skipped whenever a restriction is set. With no restriction, all severities are assessed. {% hint style="info" %} Severity scope only narrows what gets assessed within repositories that already have assessment enabled — it does not enable assessment on its own. A repository with assessment disabled is never assessed, regardless of severity. {% endhint %} ### From the dashboard Severity scope lives on the **Agents > Coverage** page. **Global default** — under **Argus**, the severities new repositories inherit. Add a severity from the dropdown or remove one with the **x** on its tag; changes save automatically. Enabling Argus on a repository starts it on this default, and **Reset all to default** pushes the current default onto every active repository (discarding per-repository overrides). **Per repository** — in the **Applies to** table, a repository's **Overwrite…** menu sets severities for that repository alone. The table shows a repository's severities only when they differ from the default.

Set the global default severities under Argus, then override per repository in the Applies to table.

### From the API Set severities per repository with `PATCH /repositories/assessment_config` (one list item per repository), and the organization default with `PUT /repositories/assessment_config/default_severities`. `GET /repositories/assessment_config` returns both. ```bash # Scope one repository to critical + high, another to medium only curl -X PATCH https://api.konvu.com/repositories/assessment_config \ -H "Authorization: Bearer api_YOUR_KEY_HERE" \ -H "Content-Type: application/json" \ -d '[ {"repository_id": "", "assessment_severities": ["CRITICAL", "HIGH"]}, {"repository_id": "", "assessment_severities": ["MODERATE"]} ]' ``` Send `null` to clear a restriction (all severities); an empty list is rejected. See the [API reference](/konvu/reference/api-documentation.md) for the full schema. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.konvu.com/konvu/administration/assessment-settings.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.