Assessment
Completed code audits and white-box assessments can check submitted source with Verify fixes. These reviews check the source you attach and do not confirm that it has been deployed. The first completed review of each finding is free; later source reviews show their price before you start.
When live black-box verification is enabled, Verify fixes repeats the finding's captured request against the same authorized target. AISafe records a verdict only after the target returns a response; a connection failure is not treated as proof that the issue was fixed. The repeated request must use the same request headers. If the original check used authentication that is no longer available, AISafe asks you to run a new assessment with current authentication details instead of testing without them.
An Assessment is one run of AISafe against one target: a codebase, a URL, or both. It is the central work unit of the platform. Findings, reports, artifacts, and triage all belong to one assessment. You create an assessment by clicking "Start assessment" in the dashboard.
For source-based assessments, AISafe records the repository or archive label, requested branch, resolved ref, and exact commit with the run. Past assessments keep that provenance even if the integration is later removed.
After a code audit or white-box assessment, Update source lets you select a branch, tag, or commit from the same repository, or attach an updated archive for an archive-based assessment. Repository previews show the exact commit that will be attached. Submitting unchanged source keeps the current revision; it does not add another history entry. Updating from a repository downloads each repository you moved, which can take a minute or more for a large application; the dialog says how many repositories are attaching until the update finishes. If the dialog cannot confirm the result, the update may still finish: check the revision history before you try again. Revision history keeps the original source and every changed candidate. If the original archive needs recovery, verification reports that source is unavailable until it can be restored.
Updating source through the API
POST /api/v1/assessments/{id}/revisions (a new revision from a repository),
POST /api/v1/assessments/{id}/revisions/upload (an archive) and
POST /api/v1/assessments/{id}/revisions/patch (a patch) no longer return the
revision. Each answers 202 Accepted with an attachment whose status is
running, and a worker fetches the repositories, extracts the archive or
applies the patch. Poll
GET /api/v1/assessments/{id}/revision-attachments/{attachment_id} every few
seconds until status is succeeded or failed:
succeededcarriesoutcome(created, orunchangedwhen the source already matched the current revision) and therevision.failedcarrieserror.code,error.messageanderror.retryable, which says whether trying again can help.
Send an idempotency_key (16 to 128 letters, digits, - or _) with each
update: in the JSON body for a repository, as a form field for an archive or a
patch. If you do not get an answer, send the same request with the same key:
you get the attachment you already started, so the update is never attached
twice. The same key with a different body (or a different file) is refused with 422
idempotency_key_reused. A failed attempt needs a new idempotency key:
the same key returns the same failed attachment. While one update runs, a
second one for the same assessment is refused with 409
source_activity_in_flight.
A file that is not an archive, one over the size limit, or an empty patch is
still refused at once. Problems found while extracting it, such as nothing
left in the assessment's scope or a patch that does not apply, arrive as the
attachment's error.
Your fix can add, move and rename files, and the update includes those changes. AISafe keeps every file the assessment read and adds new files, unless a new file is under a path you excluded when you set up the assessment or in a directory that is never audited, such as dependencies, build output and caches. A file that your fix deleted is no longer part of the source, and the changed files list shows it as removed. You do not need to choose the file scope again: the assessment's original scope still applies, and the new files are included under it.
While a verification is running, you cannot use Update source or start a second verification. Each verification is tied to the exact revision it was quoted for, so it always checks the source you started it on.
Verification progress stays on the assessment when you close the dialog or reload the page. It shows how many findings have been reviewed and keeps each attempt in history. A retry uses the same source, keeps completed reviews, and advances the attempt number while preserving earlier attempts. If the source or billing needs repair, AISafe explains the problem and does not allow a retry until the problem is resolved. Attaching a different revision starts a new review with a new quote.
Open verification results and use Verification history to revisit an older check, its attempts and its payment details. Load older verifications shows earlier checks. Choosing one leaves the assessment's current progress unchanged.
Open Insights & Tools → Source to follow the repository link. Its icon and link match your provider: GitHub, GitLab, or Bitbucket. GitLab links keep the full subgroup path. Assessments that use a project's source show that repository here.
Identity
Each assessment carries a human-readable public ID of the form AIS-{ORG}-{CODE} (e.g. AIS-ACME-TLP). The code is unique within the owning organization. A draft is given its ID the moment you create it and keeps it: submitting the draft, or renaming it later, does not change the ID, so a link you share while configuring a run still opens the finished one. These IDs appear in URLs and reports and form part of each downstream finding ID.
From the assessments list, you can select several rows and delete the selected drafts together. If the selection also includes assessments that have started, AISafe deletes only the drafts and leaves the other assessments unchanged.
Types
AISafe defines two primary assessment types:
| Type | What it does | Source input |
|---|---|---|
| Code Audit | Whitebox static analysis. AI agents examine your source for vulnerabilities, taint flows, and misconfigurations. | GitHub, GitLab, or Bitbucket repo, or uploaded archive |
| Pentest | Blackbox runtime testing. AI agents probe your live application over HTTP, modeling the attack surface and testing for exploitable vulnerabilities. | Target URLs + optional credentials |
A hybrid white-box mode combines static analysis with additional agent probing against live targets, using both source and target URLs.
Lifecycle
An assessment moves through these stages:
- Draft. You configure the name, source/target, type, and optional instructions. Nothing has run yet.
- Validation. AISafe validates the source (clones the repo, resolves the ref, checks the archive) and confirms the target is reachable.
- Running. AI agents execute in isolated sandboxes. For code audits, AISafe streams live workflow milestones through Understanding → Analysis → Audit → Triage → Report.
- Completed. Findings are final, triage is complete, and a report is ready.
- Failed. The assessment encountered an unrecoverable error. AISafe refunds credits.
During validation, a compact preparation card shows the active check beside the elapsed time, with a row of stages below and a check for each completed stage. The card has the same compact size as the ready card, and it grows when text or credit controls need more room. A small 3×3 spinner beside the active stage moves a bright highlight around the grid while all nine pixels stay visible. It stays still when you enable reduced motion. Source analysis can take five minutes or more for large repositories. The paid assessment has not started, and no credits have been spent.
The source picker shows no provisional price. Once AISafe has finished counting the source, the preparation card can show the Codebase quote. Until then, it says Calculating quote. This is the total price for the assessment, not an hourly charge. Estimated assessment time covers the assessment itself, excluding validation, and stays consistent when the assessment becomes ready. For example, a $40 code audit may show about 1 hr 40 min, and a very large monorepo about 10 hr. You can start after source analysis has finished and AISafe has checked its saved result. The compact ready card keeps Start and Cancel together below the quote and time estimate.
Code-audit progress moves forward each time the workflow reaches a new milestone; it does not move forward as wall-clock time passes. The time estimate is only there to set expectations: it does not control the timeline, limit the work, or delay a completed result.
A model provider can decline a request, or remain unavailable after retries. AISafe does not count analysis as completed when the model output is missing. AISafe keeps the provider diagnostics and the completed work so that the failure can be investigated. A provider failure does not show that the assessed code is safe.
Steering
You can provide additional instructions: free-form text that tells the agents what to prioritize (e.g. "focus on medium-or-higher vulnerabilities that map to a CVE" or "this is a mature library, prioritize logic bugs over input validation"). Scope and safety rules take precedence over steering instructions.
Project membership
An assessment may belong to a Project. Project-bound assessments load context from the project's living knowledge base at start and contribute new knowledge back at completion, making them faster and more accurate than standalone runs. See Project for details.