Skip to main content

Prepare your target

To run a pentest, you provide a target and the access the agents need to reach it. All testing stays within the scope you set.

Target URLs​

You give one to twenty-five base URLs for the application you want tested, for example https://staging.example.com. Each URL must be distinct. Listing the same host twice would not test it twice, so AISafe tells you about the repeat instead of quietly ignoring it. 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 with the name of the target AISafe could not reach, and the page still shows this when you come back to it. Fix the target and press Start again.

Domain ownership​

AISafe tests only hosts you control. You prove each host once for your organization, and the proof then covers every project and assessment that tests it. A proof does not expire.

You prove a host with any one of three proofs. The Verify dialog shows them as three tabs:

  • CNAME: a CNAME record at your DNS provider. Its name is the record name shown, which starts with _aisafe-verification-, and it points at the value shown, which ends in verify.aisafe.io. The record goes on that verification name, never on the host itself, so it does not change how your site is served. AISafe reads only this one record. It does not look up or connect to the name the record points at, so that name does not need to resolve.
  • File: an HTTPS file at the displayed URL, containing only the displayed value.
  • TXT: a TXT record at your DNS provider, at the same record name, with the displayed value.

The record name and file name contain a random part, so nobody can look up a fixed name on your domain to learn whether you use AISafe. The record stays the same, so a record you published once keeps working. A proof covers that exact host name; a subdomain needs its own proof.

You can prove a project's hosts before you start an assessment. Open the project's Setup, then Targets. Each host shows whether it is verified and, once it is, how and when. Press Verify beside a host to see its CNAME record, its file and its TXT record, publish one of them, and press Check now. If the check does not find the record, the dialog says why, for example that the record was not found yet or that its value does not match.

When you create an assessment, Define test scope and the Additional allowed domains list in Advanced configuration show the same states. A host your organization already proved shows as verified and needs nothing more; every other host has a Verify button that opens the same dialog. You can move on to the next step before you prove a host.

AISafe checks the proof when you start validation. If a host is not proved yet, the assessment waits in validation and shows Waiting for domain proof. View instructions lists each host with its record. Publish the record, then press Check now. Once every host is proved, validation continues on its own, including when you prove the host from another assessment or the project. Nothing is charged while the assessment waits. There is no deadline: the assessment waits until you check again, change the scope with Edit scope, or cancel.

If your organization no longer controls a host, an organization admin can remove its verification. New tests of that host are refused until it is proved again, and monitoring and schedules that reach it pause. Tests that are already running finish.

For wildcard scope, IP addresses or testing on behalf of a client, contact AISafe with the client's written authorization. AISafe reviews the exact hosts and approves them for your organization until the end date of that authorization.

Test users and login instructions​

Use Test Users to give the agents accounts to sign in with. Each test user has a name, which is its role in your application (for example admin or member), a username and a password. If the account signs in with a one-time code from an authenticator app, also enter its base32 secret key. Use dedicated test accounts rather than real ones.

Depending on how the account signs in, a test user can also have the URL of its login page, a separate inbox for email verification, or the OAuth token URL, client ID, client secret, scope and audience. The agents receive these with the account. A client secret is handled like a password: it is not displayed again, and the agents use it without seeing it.

You can add up to ten test users. Several test users can share a role. To test whether one user can read or change another user's data, add two accounts with the same role, for example two member accounts. The agents tell your accounts apart by their usernames.

The agents that explore your application and the agents that test each possible issue all receive your test users. They sign in through your application's own login form, and for an account with a secret key they generate the current six-digit code the way an authenticator app does. They test your application both signed out and signed in.

The agents' instructions never contain a password or a secret key. The agents enter them into your login form or a login request without seeing them, and they are told never to write them down. Findings and reports name an account by its role and username. When a finding's evidence shows a login request, it shows the request exactly as it was sent, password included, so that you can reproduce the finding with the same account. The live Traffic view replaces the password and any six-digit authenticator code with [test user secret].

Use the login instructions to describe anything about signing in that the agents cannot find on their own, such as the address of the login page or an extra step. The instructions apply to every test user. Request tokens such as API keys belong in Custom headers.

Saved passwords and secret keys are not displayed again. If you replace saved test users, enter the credentials for every account you want to keep.

The Try to create new users option, off by default, lets the agents register their own accounts through your application's normal public sign-up when that helps them compare one account or tenant against another. This is useful when you supply one account or none. The agents use only your public sign-up on an authorized target, never an admin or internal user-creation endpoint, and they record each account they create, with its username or email and the host, in the report so you can remove it afterwards.

Custom headers​

Optional headers to include in all requests, for example an API key or a session token your application expects. You can add up to twenty, with one entry per header name.

Rate limiting​

An optional requests-per-second cap to avoid overwhelming the target. Use this for production or shared staging environments.

Excluded paths​

Optional URL paths to skip during testing, up to one hundred. Use this to protect sensitive endpoints, avoid destructive actions, or stay within scope boundaries.

Reachability and scope​

The 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. This keeps the test focused and stops the agent from testing areas you did not intend to test.

Three limits keep the run safe:

  • The sandbox egress is allowlisted. It reaches only the hosts you specify, and the platform blocks any host not in your allowlist.
  • The sandbox connects only to public internet addresses. When a host in your scope resolves to a loopback, private, link-local or other internal address (for example 127.0.0.1, 10.0.0.5 or 169.254.169.254), the request is refused and recorded as blocked, even though the host name is in scope. Make sure each target's DNS name resolves to a public address.
  • If the agent meets a redirect to a domain outside your scope, it does not follow it. This keeps the test in bounds even when your application links to external services.

Because egress is allowlisted and redirects outside scope are not followed, the target must be reachable directly from the sandbox. Do not expect the agent to follow a chain that leaves your configured domains.

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. Common causes:

  • A typo in the hostname, or a DNS record that is not public.
  • A firewall or IP allowlist that only admits addresses you know about.
  • A certificate that has expired or does not cover the hostname.
  • A header, cookie or token that has expired since you saved it.

If your target only accepts traffic from known addresses, email support@aisafe.io with your assessment code. We will give you the addresses we test from and set it up with you.

Once you start​

The first stage explores the target before any deeper testing, signed out and, when you saved test users, signed in. If it finds nothing in the application that it can test, the run stops early, so that no time is wasted. See How it works.

During testing, agents may read your test users' account settings but must not submit changes to their credentials or sign-in setup. If a test user can no longer sign in after testing has started, the assessment stops using that user and continues with the others. Checks that need the unavailable user remain inconclusive. Check the user's password, second factor and account status before starting another assessment.

Limits on what you send​

Every list on this page has a maximum length, and the entries have to be distinct. If you go over a limit or repeat an entry, AISafe refuses the input with a clear message that names the limit. We never quietly trim a list to fit, because the results would then suggest that we tested something we did not.

These limits apply to what you send us, never to what we return. An assessment reports every finding it produced, however many there are.

For an assessment on behalf of a client, contact AISafe to discuss authorization.