FAQ
What pages and endpoints does it test?
The agents test whatever is reachable inside your scope. A crawling agent walks the application, follows links, submits forms, and records each endpoint and parameter it discovers. The crawl respects your excluded paths. Anything outside your target URLs (and any allowed domains you add) is unreachable from the sandbox.
Which vulnerability categories does it cover?
The testing stage covers OWASP Top 10 categories: injection, broken authentication, sensitive data exposure, cross-site scripting, server-side request forgery, and more. The agents also reason about the application's specific logic to find issues a scanner would miss.
How do I protect staging or production?
Three controls protect the environment:
- Rate limiting: set a requests-per-second cap so the agents do not overwhelm the target.
- Excluded paths: list URL paths to skip, to shield sensitive endpoints and avoid destructive actions.
- Scope boundaries: the sandbox can reach only your target URLs and allowed domains, so the test stays where you intend it.
Do I need to give credentials?
No. Authentication is optional. Without test users the agents test only what is reachable anonymously. To reach authenticated areas, add test users with a role, a username and a password, and an authenticator secret key for an account that uses two-factor authentication. The agents sign in through your login form with them. See Test users and login instructions. Use dedicated test accounts rather than real ones.
Will it test my internal services?
No. The sandbox reaches only the target URLs you provide plus any allowed domains you configure. It cannot reach internal services or any host outside your allowlist.
Does it follow redirects to outside domains?
No. If the agent meets a redirect to a domain outside your configured scope, it does not follow it. This keeps the test in bounds even when your application links to external services.
Does it have access to my source code?
No. A black-box pentest works without your source code. It probes your live application over HTTP and through a headless browser, and it never receives or inspects your source code. If you want source-level analysis, use Source Code Audit.
Is my target safe from accidental damage?
The agents operate inside isolated sandboxes that are destroyed when the run ends. The crawl respects excluded paths and rate limits, and the sandbox cannot reach anything outside your scope. No artifacts, including credentials or session tokens, persist after the assessment.
What happens if my target is down or unreachable?
When you press Start, AISafe requests each target URL before it takes any payment. If a target does not answer, the run does not start, you see a message that names the target, and you are not charged. See The check before you are charged.
What does a finding look like?
Each confirmed finding carries a proof-of-concept with the exact HTTP request and the response that proves exploitation, reproduction steps, an impact assessment, and a suggested fix. Findings map to a standard category (CWE or OWASP) where applicable, carry a severity, and move through a status lifecycle you control.
Who decides what is a real vulnerability?
Before triage, AISafe merges candidates whose evidence establishes the same root cause at the same place. In a scan with validator-confirmed live proofs, repeated proofs of the same weakness at the same input and delivery site become one candidate even when different tests found them. A triage agent then re-examines each candidate's evidence, confirms or rejects it, and assigns a confidence score. You make the final decision: from the dashboard you can confirm a finding, mark it a false positive, accept the risk, mark it a duplicate, or mark it fixed. See Triage.
What happens to the sandbox after the run?
The platform destroys the sandbox when the assessment completes (or times out). No state persists between assessments. See Sandbox isolation.