Testing your asset safely

XBOW includes safeguards to reduce the risk of damage, but no automated security test can promise zero impact. Penetration testing exercises real functionality, so how safe an assessment is depends on where you run it and how you configure it. This article helps you make both decisions.

What XBOW does by default

Every assessment includes these protections without any configuration. For a full description, see Automatic security measures.

• Safety instructions are part of every attack agent’s prompt.
• An AI safety judge and a set of deterministic rules check every command before it runs.
• Endpoints that are likely to disrupt the assessment, such as logout and password reset, are protected automatically to keep the assessment running. Add your own protections for other destructive endpoints, such as account deletion. See Automatically protected URLs.
• Endpoints that are likely to disrupt the assessment, such as logout and password reset, are protected automatically to keep the assessment running.
• XBOW monitors your asset’s health, slows down when it struggles, and pauses if it does not recover.

These protections work alongside the controls you set. They do not replace them.

Choose where to test

The environment you choose sets the upper limit on how freely you can test.

• A staging or test environment gives you the most freedom. You can use higher request rates and deeper impact demonstration. A problem there should not affect real users.
• Production is a valid target, but a problem can affect real users. Use conservative settings and make a plan in case something goes wrong. Make sure you can restore data and that someone on your operations team can respond.

Before you treat an environment as safe, check that it is fully separate from production. A test environment that shares a database, email service, or third-party integration with production can still cause real consequences.

Match your settings to your risk

Use the table as a starting point, then adjust after you see how your asset behaves.

Any rate limit can significantly increase how long an assessment takes. In Console, a limit of 100 requests per second or lower turns on sequential mode automatically, which slows the assessment further.

For more about each setting, see:

• Using a dedicated test account
• Target protection
• Limiting impact demonstration
• Limiting request rates
• Defining test windows

Run a careful first assessment

You cannot change domain scopes, protected URLs, or rate limits after the assessment starts, so decide them first.

1. Create a dedicated test account with normal-user permissions. See Define authentication for testing.
2. If you add assessment guidance, review the safety guidance XBOW extracts. See Write effective safety guidance.
3. Check the Rate limit setting. If it is off, XBOW sends unlimited requests per second. If you turn it on, it starts at 500 requests per second, so lower it to 250 or lower for your first production assessment. Additionally, choose a testing window your team can support. See Set test execution options.
4. Allow XBOW’s traffic through your firewall and tell your security operations team to expect it. See Configure firewall access.
5. Review the scope XBOW suggests. Set the third-party domains your asset depends on to Allow Visit so XBOW can load the domains without attacking them. See Defining the scope.
6. Protect sensitive endpoints, such as account deletion and payment processing. See Controlling access to sensitive endpoints.
7. Ask your operations team to monitor the asset during the run. See Monitoring performance.
8. Keep the environment stable while the assessment runs. Redeploying the asset or changing the test account can pause the assessment.
9. Know how to stop the assessment. You can pause or cancel an assessment at any time from the assessment dashboard. See Assessment running.

After the first assessment, review how your asset behaved and adjust the settings for the next one.

Exclude part of your asset from testing

The exclusion list from the Priorities card is applied on a best-effort basis. XBOW deprioritizes the excluded areas but cannot guarantee it never touches them if it reaches them through another test path. If something must never be tested, set the domain to Blocked or Allow Visit, or the endpoint to Blocked or Auth-only. See Scope configuration and Protected URLs.

Write effective safety guidance

Safety guidance tells XBOW how to keep your asset safe. XBOW extracts the guidance from the text and files you add to the Assessment guidance cards. Attack agents receive each safety item as a constraint, and XBOW checks every command against the items before it runs. A model makes that check as a judgment, not a keyword match, so it can miss cases.

Safety guidance can only add restrictions. It cannot widen your scope. Changes to guidance apply to assessments you start afterward, not to an assessment that is already running.

To get the result you want:

• Do not rely on guidance for hard limits. Use a control that enforces the limit, as described in Exclude part of your asset from testing.
• Be specific. Write rules that name an action or an endpoint, such as “Do not use the /admin endpoint” or “Do not transfer funds out of the account”. Vague wording such as “Be careful with payments” is unlikely to block anything.
• Include only what you need. Every item limits testing, so unnecessary restrictions reduce coverage.
• Review the extracted items. After you click Analyze, check the safety guidance listed on each card. Delete any item you do not want, then click Save to keep your changes. The combined list of guidance from all cards appears after you save. You cannot edit an item. To change one, edit your input and analyze it again.

For the guidance cards and what each one does, see Guiding XBOW testing for experts.

Related content

To apply the configuration decisions you have made, see Protecting assets during XBOW testing.

To learn more about XBOW’s safety measures, see Trusting XBOW to assess your asset.