Prepare your target

A white-box pentest needs both kinds of input: source to read, and a live target to validate against. You supply a source so the agents can find candidates, and a target URL so the agents can confirm which ones are exploitable. Without the live target, use a Source Code Audit instead.

Source inputs

Provide your source one of three ways (the same options as a code audit):

• Connected repositories: select an authorized repository from GitHub, GitLab, or Bitbucket — up to five from one provider, on every plan. Each has its own branch and selected paths. AISafe pins their commits and places each repository in a separate directory within one combined source tree. Connected public repositories are allowed too.
• Public repository URL: enter a public https://github.com/{owner}/{repo} URL. AISafe clones the default branch, or a specific commit or branch if you provide one.
• Uploaded archive: upload a ZIP or tar.gz of your codebase. Useful when your code is not in a supported git host, or when you want to test a specific snapshot. The archive should contain the full project tree so the agents can resolve cross-file dependencies. Repack 7z, XZ, or LZMA-compressed archives as a standard ZIP (store/deflate) or tar.gz before uploading.

Whichever option you choose, AISafe extracts the source into an isolated environment and builds the source model from it. You do not need to install packages or run a build before uploading.

The live target

You also provide the running application the agents will probe:

• Target URLs: one or more base URLs for the application you want tested, for example https://staging.example.com. AISafe checks each URL before the run starts. If a target is unreachable, the run does not start, you see a clear message, and you are not charged. The assessment page then shows Start refused until you fix the target and press Start again.
• Authentication instructions: optional credentials or auth flow descriptions so the agent can reach authenticated areas. Describe the login flow and provide test credentials if needed. Use a dedicated test account rather than a real one.
• Custom headers: optional headers to include in all requests, for example an API key or a session token your application expects.
• Rate limiting: an optional requests-per-second cap to avoid overwhelming the target. Use it for production or shared staging environments.
• Excluded paths: optional URL paths to skip during testing, to protect sensitive endpoints, avoid destructive actions, or stay within scope boundaries.
• Test windows: optional UTC day-and-hour windows. AISafe checks the window before every live-confirmation step and refuses to start a step outside it.

What one assessment covers

Connected repositories	Up to 5, from the same provider
Source archive	Up to 300 MB compressed
Selected source	Up to 300 MB extracted across all repositories
Files	Up to 100,000
Code	Up to 1,000,000 lines

If your code is larger than that, scope the assessment to the part of the repository you want audited (most codebases have one), or talk to us and we will size a run for the whole codebase.

The byte, file, and line limits apply to all selected repositories together, using the same source preparation as code audit and SAST.

A few file-level details worth knowing: single files over 2 MB are inventoried but not parsed (they are almost always bundles, lockfiles or vendored blobs), and AISafe reports anything it skipped in the run's coverage instead of skipping it silently.

Scope and safety

The runtime agents operate within the scope you define. Any URL outside the provided target URLs (and any additional allowed domains you configure) is unreachable from the sandbox. The sandbox can reach only the hosts you specify, and it does not follow a redirect to a domain outside your scope. This keeps the test focused and keeps the live target safe.

Because the runtime stage probes a running application, follow the same care you would for a black-box pentest: set a rate limit for a shared or production environment, and exclude destructive actions. See Prepare your target.

The check before you are charged

When you press Start, AISafe requests each target from our network before it takes any payment. The check takes seconds and runs no analysis. If a target does not answer, the run does not start and no credits leave your balance.

If you set custom headers, the check sends them too. A target that answers 401 or 403 to a request carrying your headers stops the start as well, because otherwise the run would spend its budget on requests that a login page blocks.

The message names the target, says what happened, and says what to check. The usual causes are a typo in the hostname, a firewall or IP allowlist, an expired certificate, or a token that has expired since you saved it. If your target only accepts traffic from known addresses, email [email protected] with your assessment code and we will give you the addresses we test from.

Once you start

The live-validation stage validates the target, scope, credential shape, and test windows before probing. Credentials are available only inside the live-confirmation sandbox and are shown to the agent through redacted labels. If the target, the policy, traffic capture, or storage fails, the run stops. AISafe never reports such a failure as evidence that a finding was not corroborated. For the stage flow, see How it works.