Skip to main content

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 repository: select a private repo from your GitHub or GitLab integration. AISafe clones the code at the revision you specify, uses a short-lived, repo-scoped token, and discards the token when the run finishes.
  • 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 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.

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 validates each URL at the start of the run; an unreachable target halts the run with a clear message so you can fix it.
  • 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, not 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.

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.

Once you start​

The live-validation stage validates the target and the authentication flow before any serious probing. A broken target or failed login stops the run early with a clear message, instead of wasting time. For the stage flow, see How it works.