# Is AI pentesting safe? Our limits and stop rules

Source: https://aipentestservices.com/safety/
Publisher: Excession Labs (aipentestservices.com)
Last updated: 2026-11-09

Is AI pentesting safe? How our tests stay inside scope: allow, ask and deny tool rules, test-owned data, bounded tests, stop conditions and production limits.

> **Short answer:** An AI-assisted pentest is safe to the degree that its limits are written and enforced. Excession Labs works only inside a written scope with owner authorization. Tool rules allow, ask or deny each action. Destructive proofs use test-owned data. Costly tests are bounded and the cost is stated. We do not promise zero risk.

An AI-assisted pentest is safe only inside limits that are written down and enforced. Below are our limits, what we will not do and what you do on your side. No test has zero risk, and we do not promise it.

## How does the scope keep testing in bounds?

The written scope is the first limit. Excession Labs writes it with you, and the system owner authorizes it in writing before any test runs. We test only with that authorization.

The scope names:

- hosts, API base paths and environments in scope
- roles and the test accounts for each
- areas and actions that are out of scope
- bounded tests and their cost limits
- a stop contact and how to reach them

Anything not in the scope is out of scope. The operator sets the tool rules from the scope, so a request to an unlisted host is blocked.

## What do the allow, ask and deny rules do?

Every tool the agent can call has one of three rules, and these keep the agent inside the scope while it works fast.

| Rule | Behavior | Typical example |
|---|---|---|
| Allow | Runs on its own | Read-only requests to in-scope hosts |
| Ask | Waits for approval from the operator | A state-changing request, or a test with a cost |
| Deny | Blocked | Any host outside the scope, or an action the scope forbids |

The operator sets the rules. People set the limits and approve the "ask" actions, so Incursion does not run without human control. The guide on [human in the loop pentesting](/guides/human-in-the-loop-pentesting/) gives the reasoning.

## How does the test avoid damaging real data?

Destructive proofs use test-owned data only. When a finding needs a write, a delete or a state change to prove it, we do it on accounts and records that were created for the test and are marked as test data. We never change a real customer's record to prove an issue.

We prove a write by reading the changed record back through another session. That needs a second test account, so request one during access setup.

Reproduction scripts in the report are read-only where possible. They must be run only with authorization and test-owned identifiers.

## Which tests are bounded, and how is the cost stated?

Some tests can cost money or affect others. We bound them in advance and state the cost in the report:

- file uploads (size and number limits)
- password guessing (attempt limits, test accounts only)
- email sending (recipient and count limits, test inboxes only)
- calls to paid third-party APIs (a stated call limit)

The scope sets each bound. If a test would go past it, the tool rule is "ask" and the operator decides. The report lists what ran and what it cost.

## When does testing stop?

We stop on these conditions:

1. You ask us to stop, through the stop contact.
2. A tool rule blocks an action and the operator does not approve it.
3. A test would go past a bound in the scope.
4. We see signs that the system is degrading, for example errors or slow responses that follow our requests.
5. We find something that needs urgent attention. We agree in the scope how to tell you before the report.

After a stop, we agree with you whether and how to continue.

## Production or staging?

Staging with test accounts carries the lower risk and is a good first choice. Production can be in scope when the written scope says so. If you choose production, expect stricter "ask" rules for state-changing actions, tighter request rates, a named contact who is available during the test, and a smaller set of bounded tests. [Is AI pentesting safe in production](/guides/is-ai-pentesting-safe-in-production/) goes into more depth.

## What will we not do?

- Test without written authorization from the system owner.
- Test hosts, accounts or data that are not in the scope.
- Use real customer records to prove a destructive effect.
- Run social engineering, phishing or physical tests in this service.
- Claim that a system is secure after testing, or that the test found all vulnerabilities.

## What should you tell your team?

Before the test, tell the people who may see the traffic:

1. The test window and the environment.
2. The test accounts and their names, so that support does not treat them as customers.
3. That your monitoring may alert. Decide if you want alerts suppressed or watched.
4. The stop contact on your side and ours.
5. Who owns the fixes when the report arrives.

[How it works](/how-it-works/) lists each step. [Incursion](/incursion/) is the agent that runs the tasks. [Pricing](/pricing/) lists the choices that change the quote.

## Questions

### Can the agent change or delete my real data?

Destructive proofs use only test-owned accounts and records, marked as test data. The tool rules can also block or hold a risky action for approval. We cannot promise that no test ever has a side effect, so we agree limits and a stop contact in the scope.

### Can I stop a test while it runs?

Yes. Name a stop contact during access setup. When you ask us to stop, we stop the testing. Agree how you reach us before the test starts.

### Should I test production or staging?

Staging with test accounts is the lower-risk first choice. Production can be in scope if the written scope says so and your team accepts the limits. The scope states which environment is tested.

### What should I tell my own team?

Tell operations, support and your security monitoring team the test window, the source of the traffic and the stop contact. This avoids a false incident response.