> For the complete documentation index, see [llms.txt](https://help.aikido.dev/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.aikido.dev/pentests/prepare-a-pentest/why-use-a-testing-environment.md). # Why Use a Testing Environment Why Aikido asks you to run pentests on a testing environment, and why some tests can change or delete data. You may have seen a warning to run this on a testing environment, because some tests can change or delete data. That sounds worse than what usually happens. This page explains what Aikido's agents actually do, when a test can change data, and why we still ask you to run it on a testing environment. ## What "change or delete data" really means It doesn't mean Aikido will wipe your production database or take your site down on purpose. It means that to prove some bugs are real, an agent sometimes has to do something that **changes** a file, a record, or a setting. That's uncommon. Most proofs never need it, but in a worst case this can bring your environment down and you need to be aware of this risk. The easiest way to avoid problems is to run the pentest on a testing environment. ## Do agents keep exploiting after they find something? No. Aikido Pentest agents are built to **prove a finding, then stop**. By default they don't keep exploiting, dump your database, or see how far they can go. If you later want a deeper follow-up on a specific finding and exploit it further, that's opt-in with a [human in the loop](/pentests/coverage-and-findings/human-in-the-loop.md). It's not part of the default run. To use **Exploit Further** without worrying, get the testing environment right from the start. It runs against the same target you scoped, so switching later means starting a new assessment and setting everything up again. ## Can most findings be proven in a harmless way? Yes. For most vulnerabilities, proof looks like a harmless signal that the app did something unexpected, not damage. * **Cross-site scripting (XSS):** inject something like a `console.log`, not a script that steals sessions. * **SQL injection:** make the database pause for a few seconds (`SLEEP`), not `DROP TABLE`. * **Broken access control:** read another *test* user's record to prove the ID check is missing, not delete a real customer. ## When is the only proof a real action? A few bugs can't be confirmed without doing the dangerous thing. A common example is **path traversal** that lets someone delete a file. There may be no "read this file" option. Deleting a test file can be the only way to know the bug is real. **That's the actual risk.** On a testing environment you lose a dummy file or a fake user. On production, that same proof could delete a real file, order, or account. The same idea applies to some access-control bugs that only show up on a delete or update endpoint: the agent may need to change or remove a *test* record to prove the check is missing. ## Do agents clean up after themselves? They try. Agents create throwaway test data (users, files, records) and **try to remove it** when they're done. Cleanup isn't always possible. There may be no delete endpoint, permissions may have changed mid-run, or the app isn't avialable anymore. That's another reason to use dummy data in a testing environment. Leftover test users or files on a staging app are annoying. Leftover test users on a live app with real customers are a problem. ## What does a good testing environment look like? Use a testing environment you can afford to mess up: * A **staging, QA, or preview** URL, not the live app real people use * **Dummy data only** (no real customer PII) * A preview URL isn't enough if it still uses your production database or live keys * Close enough to production that findings still matter (same features, same auth) For the full preflight checklist, see [Preparing for a Pentest](/pentests/prepare-a-pentest/preparing-for-a-pentest.md). ## Bottom line Run the pentest on a testing environment that mirrors production, with dummy data instead of real customers. You'll get findings that still matter, without putting real users or real data at risk. **Not sure?** If you need help picking a safe target URL, open the **Intercom chat** in the bottom right corner. Our team is here to help! --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://help.aikido.dev/pentests/prepare-a-pentest/why-use-a-testing-environment.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.