# About AI Pentest Services Source: https://aipentestservices.com/about/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 AI Pentest Services is run by Excession Labs, a security lab that runs authorized tests of web apps and APIs with AI testing agents and publishes lab research. AI Pentest Services is a service of Excession Labs. Excession Labs is a security lab. It runs authorized security tests and publishes lab research. The lab's AI testing agents do part of the testing, and [how it works](/how-it-works/) describes the sequence. ## How we work The lab runs the agents itself, so it sees where they work well and where they need a person. The service has one rule above the others: a finding counts only when it links to proof. The lab's AI testing agents run test tasks in parallel across roles, endpoints and tenants, under tool rules Excession Labs sets for your scope. An agent may only report a finding that links to evidence. Excession Labs agrees the scope with you, checks the evidence for each finding and writes the report. Read [how it works](/how-it-works/) for the sequence. We do not: - Test without written authorization from the system owner. - Present an unproven result as a finding. - Claim that an AI agent finds every vulnerability or that a tested application is secure. - Name a customer without permission. ## Our security sites and contact Email [support@excessionlabs.ai](mailto:support@excessionlabs.ai), follow [@ExcessionLabs on X](https://x.com/ExcessionLabs) or visit [excessionlabs.ai](https://excessionlabs.ai/). --- # AI pentesting for SaaS: multi-tenant testing with evidence Source: https://aipentestservices.com/ai-pentesting-for-saas/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 AI pentesting for SaaS: what the lab's agents test in a multi-tenant product, how the two-tenant method proves cross-tenant findings, and what you receive. > **Short answer:** AI pentesting for SaaS means the lab's AI agents test a multi-tenant product role by role and tenant by tenant. They cover tenants, roles, invitations, billing, exports, admin paths and releases. A cross-tenant finding counts only when it is read back from a second tenant's session. Excession Labs checks the evidence and writes the report. AI pentesting for SaaS is a scoped test of a multi-tenant product, run by the lab's AI testing agents under rules that Excession Labs sets. The agents work through each role and each tenant in parallel. Excession Labs checks the evidence for each finding and writes the report. A SaaS product serves many customers from one system, so the worst bug is one customer reaching another customer's data. A scanner with one login rarely finds that. The test needs several accounts, in several tenants, compared against each other. ## What does AI-assisted testing cover in a multi-tenant SaaS? It covers the places where a tenant boundary or a role rule can fail. We scope the areas below with you. The first column is what the agents check, and the second is the method. | Area | What the agents check | Method | |---|---|---| | Tenants | Can tenant A read or change tenant B's records by changing an identifier? | Replay A's requests with B's IDs, and the reverse | | Roles | Can a member call admin functions? Can a viewer write? | Same request, one session per role | | Invitations and membership | Can an invite be reused, redirected or accepted into the wrong tenant? | Create invites in each tenant and cross the tokens | | Billing and entitlements | Can a lower plan reach a paid feature by calling the API directly? | Compare UI limits with API behavior | | Exports and files | Does an export or download resolve a record by ID alone? | Request another tenant's report ID, read back the file | | Admin and support paths | Can an ordinary user reach internal routes or flags? | Differential comparison of anonymous and signed-in callers | | Integrations | Do API keys, webhooks and OAuth apps stay inside their tenant? | Use one tenant's key against the other tenant | | Releases | Did the last release open a new path? | Scope the delta, then retest earlier findings | The categories follow public guidance. The [OWASP Multi Tenant Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html) describes tenant isolation as a design requirement. [API1:2023](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/) covers object-level access, and [API5:2023](https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/) covers function-level access. OWASP's [privilege escalation test](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/05-Authorization_Testing/03-Testing_for_Privilege_Escalation) is the manual version of the role checks. ## How does the two-tenant method prove a cross-tenant finding? It proves the effect by reading the record back from the other tenant's session. You create two tenants with at least two roles each. The agents create test objects in each tenant, then replay in-scope requests from tenant A with tenant B's identifiers, once for every role. A "success" response is not proof. A write counts when the changed record shows up through another session. A read counts when the response holds rows that belong to the other tenant. Controls run next to each exploit request: a nonexistent identifier, a wrong record type, another account's token, and an anonymous call. If a control shows the first result was misleading, we downgrade or drop the finding. Controls that held are listed in the report, so a later fix does not break a protection that works. > **Sample check:** This is a demonstration. It uses a fictional app, Harbor Notes Teams, and no real customer system was tested. > > Tenant `t_acme` has an admin and a member. Tenant `t_globex` has the same. The agent asks for an export with a report ID that belongs to `t_globex`, using the acme member's session. > > ```http > POST /api/exports HTTP/1.1 > Host: app.example.com > Cookie: session= > Content-Type: application/json > > {"report_id":"rpt_55120"} > ``` > > The control, report `rpt_00000`, returns 404. If the export of `rpt_55120` returns `202` and the downloaded file holds `t_globex` rows, the finding is Observed, read back with the acme session. If the file is empty or the request is refused, the control held and the report lists it that way. For the full test matrix, see the guide on [multi-tenant isolation testing](https://penetrationtestservices.com/guides/multi-tenant-isolation-testing/) and the [tenant isolation testing](https://penetrationtestservices.com/tenant-isolation-testing/) page on penetrationtestservices.com, which is also run by Excession Labs. ## What does the AI part do, and what does a person do? The agents split the engagement into tasks and run them in parallel, one set per role in scope. Each tool they use is set to run on its own, wait for approval, or stay blocked. An agent may report a finding only if it links to evidence: the requests, the responses and the controls. Excession Labs agrees the scope with you in writing, checks the evidence for each finding, and writes the report. The agents do not decide what is a finding. The [how it works](/how-it-works/) page lists the nine steps, and the [safety page](/safety/) covers the limits. The agents do not find everything. Business-logic flaws that depend on how your customers use the product are the weakest area, and the page on [where AI pentesting falls short](/guides/where-ai-pentesting-falls-short/) lists others. Say in the scoping call which flows carry the most money or data, so the scope puts effort there. ## What do you receive? You receive a written report in HTML, PDF and Markdown, plus proof-of-concept scripts. It has these parts: 1. Project details: scope, assets and the severity scale (Critical, High, Medium, Low, each defined) 2. Executive summary with priority actions 3. Findings at a glance 4. One section per finding: description, impact, verified results, reproduction and remediation 5. Controls that held 6. Remediation plan 7. Limitations and open questions 8. Evidence index, with saved requests and responses Findings carry an evidence label. "Observed" means we reproduced it. "Browser-observed" means we showed it in a real browser. Inferred paths are labeled separately, and open questions stay out of confirmed impact. The [example assessment](/example-assessment/) shows the layout with a labeled demonstration. We can retest fixed findings. Whether a retest is part of a quote is agreed during scoping. ## How do you start? Start with a short call, then a written scope and proposal. We test only with written authorization from the system owner. Prices are quoted after scoping, and we publish no price list. The [pricing page](/pricing/) lists what changes a quote. Before the call, collect these: - the environment to test, staging or production - two tenants for the test, with at least two roles in each - the role matrix and the features behind each plan - a list of what changed since the last test, if you ship often (see [per-release testing](/per-release-testing/)) - how you will pass test credentials to us The [authenticated web app testing](/authenticated-web-app-testing/) page covers accounts, sessions and MFA in more detail. If you want a small first test, [apply for a pilot](/pilot/). Pilot places are limited and reviewed by hand. ## Questions ### Do I need two tenants for the test? Yes, for a multi-tenant product. Create two tenants for the test, with at least two roles in each. Without a second tenant, a cross-tenant read cannot be proven, and the report would have to label that path as inferred. ### Can the agents test with our real customer data? No. Tests use test-owned accounts and records that are marked as test data. Staging with data that is not real is the usual choice. If production is in scope, the written scope says so and tighter limits apply. ### Is this the same as a SaaS compliance pentest? The testing method is the same, but the report is not an attestation. Ask your auditor or customer what they need. We do not claim that any auditor will accept a report. ### What if we ship every week? Scope the areas that changed. The per-release page explains how a scope delta works. We do not promise continuous or scheduled testing. ## Sources - [OWASP Multi Tenant Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Multi_Tenant_Security_Cheat_Sheet.html) - [OWASP API Security Top 10 2023: API1 Broken Object Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/) - [OWASP API Security Top 10 2023: API5 Broken Function Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/) - [OWASP Web Security Testing Guide v4.2: Testing for Privilege Escalation](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/05-Authorization_Testing/03-Testing_for_Privilege_Escalation) --- # AI vs manual pentesting: what each does best Source: https://aipentestservices.com/ai-vs-manual-pentesting/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 AI vs manual pentesting in one table: which task types suit an agent, which need human judgment, and how Excession Labs combines both in one test. > **Short answer:** Excession's model is AI-assisted testing. the lab's AI testing agents do the testing work under tool rules. Excession Labs agrees the scope, checks the evidence for each finding and writes the report. An agent is strong at breadth, repetition, role comparison and retesting. People are needed for business context, novel chains, risk acceptance and scoping. Excession Labs delivers AI-assisted testing. Our AI testing agents run test tasks in parallel under tool rules that you can see. Excession Labs agrees the scope with you in writing, checks the evidence for each finding, and writes the report. This page describes our own delivery model. For a neutral comparison of providers, read the [AI vs human pentesting guide on pentestcompare.com](https://pentestcompare.com/guides/ai-vs-human-pentesting/). Excession Labs publishes that guide, and the guide says so. ## How does AI-assisted testing work here? AI-assisted means an agent does the repetitive, wide testing work, and people keep control of scope, approvals and the final report. Three points define it. - People set the limits. The scope is written, the owner authorizes it, and the operator sets which tools run on their own (allow), wait for approval (ask) or are blocked (deny). - The agent works in parallel. A coordinator splits the job into tasks, and several workers run them at the same time. - Evidence decides. A task is done only when each finding links to its evidence, and Excession Labs checks that evidence before it goes in the report. [How it works](/how-it-works/) gives the full sequence. In practice we use the agent for volume and people for judgment, in three steps. 1. Excession Labs holds the scoping call and writes the scope. You may share your access model, so that "should this role see this?" has a stated answer. 2. The agents plan and run the tasks under the tool rules. They save each request and response with a timestamp. 3. Excession Labs checks the evidence for each finding and writes the report. A weak finding is removed or labeled as inferred at this step. A scanner reports possible issues from signatures. The agent must show a real effect, such as a record changed and read back through another session. [AI pentest agents vs DAST scanners](/guides/ai-pentest-agents-vs-dast-scanners/) explains the difference. ## Which task types suit an agent and which need a person? This table covers task types and does not rate any provider. | Task type | Agent strength | Where human judgment is needed | |---|---|---| | Broad coverage of many endpoints | Strong. It tries the same checks on every route without tiring. | Deciding which routes matter most to your business. | | Repeated checks (headers, session handling, input handling) | Strong. Repetition is cheap. | Reading edge cases that do not fit the pattern. | | Differential checks across roles | Strong. It replays the same request as anonymous, user, admin and a second account, and compares results. | Deciding what each role should be allowed to do. You supply the intended access model. | | Cross-account authorization (IDOR-style) | Strong when two test accounts exist: it reads back the changed record from another session. | Judging whether a shared record is meant to be shared. | | Retesting fixed findings | Strong. The original request is replayed and the control checks run again. | Confirming that the fix matches the intended design. | | Reading client-side JavaScript for routes and keys | Good for finding candidates fast. | Judging which candidates are real exposure. | | Business-logic flaws (price, quota, workflow order) | Limited. It needs your rules explained. | Needed. A person must know what "wrong" means for your business. | | Novel multi-step chains | Limited. It can combine known steps. A new chain needs creative judgment. | Needed. | | Severity and risk acceptance | Can propose. | Needed. Your team decides what risk to accept. | | Scoping and authorization | Not the agent's job. | Needed. The owner authorizes in writing. | | Social engineering, phishing, physical access | Out of scope for this service. | Not offered here. | [Where AI pentesting falls short](/guides/where-ai-pentesting-falls-short/) covers the limits in more detail. ## When should you ask for more human involvement? Ask for more human review when your main risk sits in business rules. Three situations call for it. - The app handles money movement, approvals or entitlements with custom rules. - Your main fear is a sequence of valid actions used in an unexpected order. - A regulator or customer asks for a specific named method. Tell us in the scoping call. The written scope states what the test covers and what it does not. We do not claim that the test finds all vulnerabilities, and we do not claim that your system is secure afterward. An agent gives you breadth and repeatable retests. Your team knows what the application is for, so give us the intended rules for each role, and read the "Limitations and open questions" section of the report. The [free pentest pilot](/pilot/) lets you see the work first, on a small written scope. [Pricing](/pricing/) lists what moves the cost. [Safety](/safety/) sets out the limits on the agent. [How it works](/how-it-works/) describes the agents and the sequence. [Human in the loop pentesting](/guides/human-in-the-loop-pentesting/) covers the review idea in more depth. ## Questions ### Is an AI-assisted pentest fully automated? No. People agree the scope in writing, set the tool rules and approve actions that need approval. Excession Labs checks the evidence for each finding and writes the report. The agent does the testing work in between. ### Does AI find everything a human tester finds? No, and we do not claim that. Some issues need business context or a creative chain across several features. Those need human judgment. Read what the agent cannot do before you decide. ### Should I choose AI-assisted or manual testing? Match the test to the question. Broad coverage of many roles and endpoints, with retests, fits an agent well. A question about your business rules, risk appetite or social engineering needs people. Some programs use both. ### Where can I compare AI pentest vendors? Use the neutral guide on pentestcompare.com. It is published by Excession Labs and discloses that. This page covers how we deliver. --- # Authenticated web app testing with AI agents Source: https://aipentestservices.com/authenticated-web-app-testing/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 Authenticated web application penetration testing with AI agents: test accounts per role, session handling, SSO and MFA options, scope limits and evidence. > **Short answer:** Authenticated web application penetration testing tests the parts of an app behind login. The lab's AI agents sign in with test accounts, one per role, and compare what each role can reach. You choose how sessions, SSO and MFA are handled. Real user accounts stay out of scope. Each finding links to saved requests and responses. Authenticated web application penetration testing tests the parts of your app that sit behind login. The lab's AI testing agents sign in with test accounts, one per role, and compare what each role can see and do. Excession Labs checks the evidence for each finding and writes the report. An unauthenticated test reaches the login page and the public site. Most records, settings, payments and admin tools are behind login, so authorization bugs show up only when the caller is signed in. ## What does an authenticated test cover? It covers every function that checks who the caller is. The agents run the same request as several roles and as an anonymous caller, then compare the results. | Area | Question | Check | |---|---|---| | Object access | Can user A read or change user B's record? | Replay A's request with B's identifier, read back from B's session | | Function access | Can a low-privilege role call an admin function? | Call the admin route directly with the low-privilege session | | Session handling | Does logout end the session? Is a token reusable after logout? | Replay a token after logout | | State-changing requests | Is a request accepted without a valid anti-CSRF token? | Browser-observed check in Chromium | | Client-side code | Do the JavaScript bundles expose routes or keys the UI hides? | Review of the bundles, then request the routes | | Tenant boundaries | Can one tenant reach another tenant's data? | Two-tenant method, see [AI pentesting for SaaS](/ai-pentesting-for-saas/) | [OWASP API1:2023](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/) and the OWASP [privilege escalation test](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/05-Authorization_Testing/03-Testing_for_Privilege_Escalation) describe the same ideas for manual testers. ## Which test accounts do you need for each role? You need one account for each role, and a second account in any role that holds data. The second account is what proves one user can reach another user's records. Create the accounts for the test and mark them as test data. | Account | Purpose | |---|---| | Admin | Baseline for restricted functions | | Standard user A | Owns test records | | Standard user B, same role as A | Target of cross-account reads | | Read-only or low-privilege user | Function-level limits | | User C in a second tenant | Tenant isolation, if the app has tenants | | Anonymous | Baseline for every request | Give each account some test data, or a cross-account read has nothing to read. We write the accounts and roles into the scope. ## How do sessions work during the test? Each account keeps its own session, and the agents renew it when it ends. A mix-up between sessions would ruin the comparison. If a response returns a login page with a `200` status, the agent treats the session as lost, writes it in the run log, and does not report it as a finding. Tell us three things: how to sign in, what carries the session (a cookie, a bearer token or a header), and how long it lives. The [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) is the reference for expiry and logout behavior. Logout, token reuse after logout and cookie flags are valid tests, so the scope can include them. The [signed-in flows guide](/guides/testing-signed-in-flows-with-ai-agents/) walks through session handling step by step. ## What are the SSO and MFA options? You pick one option per environment, and the scope records it. OWASP calls MFA a critical control, so we do not ask you to turn it off for real users. | Option | Use when | Limit | |---|---|---| | Test account with a TOTP seed shared with the tester | Staging or production with MFA on | Store the seed in a secrets manager and rotate it afterward | | MFA waived for named test accounts in staging | The MFA flow is not in scope | The test does not cover MFA, and the report says so | | Pre-issued session or token per account | SSO or passkeys block automation | The login path stays untested | | Test identity provider tenant | The app uses SAML or OIDC | The setup must match production | If login, MFA or password reset is in scope, test it on purpose with accounts you control. The [OWASP Multifactor Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html) lists what to check. ## What stays out of scope? Real users' accounts, real customer data and anything the system owner has not authorized in writing stay out. We test only with written authorization from the system owner. Destructive proofs use test-owned accounts and records only. Some actions need approval or are bounded, and their cost goes in the report: uploads, password guessing, email sending and paid third-party APIs. If something outside the scope looks relevant, we stop and ask. The agents' tool rules (run on its own, wait for approval, blocked) are set per scope. See the [safety page](/safety/). Credentials need care too. Pass them through a secrets manager or an encrypted channel, not through chat or tickets. Replace session values with placeholders in saved evidence, and disable the accounts when the test ends. ## What evidence do you get? Each finding comes with saved requests and responses, timestamps and the controls that were run next to it. Key evidence can carry a SHA-256 manifest. A finding is "Observed" when we reproduced it and "Browser-observed" when it was shown in a real browser. A worked example: the agent signs in as user A and as user B in the same role. It requests B's record with A's session, and then reads it from B's session to see what changed. A control, such as a nonexistent record ID, runs alongside. The report holds the pair, the result and the fix guidance. The report also lists controls that held, so you know which protections work. The [example assessment](/example-assessment/) shows the report layout. ## How do you start? Start with a short call, then a written scope and proposal. Prices are quoted after scoping. Send us the role list, the environment and your SSO and MFA setup before the call. For a small first test, [apply for a pilot](/pilot/). Places are limited and reviewed by hand. ## Questions ### Do you need our admin credentials? We need an admin test account if admin functions are in scope. Create it for the test, give it the admin role only, and disable it afterward. A real administrator's login stays out of the test. ### Can you test if we require MFA? Yes. The scope states which option you chose: a test account with a second factor the tester can use, a staging waiver for named test accounts, or a pre-issued session. The report says if the MFA flow itself was not tested. ### Does it cover SSO login? It can. A separate test identity provider tenant with test users is the closest match to production. Say in scoping whether the SSO login flow is in scope or only the app behind it. ### Is an authenticated test also a test of anonymous access? Both are run. Every request is compared across anonymous and signed-in callers, so the report shows what login protects and what it does not. ## Sources - [OWASP Web Security Testing Guide v4.2: Testing for Privilege Escalation](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/05-Authorization_Testing/03-Testing_for_Privilege_Escalation) - [OWASP Multifactor Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html) - [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html) - [OWASP API Security Top 10 2023: API1 Broken Object Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/) --- # Contact us about AI-assisted pentesting Source: https://aipentestservices.com/contact/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 Contact AI Pentest Services about AI-assisted penetration testing of your web application or API. We reply by email to agree scope, access and a test window. Tell us about the application and what you need. We reply by email from support@excessionlabs.ai. [Use the form on this page](https://aipentestservices.com/contact/) Prefer email? Write to [support@excessionlabs.ai](mailto:support@excessionlabs.ai). Never send passwords, API keys or customer data by email or through this form. --- # Developers and AI agents Source: https://aipentestservices.com/developers/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 Machine-readable access to aipentestservices.com: OpenAPI description, API catalog, Markdown versions of every page, llms.txt and the rules for AI agents. Everything on aipentestservices.com is public and readable by software. Reading needs no account and no key. | What | Where | |---|---| | API description (OpenAPI 3.1) | [/openapi.json](/openapi.json) | | API catalog (RFC 9727) | [/.well-known/api-catalog](/.well-known/api-catalog) | | Rules for AI agents | [/auth.md](/auth.md) | | Site index for language models | [/llms.txt](/llms.txt), full text in [/llms-full.txt](/llms-full.txt) | | Markdown version of any page | add `index.md` to the page URL, or send `Accept: text/markdown` | | Sitemap and feed | [/sitemap.xml](/sitemap.xml), [/feed.xml](/feed.xml) | | Service status | [/api/health](/api/health) | ## Sending an enquiry `POST /api/enquiry` stores an enquiry and notifies Excession Labs. It needs a Cloudflare Turnstile token, which only a person completing the form on the site can produce. An agent helping someone get in touch should give them [the form](/pilot/) or the address [support@excessionlabs.ai](mailto:support@excessionlabs.ai). The field list for each form is in the OpenAPI description. ## Fair use Read and cite freely. Keep request rates reasonable; the enquiry endpoint is rate limited. Do not try to bypass the human verification. Questions: [support@excessionlabs.ai](mailto:support@excessionlabs.ai). --- # AI pentest example: a worked assessment of a demo e-commerce API Source: https://aipentestservices.com/example-assessment/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 AI pentest example on a fictional API: the written brief, tool rules, coordinator and workers, one validated finding, one rejected false positive and a retest. > **Short answer:** One AI-assisted assessment of a fictional e-commerce API, from the written brief to the retest. It includes the written brief, the allow, ask and deny tool rules, the coordinator and workers, one finding proven by read-back from a second account, one candidate rejected after a control, the human review, and the report excerpt with its retest. > **Demonstration:** This is a demonstration based on a fictional application. No real customer system was tested. > Pinecart, its host `api.pinecart.example`, its accounts and its data are invented. All transcripts, timestamps and identifiers are illustrative. They show the shape of the work, not the output of a real engagement. This page is the sample report for our AI penetration testing services. An AI-assisted pentest is an authorized security assessment where an agent does much of the testing work under rules the system owner approves. This example follows the process in [how AI pentesting works](/how-it-works/) on an invented target, from the first brief to the final report. Excession Labs is a security lab. In the delivery model described here, its AI testing agents run test tasks in parallel under the tool rules Excession Labs sets for the scope. An agent may only report a finding that links to evidence. Excession Labs agrees the scope with you in writing, checks the evidence for each finding, and writes the report. ## The brief and the tool rules Pinecart is a small e-commerce SaaS. Merchants run online shops on it. Shoppers place orders through a public API. The Pinecart team wanted to know if one shopper could read another shopper's data before a large customer's security review. The system owner approved this written scope. | Item | Agreed value | |---|---| | Target | `https://api.pinecart.example` (production-like test environment) | | Out of scope | The marketing site, the payment processor, email delivery systems, and any other host | | Test type | Black-box web and API assessment, then grey-box with two test accounts | | Accounts | Two shopper accounts that Pinecart created for the test: `shopper-a@example.com` and `shopper-b@example.com` | | Test data | Orders created during the test carry the note `EXCESSION TEST DATA` | | Authorization | Signed by the Pinecart owner before any request was sent | | Contacts | A Pinecart engineer reachable during the test, and a written stop contact | | Stop conditions | Any sign of customer impact, any real person's data, or an unexpected error rate | The brief also lists Pinecart's worries. The coordinator turned them into tasks: 1. Can a signed-in shopper read or change another shopper's orders or profile? 2. Can an anonymous caller reach any signed-in endpoint? 3. Are session tokens and password reset safe against simple abuse? 4. Do the search and filter parameters accept input that changes the query? 5. Does the API leak internal details in errors? The [safety page](/safety/) lists the general rules. Each tool has one of three rules. A tool with the allow rule runs on its own. A tool with the ask rule waits for a human to approve each use. A tool with the deny rule is blocked. The operator sets the rules before the run. For Pinecart, the rules were these. | Tool or action | Rule | Reason | |---|---|---| | Read-only HTTP requests (GET, HEAD, OPTIONS) to the target host | Allow | Low risk. Needed for mapping and differential tests. | | Reading the API documentation and client-side JavaScript | Allow | Public material. No effect on the target. | | Creating an order or editing a profile with a test account | Ask | Changes state. The human checks the record is marked as test data. | | Deleting any record | Ask | Not needed except to clean up test-owned data. | | Requests that send email or SMS | Ask | Real messages cost money and reach real inboxes. | | Password guessing and credential stuffing | Deny | Not in scope. Account lockout could affect real users. | | High-rate requests and load generation | Deny | Could harm availability. | | Any host other than `api.pinecart.example` | Deny | Out of scope. | | Writing files outside the engagement folder | Deny | Keeps evidence and the host clean. | A bounded test is possible under the ask rule. For example, a rate-limit check can send a small, fixed number of requests after a human approves the number. The report states that number. ## The run: coordinator, workers and status The coordinator is the planner. It reads the brief, splits the work into tasks and hands each task to a worker. Workers run in parallel. Each worker keeps its own notes and findings. For Pinecart the coordinator made four tasks. | Worker | Assignment | Status | Latest action | |---|---|---|---| | W1 Mapper | Map endpoints from the API docs and the JavaScript bundle. Record which need a token. | Done | Listed 41 endpoints. Flagged 6 that take an object ID in the path. | | W2 Access control | Compare anonymous, shopper A and shopper B on every endpoint with an object ID. | Done | Proposed 2 candidates: C-01 and C-02. | | W3 Sessions | Check token format, expiry, logout and password reset. | Running | Waiting for approval to request one reset email to a test inbox. | | W4 Input handling | Test search and filter parameters for injection and unsafe errors. | Running | Reviewing 9 error responses for stack traces. | The numbers in this table are invented. A task is done only when each finding links to its evidence. W2 reached that point only after the validation steps below. This fictional log excerpt shows part of the session. ```text 09:02:11 coordinator brief loaded. scope: api.pinecart.example. 5 objectives, 4 tasks. 09:02:12 coordinator rules: GET/HEAD/OPTIONS allow | POST/PUT/PATCH/DELETE ask | password guessing deny 09:02:40 W1 GET /v1/openapi.json 200 (41 paths) 09:03:05 W1 bundle app.4f1c.js: found /v1/orders/{id}, /v1/users/{id}/addresses 09:03:31 W1 task done: 6 endpoints take an object ID 09:04:02 W2 POST /v1/orders as shopper-a ASK create test order, note "EXCESSION TEST DATA" 09:04:20 operator approved (record is marked as test data) 09:04:21 W2 POST /v1/orders 201 id=48213 owner=shopper-a 09:04:48 W2 GET /v1/orders/48213 as shopper-b 200 owner=shopper-a 09:04:49 W2 candidate C-01: cross-account order read. needs controls 09:05:30 W2 GET /v1/users/me/orders?customer_id=A as shopper-b 200 09:05:31 W2 candidate C-02: filter by other customer. needs controls 09:06:10 W3 POST /v1/password-reset ASK one request, test inbox only 09:06:12 W3 waiting for operator... 09:06:44 W4 GET /v1/search?q=%27 200 (empty list, no error text) 09:07:02 coordinator W2 finding list is not closed: C-01, C-02 have no evidence links yet 09:07:03 coordinator W2 task stays open until controls and read-back are recorded ``` Order creation waited for a human because it changes state. The coordinator kept W2 open because a single 200 response is only a lead. ## How does a candidate become a finding? A candidate becomes a finding when we can show a real effect and the controls behave as expected. The method follows the [evidence standard](/how-it-works/) used across our work. A bare "success" response is not proof. Proof for a read is a record that only the other account should see, returned to the wrong account. Proof for a write is the changed record, read back through another session. Each exploit request runs next to controls. Controls are requests that should fail or return different data: - A nonexistent identifier. - A wrong record type. - A request with no token, or a token for another account. - A comparison of anonymous and signed-in callers. If the controls do not behave as expected, the candidate is not a finding. The two W2 candidates below show both outcomes. For the method in more depth, see [false positives and validation](/guides/ai-pentesting-false-positives/) and [how agents test authorization](/guides/how-ai-agents-test-authorization/). ### Candidate C-01: validated end to end C-01 claimed that a shopper can read another shopper's order by changing the number in the URL. Pinecart order IDs are sequential integers, so the next ID is easy to guess. This is the pattern OWASP lists as [API1:2023 Broken Object Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/). The worker took these steps. Each step is saved with a timestamp. 1. Shopper A created order 48213 with the note `EXCESSION TEST DATA`. The response named shopper A as owner. 2. Shopper B requested `GET /v1/orders/48213` with B's own token. 3. The response was `200` and contained A's test email and shipping address. 4. The worker ran four controls. The exploit request and response: ```http GET /v1/orders/48213 HTTP/1.1 Host: api.pinecart.example Authorization: Bearer HTTP/1.1 200 OK Content-Type: application/json {"id":48213,"owner":"shopper-a@example.com","note":"EXCESSION TEST DATA", "ship_to":"1 Test Lane, Exampleville","total_cents":4200} ``` The response names shopper A, so shopper B received A's data. The four controls then checked the result. | Control | Request | Expected | Observed | Meaning | |---|---|---|---|---| | Nonexistent ID | B reads `/v1/orders/99999999` | 404 | 404 | The API does not return 200 for every number. | | No token | Anonymous reads `/v1/orders/48213` | 401 | 401 | Authentication is enforced. The gap is authorization. | | Own record | B reads B's own order 48220 | 200 | 200, owner is B | Normal access works, so the difference is the owner field. | | Neighbor ID | B reads `/v1/orders/48214` (made by A) | 200 if the flaw is general | 200, owner is A | The flaw is not limited to one record. | The last step is the read-back from the second account. The worker asked shopper A to read order 48213 again with A's token. The note and total matched what shopper B saw. So B's response came from A's real record, not from a cached or generic reply. The evidence index for C-01 lists five saved request and response pairs, each with a timestamp. The main pairs carry a SHA-256 hash in the manifest. The coordinator then closed the C-01 part of W2, because the finding links to all of its evidence. ### Candidate C-02: rejected as a false positive C-02 looked like a second access control flaw. Shopper B called the order list with another customer's ID in a query parameter: ```http GET /v1/users/me/orders?customer_id=cus_A91 HTTP/1.1 Authorization: Bearer HTTP/1.1 200 OK {"orders":[{"id":48220,"owner":"shopper-b@example.com"}, ...]} ``` The status was 200. A scanner or a weak check would stop here and report a leak. The worker ran controls instead. | Control | Observed | Meaning | |---|---|---| | B calls the list with no `customer_id` | Same 3 orders, all owned by B | The parameter changed nothing. | | B calls the list with a nonexistent `customer_id` | Same 3 orders, all owned by B | The server ignores the parameter. | | B calls the list with `customer_id` set to B's own ID | Same 3 orders | Confirms the result depends on the token only. | | Owner field of every returned order | `shopper-b@example.com` | No record of shopper A appeared. | The 200 response returned the caller's own data. The server takes the account from the token and discards the extra parameter. No other shopper's record was exposed, so there is no access control effect to report. We did not put C-02 in the report as a finding. A finding needs evidence of a real effect, and this one has none. Reporting it would tell Pinecart's engineers to fix something that already works. It would also bury PIN-01 among noise. The report keeps the rejection in the "Controls that held" section as a short entry: the list endpoint ignores a `customer_id` parameter and scopes results by token. If a later release changes that behavior, a retest will show it. The entry also protects the fix: a developer who patches C-01 should not break this working protection. ## Human review and the report excerpt Excession Labs checks the evidence for each finding and writes the report. For this assessment, that review covered these points before anything reached Pinecart: - Each finding has linked request and response evidence with timestamps. - The effect is shown by a read-back or a second-account view, and a status code alone is not accepted. - The controls ran and behaved as expected. If they did not, the finding was dropped or relabeled. - Every state-changing proof used test-owned accounts and records marked as test data. - The severity matches the written definition for that level. - Any inferred path is labeled as inferred, and open questions sit under "Limitations and open questions". - The tool rules were followed, and the report states any bounded test and its cost. The agent proposes findings and runs tests. The review decides what the buyer reads. [Human in the loop pentesting](/guides/human-in-the-loop-pentesting/) covers the review in more depth. The allow, ask and deny rules give people control during the run, and the review follows it. The report lists what was not tested, because the agent does not find all vulnerabilities. The final report writes C-01 as a finding section with description, impact, verified results, reproduction and remediation. The full report holds the executive summary, controls that held, limitations and evidence index in other sections. > **Demonstration:** This is a demonstration based on a fictional application. No real customer system was tested. The excerpt is invented. PIN-01 / Authorization / Evidence label: ObservedHighAny signed-in shopper can read any other shopper's order by IDEndpointGET /v1/orders/{id}ClassBroken object level authorization (OWASP API1:2023)StatusOpen (retest pending)EvidenceE-014 to E-018 in the evidence indexDescription. The order endpoint checks that the caller has a valid token. It does not check that the order belongs to the caller. Order IDs are sequential integers, so a caller can read orders by counting upward.Impact. A signed-in shopper can read the name, email and shipping address of other shoppers. An attacker needs only a free account and can read every order by enumeration. Customers of Pinecart's merchants would be exposed, and a customer security review would raise it.Verified results. Shopper B read order 48213 and order 48214, both owned by shopper A. A nonexistent ID returned 404. An anonymous call returned 401. B's own order returned 200 with B as owner. Shopper A read the same record back with matching values.Reproduction. Create an order with test account A and note its ID. Request GET /v1/orders/{id} with the token of test account B. Compare the owner field. Use only test-owned accounts and records, and only with authorization.Remediation. Check ownership on the server for every order read. Compare the order owner with the account in the token and return 404 on mismatch. Do the same for update and cancel routes. Consider unpredictable order identifiers as defense in depth. They do not replace the ownership check.Found: demo run 1Retest: pending The severity is High because the exposed data is personal, the attack needs only a free account, and the effect is repeatable at scale. The report gives each level a written definition. It does not add CVSS vectors by default. If your program needs CVSS, say so during scoping. ## How a retest marks it fixed Pinecart fixes the check and ships. A retest reruns the original request set against the fixed system. It uses the same accounts, the same IDs and the same controls. A finding is marked fixed only when all these are true: 1. Shopper B's request for order 48213 now fails. The response is 404 or 403, with no order data in the body. 2. Shopper A can still read order 48213. This shows the fix did not break normal access. 3. The controls behave as before: the nonexistent ID gives 404, the anonymous call gives 401. 4. The neighboring routes (update, cancel) fail for B in the same way. 5. The "Controls that held" entry for C-02 still holds. A retest report keeps the old and new evidence side by side. | Outcome | What it means in the report | |---|---| | Fixed | The exploit request fails, normal access works and the controls hold. | | Not fixed | The exploit request still returns the other account's data. | | Partly fixed | The main route is fixed. A related route still leaks. | | Not retested | The item was out of the retest scope or could not be reached. | For Pinecart, the retest of PIN-01 would show this change: ```http GET /v1/orders/48213 HTTP/1.1 Authorization: Bearer HTTP/1.1 404 Not Found {"error":"order_not_found"} ``` The same request with A's token still returns 200. PIN-01 changes from Open to Fixed, with the date of the retest and the new evidence IDs. Excession Labs can retest fixed findings. We do not publish terms for retests on this page. Ask during scoping. ## Limits of this example and how to run one on your app A real run has many more leads than the two shown, and most close with a control and a short note. Business logic findings need a person to reason about how the product should behave, and none appear here ([where AI pentesting falls short](/guides/where-ai-pentesting-falls-short/)). The counts are invented, no result comes from a real system, and we make no claim about past engagements. Real counts, tools and rules come from the written scope. The path to a real assessment starts with a short call and a written scope. We test only with written authorization from the system owner. A small written scope can start as a [free pentest pilot](/pilot/); use the pilot form to apply. Places are limited and reviewed by hand. You approve rules like these before testing starts: see [how it works](/how-it-works/) and [the safety rules](/safety/). [The sample report](https://penetrationtestservices.com/sample-report/) from our pentest service shows a full web and API report. ## Questions ### Is this a real customer assessment? No. Pinecart is a fictional app and api.pinecart.example does not exist. We built the scenario to show the method. The format, rules and evidence standard match how we describe our work on the rest of this site. ### Why does the report include a rejected candidate? A rejected candidate shows how validation works. The 200 response looked like a leak until a control showed it returned the caller's own data. Reporting it would have wasted your engineers' time. The report records only what we can prove. ### Who decides that a finding goes into the report? Excession Labs checks the evidence for each finding and writes the report. The agent proposes findings. A finding with no linked evidence does not pass that check. ### What happens at retest? The original request set and its controls run again against the fixed system. The finding is marked fixed only when the exploit request fails and the control behavior still shows that normal access works. ## Sources - [OWASP API Security Top 10 2023: API1 Broken Object Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/) --- # AI pentest agents vs DAST scanners: what each does and what neither replaces Source: https://aipentestservices.com/guides/ai-pentest-agents-vs-dast-scanners/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 AI pentest vs DAST: how a fixed-check scanner and an adaptive agent differ, what each finds, a comparison table and a seven-step way to test both on one build. > **Short answer:** A DAST scanner sends payloads from a fixed check set to a running app and reports likely flaws. An AI pentest agent chooses its next request from earlier responses, can use several accounts, and must prove a finding with evidence. DAST suits broad, repeatable coverage. Agents suit flow and authorization testing. Neither replaces review of business logic by a person. A DAST scanner and an AI pentest agent both test a running application from outside. A scanner runs a fixed set of checks. An agent chooses its next request from what it just saw. That changes what each finds and how you read the results. ## What do a DAST scanner and an AI pentest agent each do? DAST stands for dynamic application security testing. OWASP's DevSecOps Guideline describes DAST as "black-box" testing that "can find security vulnerabilities and weaknesses in a running application". It works by "injecting malicious payloads to identify potential flaws", with SQL injection and cross-site scripting as examples. The same OWASP page says DAST tools are especially helpful for detecting input and output validation issues, authentication issues and server configuration mistakes. It adds that scans work without source code and "usually require minimal user interactions once configured and can be run as part of a nightly scan." The page does not discuss limits or false positives, so those points below are our own reading. A scanner crawls the app, builds a list of URLs and parameters, and sends its payload set to each. It matches the responses against signatures and reports matches. An AI pentest agent works differently. It reads each response and picks the next request. It can hold several sessions at once, follow a multi-step flow such as sign-up then checkout, and read client-side JavaScript for routes the crawler never visited. In the lab's AI testing agents, an engagement is split into tasks that run in parallel under tool rules Excession Labs sets for the scope. Each tool has an allow, ask or deny rule. A task is done only when each finding links to its evidence. The evidence rule is the main design difference. A scanner reports that a pattern matched. An agent, under a strict standard, reports that an effect was shown. ## How do they compare, and where does each fit? These differences affect a buying choice, for typical designs. | Question | DAST scanner | AI pentest agent | |---|---|---| | How is the next request chosen? | From a fixed check set | From earlier responses, by a model | | Sessions used | Usually one, sometimes several | Several accounts and roles by design | | Finds object-level access flaws? | Rarely | Yes, through two-account comparison | | Follows multi-step flows? | Limited to recorded scripts | Yes, within limits | | Repeatability | High: same input, same checks | Lower: model choices vary between runs | | Speed and cost per run | Low, can run on a schedule | Higher per run | | Typical false positive cause | Pattern match without proof | Success message read as proof | | Output | Findings list with severity | Findings with evidence, steps and a fix | | Human review | Optional | Needed for validation | | Business-logic flaws | Not found | Sometimes found; people still review | Use a scanner for breadth and routine, and an agent for depth on authorization and flows. | Situation | Better first choice | |---|---| | Nightly check for known issue classes on every build | DAST scanner | | Check that role and tenant boundaries hold | AI pentest agent, with test accounts | | Many small web properties, same stack | DAST scanner | | New feature with a multi-step workflow | AI pentest agent, with a human reviewer | | Customer asks for a penetration test report | Pentest with human-checked evidence | | Need to prove a fix worked | Retest of the specific finding | For release-based testing, see [per-release testing](/per-release-testing/). ## Why do scanners miss authorization bugs, and what does neither replace? Scanners usually lack the information needed to see an authorization flaw. [OWASP API1:2023](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/) describes attackers changing "the ID of an object that is sent within the request". A request that returns data for another user's ID looks like a normal `200` response. Only a test that knows which account owns the object can call it a flaw. The [WSTG test for IDOR](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References/) works for the same reason: it needs more than one identity and a comparison. [How AI agents test authorization](/guides/how-ai-agents-test-authorization/) gives the full method. Neither a scanner nor an agent replaces a person who understands your business. Three gaps remain. 1. Intent. Only your team knows that a coupon must work once or that a manager may approve up to a limit. 2. Novel chains. Joining several weak points into one serious impact still needs human judgment. 3. Accountability. Someone must decide what a finding means for your risk and sign off on the report. This is why our model keeps a human step. Excession Labs checks the evidence for each finding and writes the report. See [where AI pentesting falls short](/guides/where-ai-pentesting-falls-short/) for more. ## How should you test a scanner and an agent against each other? Run both on the same staging build and compare what each reports. This tells you more than any vendor claim. 1. Pick one staging build and freeze it for the comparison. 2. Create the same test accounts for both tools. Use at least two accounts in one role. 3. Run the scanner with its authenticated mode on, if it has one. A scanner run without login is an unfair test. 4. Run the agent-led test under written scope and the same accounts. 5. Sort every reported item into three groups: confirmed by a read-back or browser proof, plausible but unproven, and rejected. 6. Count each group per tool. Do not count raw findings. A long list with a high rejected share costs your developers time. 7. List the real bugs that only one tool found. Those show each tool's blind spot. > **Note:** Do not plant bugs and score the tools on them alone. Planted bugs only test what you already thought of. If both tools find the same injection flaw, the scanner covers that class well for routine runs. A cross-account read that only the agent finds fits a scanner that had one identity. Use both in many cases. A scanner on a schedule catches regressions in known issue classes at low cost. An agent-led test, run when you ship a major change, goes deeper on access control and flows. Whichever you pick, ask how findings are validated. [AI pentesting false positives](/guides/ai-pentesting-false-positives/) covers agents that over-claim. [What is AI penetration testing](/guides/what-is-ai-penetration-testing/) maps the three kinds of AI testing. [AI versus manual pentesting](/ai-vs-manual-pentesting/) describes our delivery model. ## Questions ### Should I stop using my DAST scanner if I buy AI pentesting? Not necessarily. A scanner gives cheap, repeatable coverage of known issue classes, and it can run on a schedule. AI-assisted testing adds depth on flows and authorization. Many teams keep both and compare what each finds. ### Do DAST tools find IDOR and broken access control? Rarely. Most scanners test one session and do not know which object belongs to which user. Finding these flaws needs two or more accounts and a comparison. Some scanners support multi-user scans, so check your tool. ### Is an AI pentest agent just a DAST scanner with a chatbot? No, if it is built as an agent. A scanner follows a check list. An agent plans, adapts to responses and uses tools. But some products sold as AI pentesting are scanners with AI features, so ask how the next request is chosen. ### Which one produces more false positives? It depends on the product and the evidence rules. Scanners can flag patterns without proof. Agents can over-claim from success messages. Ask how each finding is validated and by whom. ## Sources - [OWASP DevSecOps Guideline: Dynamic Application Security Testing](https://owasp.github.io/www-project-devsecops-guideline/latest/02b-Dynamic-Application-Security-Testing) - [OWASP API Security Top 10 2023: API1 Broken Object Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/) - [OWASP Web Security Testing Guide v4.2: WSTG-ATHZ-04 Testing for Insecure Direct Object References](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References/) --- # AI pentesting false positives: why agents over-claim and how to validate Source: https://aipentestservices.com/guides/ai-pentesting-false-positives/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 Why AI pentest agents report bugs that are not real, the evidence standard that stops it, and a validation checklist you can apply to any AI-generated finding. > **Short answer:** AI pentest false positives are findings that an agent reports as real but that have no real effect. They arise because a language model reads a response and judges it, and a success message looks like proof. The fix is an evidence standard: prove the effect by reading state back, run controls beside each exploit request, and have a human check every finding. An AI pentest false positive is a finding that an agent reports as real but that has no real effect on the target. A bare success response is not proof. A server can answer `200 OK` and change nothing, or return `{"ok": true}` while it ignores the request. If a report treats that answer as evidence, the finding may be false. ## Why do AI pentest agents over-claim, and what evidence stops it? Agents over-claim because a language model judges text, and a response that looks like success reads as success. Four causes recur. 1. Success-shaped responses. Many APIs return `200` or a friendly message for a request they quietly ignore. The model reads the message and concludes that the action worked. 2. Echoed input. The server reflects the attacker's value back. The agent sees its own payload in the response and calls it injection or stored data. 3. Public data. The agent fetches another user's record and calls it an authorization failure. The record is public by design. 4. Pressure to finish. An agent that is asked for findings tends to produce findings. A task with no evidence rule rewards a confident claim. Each cause comes from a design that lets the model decide alone that a test passed. The fix is an evidence standard. A finding needs evidence of a real effect. Our rule is that a write is proven by reading the changed record back through another session. A "success" response alone does not count. In the lab's AI testing agents, a finding is reported only when it links to its evidence. [OWASP API1:2023](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/) describes attackers manipulating "the ID of an object that is sent within the request". Proof is a response or stored state that shows an object the caller should not reach. | Claim type | Weak evidence (do not accept) | Strong evidence | |---|---|---| | Read another user's data | `200` status | Response body holds a record that belongs to the other account, and a control shows the owner can see it and a third party cannot | | Change another user's data | `200` or `{"ok":true}` | Owner session reads the record back and shows the new value | | Delete a record | `204` status | Owner session requests the record and gets `404` | | Injection | Payload echoed in the response | Payload runs in a real browser, or changes server behavior in a way a control does not | | Missing authentication | One request without a cookie works | Same request with and without a valid cookie differ in a way that shows the protection is absent | ## What are controls, and why run them beside the exploit? A control is a second request that should fail or behave differently, sent next to the exploit request. It shows that the test can tell a real effect from noise. Without controls, a positive result might come from a server that accepts everything. The controls we run beside exploit requests are: - nonexistent identifiers; - wrong record types; - unsigned or wrongly signed cookies; - another account's token; - anonymous versus signed-in comparisons. Controls that held are reported too, in a "Controls that held" section. That way a later fix does not break a protection that worked. > **Demonstration: a false positive caught by a control:** This is a demonstration on a fictional app, Harbor Notes, hosted on example.com. No real customer system was tested. > > An agent sends a request to rename a note owned by another account: > > ```http > PATCH /api/notes/9001 HTTP/1.1 > Host: harbor.example.com > Cookie: session= > Content-Type: application/json > > {"title": "renamed by B"} > ``` > > The response is: > > ```http > HTTP/1.1 200 OK > Content-Type: application/json > > {"ok": true} > ``` > > The agent first records "possible broken object-level authorization". The validation step reads the note back as account A, the owner: > > ```http > GET /api/notes/9001 HTTP/1.1 > Host: harbor.example.com > Cookie: session= > ``` > > ```json > {"id": 9001, "title": "Quarterly plan", "owner": "a@example.com"} > ``` > > The title did not change. The server returned `200` and ignored the write. A control with a nonexistent ID (`/api/notes/0`) also returned `200 {"ok": true}`, which shows that this endpoint answers success to anything. The finding is rejected. The report lists it under controls and notes, not under findings. ## How do you validate an AI-generated finding? Use this checklist on every AI-generated finding, whether it comes from us or from another tool. A finding passes only if each box can be ticked from the saved evidence. 1. The request and response are saved, with a timestamp. 2. The test used accounts and records that the tester owns, marked as test data. 3. For a write or delete, a second session read the state back and shows the change. 4. At least one control ran beside the exploit and behaved as expected. 5. The data shown is not public by design. 6. The steps reproduce on a second attempt. 7. The report labels the evidence: "Observed" (reproduced), "Browser-observed" (shown in a real browser), or inferred. 8. A human reviewed the evidence before the finding reached the report. 9. The impact statement does not go beyond what the evidence shows. If items 3, 4 or 8 are missing, treat the finding as unconfirmed. [Human-in-the-loop pentesting](/guides/human-in-the-loop-pentesting/) shows where review points sit in the workflow. Findings that cannot be proven go into a separate section, not into confirmed impact. Our reports use a "Limitations and open questions" section for these. An inferred path is labeled as inferred, so a reader can see what was proven and what was only suspected. To check any AI pentest report, count how many findings carry a read-back or a control, and how many rest on a status code. The [guide to evaluating an AI pentest report](/guides/evaluating-an-ai-pentest-report/) goes through the signals. ## Where can you see this in practice? The [example assessment](/example-assessment/) is a labeled demonstration with a rejected false positive beside a validated finding. [How AI pentesting works](/how-it-works/) shows where the evidence check and the human review sit in the flow. Excession Labs checks the evidence for each finding and writes the report. ## Questions ### Do human pentesters also report false positives? Yes. Any tester can misread a response. The difference is scale and tone: an agent can produce many plausible-looking claims fast, each written with confidence. That makes a fixed validation step more important, not less. ### Is a false positive worse than a missed bug? Both cost you. A false positive wastes engineering time and teaches developers to ignore reports. A missed bug leaves a hole open. A good process keeps both rates low and states what it did not test. ### How can I check a finding without running the exploit? Ask for the saved request and response, the timestamps, and the read-back that shows the changed state. If the report has only a status code and a description, ask for more before you accept the finding. ### Can you remove false positives completely? No. You can lower them with evidence rules, controls and review. A report should also list its open questions, so you can see what was inferred and not proven. ## Sources - [OWASP API Security Top 10 2023: API1 Broken Object Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/) - [OWASP Web Security Testing Guide v4.2: WSTG-ATHZ-04 Testing for Insecure Direct Object References](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References/) --- # AI pentesting for startups: when it fits and what to prepare Source: https://aipentestservices.com/guides/ai-pentesting-for-startups/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 AI pentest for startups: when AI-assisted pentesting fits a customer security review or launch, a readiness checklist to prepare, and what it will not give you. > **Short answer:** AI pentesting suits startups with a web app or API that needs evidence before a customer security review or launch. Prepare a staging copy, test accounts for each role, written authorization and a short scope. It will not give you compliance, a clean bill of health, or tests of people and offices. Prices are quoted after scoping. AI pentesting fits a startup that has a web app or API and needs proof of its security state at a set time. Two common moments are a customer security review and a pre-launch check. It does not fit if you need a test of people, offices or a network. ## When does AI pentesting fit a startup? It fits when you have a defined target, a deadline for evidence, and a small team. AI-assisted testing by Excession Labs covers web applications and APIs. The lab's AI testing agents do the testing work under tool rules that Excession Labs sets for the scope. Excession Labs agrees scope with you in writing, checks the evidence for each finding and writes the report. Typical triggers: - A customer security review: An enterprise buyer asks for a pentest report or a summary. For the buyer's view of what to expect, see [pentest reports for customer security reviews](https://penetrationtestservices.com/customer-security-review/). - A pre-launch check: You want to find broken access control before real users arrive. - A major release: You added roles, billing or an API. See [pentesting in CI/CD](/guides/pentesting-in-ci-cd/). - A fix check: You fixed earlier findings and want proof. If you have not launched, a free pilot may suit you. Read the [pilot page](/pilot/) for terms. Before a first test, work through this readiness list. > **Startup readiness checklist:** **Decide** > - [ ] The reason for the test (review, launch, release, fix check). > - [ ] The deadline for the report, if any. > - [ ] One person who approves scope and answers questions. > > **Authorize** > - [ ] Written authorization from the system owner. > - [ ] Hosting and cloud rules for security testing checked. > - [ ] A list of third-party services in the flow, and any limits on them. > > **Environment** > - [ ] A staging copy that matches production, or agreement to test production with test-owned data. > - [ ] Test accounts for each role. Two accounts in different tenants if you are multi-tenant. > - [ ] Synthetic data. No real customer records. > - [ ] A way to reset test data. > > **Material** > - [ ] API docs or an OpenAPI file, if you have one. > - [ ] A short list of what matters most: money, personal data, admin actions, tenant isolation. > - [ ] Known issues you do not want re-reported. > > **Safety** > - [ ] A named contact during the test. > - [ ] Stop conditions agreed. > - [ ] Backups confirmed. > > **After** > - [ ] A place to track findings as tickets. > - [ ] Time set aside to fix, then retest. The [production safety guide](/guides/is-ai-pentesting-safe-in-production/) covers the safety rows in detail. ## What will you get, and what will it not give you? You get a written report with proof. Each finding includes the evidence, the steps to reproduce it, and a suggested fix. The report also lists controls that held, and a section on limitations and open questions. Formats are HTML, PDF and Markdown, plus proof-of-concept scripts. Severity uses a four-level scale: Critical, High, Medium and Low, each with a written definition. CVSS vectors are not added by default. Tell us during scoping if a customer asks for CVSS. We can retest fixed findings. We do not state here whether a retest is free or how long it takes. Agree this in the written scope. Know these limits before you plan around a test. - Compliance: A pentest report is evidence. It does not make you compliant. Standards set their own text. For example, OWASP ASVS says Level 1 [is a starting point](https://asvs.owasp.org/), not a finish line. Ask your auditor or customer what they accept. - A clean bill of health: A test with no findings means nothing was found in that scope. It says nothing more about the rest of the system. - All vulnerabilities: The lab's AI agents do not find all of them. No test does. - People and places: Phishing, phone pretexts and physical access are out of scope. - Business-rule judgment: You must tell us your rules. [Where AI pentesting falls short](/guides/where-ai-pentesting-falls-short/) gives the full list. - A fixed price or date on this page: Prices are quoted after scoping. We publish no turnaround times. ## How do you choose between a pilot, a one-off test and recurring testing? Pick by the question you need answered. | Your situation | Fit | |---|---| | First test, small app, want to see the output | Free pilot. Small written scope, limited places | | One customer review or one launch | One-off test for that need | | Frequent releases with changes in auth or data | Recurring testing after releases, with a scope delta each time | | Only fixes to check | Retest of those findings | Paid work is priced after scoping. The [pricing page](/pricing/) lists what changes a quote. We do not publish prices. Whichever you choose, the process starts with a short call to understand the need, then a written scope and proposal. We test only with written authorization from the system owner, so settle the authorization items on the checklist early. ## How should a small team handle the findings? Handle findings in order of impact. Fix High and Critical items first. Create one ticket per finding and attach the evidence. Ask for a retest after the fix. Then add a regression test to your own CI so the bug does not return. The [OWASP Web Security Testing Guide](https://wstg.owasp.org/) lists test areas your team can cover in its own checks. Keep the "controls that held" list. It tells you what to protect when you refactor. If a customer asks for your report, share what your contract allows. Do not share raw evidence that includes secrets. Ask your lawyer before you share a full report outside the company. To scope a test, open the [pilot page](/pilot/) or read [how it works](/how-it-works/). ## Questions ### Is a free pilot available? Excession Labs runs a free pentest pilot with a small written scope. You give written authorization first. You receive every finding in the agreed scope with evidence and fix guidance. Places are limited and reviewed by hand. See the pilot page. ### How much does it cost? We do not publish prices. A quote follows scoping. The number of apps, roles and API endpoints, and the number of retests, are the usual drivers. See the pricing page for what changes a quote. ### Will a pentest make us compliant? No. A pentest gives evidence. A standard sets its own rules. Ask your auditor or customer what they accept. We make no claim about what an auditor, customer or regulator will accept. ### We have no security team. Can we still use this? Yes. You need one person who can approve scope, set up test accounts and take fix tickets. The report gives evidence and suggested fixes for each finding. Developers can work from it. ## Sources - [OWASP Application Security Verification Standard 5.0.0](https://asvs.owasp.org/) - [OWASP Web Security Testing Guide](https://wstg.owasp.org/) - [About Excession Labs](https://excessionlabs.ai/about/) --- # Evaluating an AI pentest report: signs of real validation Source: https://aipentestservices.com/guides/evaluating-an-ai-pentest-report/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 How to evaluate an AI pentest report: check for requests, read-back proof, controls, evidence labels and limits. Includes a scorecard with no numeric scores. > **Short answer:** A good AI pentest report shows proof, not claims. Look for saved requests and responses with timestamps, read-back from a second account, controls that held, evidence labels such as Observed and Browser-observed, inferred paths marked apart, a limitations section, and reproduction steps. Scanner noise gives severity words and generic advice without evidence. To evaluate an AI pentest report, check whether each finding comes with proof you can inspect. Real validation shows the request, the response, a read-back that confirms the effect, and controls that rule out false explanations. Scanner noise shows a severity word, a generic description and no evidence. The scorecard below has no numeric scores, because a number hides the one missing item that matters. ## What does real validation look like? Real validation proves an effect. A server can answer 200 and change nothing, and another can answer 403 and still change data. The report must show what happened. Our own reports use these signals: - Requests and responses are saved with timestamps. - A write is proven by read-back: the tester changes a record, then reads it through another session. - Controls run next to the exploit request: nonexistent identifiers, wrong record types, unsigned or wrongly signed cookies, another account's token, anonymous versus signed-in. - Evidence has labels. "Observed" means reproduced, "Browser-observed" means shown in a real browser, and inferred paths are labeled apart. - A "Limitations and open questions" section holds what was not proven. The [example assessment](/example-assessment/) is a labeled sample run with a validated finding and a rejected false positive. Scanner noise states a possible issue. A validated finding shows the issue working. | Scanner noise | Validated finding | |---|---| | "Possible IDOR on /api/items/{id}" | Request as account A for account B's item, the response, and the read-back | | "Missing security header" with no effect described | Header gap tied to a shown, exploitable path, or labeled as low-impact hardening | | Same text for every customer | Text tied to your routes, roles and data | | Severity from a plugin default | Severity from the written scale, with impact for your product | | No negative tests | Controls show the check is not a false trigger | [AI pentesting false positives](/guides/ai-pentesting-false-positives/) goes further, and [AI pentest agents vs DAST scanners](/guides/ai-pentest-agents-vs-dast-scanners/) compares scanners with agents. ## Scorecard: what to look for in a report > **Report evaluation scorecard:** Mark each row Present, Partly or Missing. Do not add numbers. Any Missing row in the first block needs an answer from the provider. > > | Check | What good looks like | Red flag | > |---|---|---| > | **Proof** | | | > | Requests and responses | Saved per finding, with timestamps | Screenshots only, or none | > | Read-back | Change confirmed from a second session | "200 OK" as proof of a write | > | Controls | Negative cases listed next to each exploit | Only the positive case | > | Reproduction | Steps or read-only scripts that use test-owned IDs | "Try it yourself" with no steps | > | **Honesty** | | | > | Evidence labels | Observed, Browser-observed, inferred, kept apart | One confidence level for all | > | Limitations | Named section: not tested, not proven | No such section | > | Controls that held | Reported, so fixes keep them | Only failures listed | > | **Usefulness** | | | > | Severity scale | Written definition for each level | Severity words with no definition | > | Fix guidance | Specific to your stack and the finding | Generic advice copied from a standard | > | Scope and method | Assets, roles, dates and method stated | Scope missing or vague | > | Evidence index | A list that maps findings to files | Evidence cannot be found | > | Integrity | Key evidence with a SHA-256 manifest | Files can change unseen | Ask about every Missing in the Proof block. A report that lacks read-back or controls has not shown that the issue is real. ## What should the report structure include, and how do you read severity? Our reports have these sections: 1. Project details: scope, assets, severity scale. 2. Assessment method. 3. Safety constraints. 4. Evidence labels. 5. Executive summary with priority actions. 6. Findings at a glance. 7. Reproduction environment. 8. One section per finding: description, impact, verified results, reproduction, remediation. 9. Controls that held. 10. Remediation plan. 11. Limitations and open questions. 12. Evidence index. 13. Appendix of reproduction scripts. We deliver HTML, PDF and Markdown, plus proof-of-concept scripts. [NIST SP 800-115](https://csrc.nist.gov/pubs/sp/800/115/final), published in 2008 and still listed as final, also asks for analysis and reporting that turns results into mitigation actions. Use the list to find gaps in any report. Severity should follow a written scale, and impact should name your product. Our scale has four levels: Critical, High, Medium and Low. Each level has a written definition in the report. Check three things for each rating: 1. The definition: Can you point to the sentence that puts this finding at High, not Medium? 2. The impact text: Does it say what an attacker gains in your app, such as reading another tenant's invoices? Or does it repeat a generic line about "data exposure"? 3. The conditions: Does the finding state what the attacker needs: an account, a role, a leaked token? A rating with no definition is an opinion. Ask the provider for the rule behind it. ## What should you ask the provider? Send questions in writing and expect answers that point to evidence: - Which finding has the weakest proof, and why is it in the report? - Which checks did not run, and what stopped them? - What did the controls show for the top three findings? - Which paths are inferred, and what would confirm them? - Which tests were bounded, and what did they cost? - Who checked the evidence before the report was written? Compare the answers with the report. If the report says one thing and the provider says another, trust the saved evidence. A report with more findings is not better. Count does not measure quality. A long list of unproven alerts costs your team time. A short list of proven findings with controls gives you work you can start today. Read the first three findings in full before you judge the rest. If they are well proven, the process behind the report is probably sound. If they are thin, expect the same across the report. Then check the section that lists controls that held. It shows the tester looked at working protections too, and it gives you a list to guard when you change the code. Also ask who checked the AI's work. At Excession Labs, the lab's AI testing agents do the testing under tool rules that Excession Labs sets for the scope. Excession Labs checks the evidence for each finding and writes the report. A task is done only when each finding links to its evidence. Look for the same split in other reports: who ran the tests, who checked the proof, and who wrote the conclusions. If the report cannot answer, you cannot tell how much to trust it. [How agentic pentesting works](/guides/how-agentic-pentesting-works/) explains the pipeline. ## What to do after you read the report 1. Mark the scorecard. Send questions about Missing items. 2. Pick one High finding and replay its evidence, with authorization. 3. Check that the fix guidance fits your code. 4. Fix, then ask for a retest of each fixed finding. 5. Keep the controls-that-held list as a regression list for your own tests. [How it works](/how-it-works/) covers a full engagement from scope to retest. ## Questions ### How long should a pentest report be? Length is not a quality signal. A short report with proven findings beats a long one with unproven alerts. Check the ratio of evidence to claims, and check that the method and limits are written. ### Should a report use CVSS? Not necessarily. Our reports use a four-level scale (Critical, High, Medium, Low) with a written definition for each level. CVSS vectors are not added by default. If your program needs CVSS, say so during scoping. ### What if a report has no findings? A clean report is useful only if it shows what was tested and the controls that held. Check scope, method and limits. It shows that nothing was found in that scope, and it says nothing more about the system. ### Can I rerun the tests myself? You can, with authorization and test-owned identifiers. Good reports include reproduction steps or scripts. Scripts should be read-only where possible. Do not run them against real users' data. ## Sources - [NIST SP 800-115: Technical Guide to Information Security Testing and Assessment (2008, final)](https://csrc.nist.gov/pubs/sp/800/115/final) - [OWASP Web Security Testing Guide](https://wstg.owasp.org/) --- # How agentic pentesting works: planner, workers, tools and evidence Source: https://aipentestservices.com/guides/how-agentic-pentesting-works/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 How agentic pentesting works: a planner splits work, workers run tasks in parallel, tool rules gate actions, and each finding must link to evidence. > **Short answer:** Agentic pentesting uses an AI agent that plans and runs security tests with tools. In the lab's AI testing agents, a planner splits an engagement into tasks, workers run them in parallel, each tool has an allow, ask or deny rule, workers keep notes, and a task is done only when each finding links to its evidence. Excession Labs checks that evidence and writes the report. Agentic pentesting is security testing done by an AI agent in a loop. The agent plans, calls tools, reads results and plans again. It works inside rules that a human sets. This page describes the AI testing agents that Excession Labs uses, and makes no claims about how other products are built. ## What are the parts of an agentic pentest? An agentic pentest has five parts: a planner, workers, tools with rules, notes, and an evidence link for each finding. The walkthrough follows one engagement in order. > **Architecture walkthrough:** > 1Scope and authorizationYou and Excession Labs agree a written scope. The system owner gives written authorization. Nothing runs before this. > 2Planner (coordinator)The planner splits the engagement into tasks, such as "map the API", "compare role access" or "check the upload flow". > 3WorkersSeveral workers run tasks in parallel. Each worker uses the agent loop: decide, call a tool, read the result. > 4Tool rulesEach tool is allow (runs on its own), ask (waits for approval) or deny (blocked). The operator sets the rules. > 5Notes and findingsThe agents keep notes and findings for each worker, plus session history. > 6Evidence gateA task is done only when each finding links to its evidence. > 7Review and reportExcession Labs checks the evidence for each finding and writes the report. Retest of fixes follows. > In step 2, the planner turns a scope into a set of tasks. It is the coordinator of the engagement. It decides what to test, in what order, and how to divide the work. A good plan follows a known test structure. The [OWASP Web Security Testing Guide](https://wstg.owasp.org/) is one common reference for web testing areas such as authentication, session management, authorization and input handling. The planner can use that kind of structure to avoid skipping areas. The planner works inside the written scope. If a task needs a target outside it, the task does not run. The human operator can change the plan. ## What do workers do, and how do tool rules work? Workers carry out tasks in parallel. One worker might compare what an anonymous caller and a signed-in caller can request while another reviews client-side JavaScript bundles for endpoints. Parallel workers do not remove the need for review. Each worker follows the same tool rules and the same evidence rule. The methods used in an Excession Labs engagement include: - Direct HTTP requests. - Browser-observed tests in Chromium, for example CSRF and stored XSS checked in a real browser. - Review of client-side JavaScript bundles. - Differential comparison of anonymous and signed-in callers. - Read-back from a second account to prove cross-account effects. A tool is any action the agent can call: an HTTP client, a browser, a code search, a script runner. Every tool has one of three rules. | Rule | Behavior | Example use | |---|---|---| | allow | Runs on its own | Read-only requests to in-scope hosts | | ask | Waits for human approval | A state-changing request, or a bulk action | | deny | Blocked | Anything outside scope or on a forbidden list | The operator sets these rules before the run. The [safety page](/safety/) lists the full set of safe-test constraints. [Human-in-the-loop pentesting](/guides/human-in-the-loop-pentesting/) shows where approval points fit. ## Why do the agents keep notes and require evidence for each finding? Notes let a worker keep what it learned and let the report trace back to the work. The agents run an agent loop with tools and session history, and keep notes and findings for each worker. With notes, a worker can continue a task and a reviewer can follow how a finding came about. This page does not describe the internal format. The evidence rule keeps unproven claims out of the report. A model can state a vulnerability with confidence and be wrong, so every finding must point at something checkable. What counts as evidence follows our standard: - A finding needs evidence of a real effect. A write is proven by reading the changed record back through another session. A bare "success" response is not proof. - Controls run next to exploit requests: nonexistent identifiers, wrong record types, unsigned or wrongly signed cookies, another account's token, anonymous versus signed-in comparisons. - Requests and responses are saved with timestamps. - Labels separate "Observed" (reproduced), "Browser-observed" (shown in a real browser) and inferred paths. Each finding includes the evidence, the steps to reproduce it, and a suggested fix. [AI pentest false positives](/guides/ai-pentesting-false-positives/) shows what this rule rejects. ## Where does the human review fit? People act at three points. The operator sets tool rules and approves actions marked ask. Excession Labs agrees the scope with you in writing. Excession Labs then checks the evidence for each finding and writes the report. The agents run under human control and does not find all vulnerabilities. The report has a "Limitations and open questions" section for what stayed unproven. [Where AI pentesting falls short](/guides/where-ai-pentesting-falls-short/) lists the limits. [How it works](/how-it-works/) covers the service workflow from enquiry to retest. ## Questions ### What does agentic mean in pentesting? An agentic tool runs a loop. It decides the next step, calls a tool, reads the result and decides again. A scanner runs a fixed list of checks. An agent can change its plan based on what it sees, within the rules the operator sets. ### Do the workers share what they learn? The agents keep notes and findings for each worker, and they keep session history. This lets a worker continue a task and lets the report trace back to the work. We do not describe internal data formats on this page. ### Is a human involved? Yes. The operator sets tool rules and approves actions that are set to ask. Excession Labs agrees scope in writing, checks the evidence for each finding and writes the report. The agents do not run without human control. ### Can I see the agent's work? You see the evidence for each finding: saved requests and responses with timestamps, and steps to reproduce. The report has an evidence index. Key evidence can carry a SHA-256 manifest. ## Sources - [About Excession Labs](https://excessionlabs.ai/about/) - [OWASP Web Security Testing Guide](https://wstg.owasp.org/) --- # How AI agents test authorization: differential tests across accounts Source: https://aipentestservices.com/guides/how-ai-agents-test-authorization/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 How an AI pentest agent tests your app for IDOR and broken authorization: replay requests across accounts, compare responses, and prove the effect by read-back. > **Short answer:** An AI agent tests authorization by differential testing. It signs in as two or more test accounts, records what each can reach, then replays each request with the other account's identifiers and compares the results. A real flaw needs proof: a read of data the caller should not see, or a read-back that shows a change. An AI agent tests authorization by differential testing: it compares what different callers can do with the same request. It signs in as several test accounts, replays each request under each account, and checks whether the server enforces the rules. The same method finds IDOR (insecure direct object reference), which OWASP's API list calls Broken Object Level Authorization. ## What is differential testing, and how does an agent run it? Differential testing sends the same action as different callers and compares the results. The difference, or the lack of one, shows whether access control works. A tester needs one baseline and several variants. - Baseline: the owner of an object makes a request. This shows what correct access looks like. - Variants: another account in the same role, an account in a lower role, an account in another tenant, and an anonymous caller make the same request. If a variant gets the baseline response, the server did not enforce the rule. The first thing to rule out is that the data is public by design. For the manual version of this method, see our sister site's [IDOR testing guide](https://penetrationtestservices.com/guides/idor-testing/). An agent follows the same loop for any endpoint. In the lab's AI testing agents, a planner splits the engagement into tasks and workers run them in parallel. A worker handling authorization does this: 1. Map. Sign in as each test account and record every request the app makes, including requests found in client-side JavaScript. 2. Extract identifiers. List each object ID, tenant ID and role value that appears in paths, query strings and bodies. 3. Build the matrix. For each endpoint, note which account owns which object. 4. Replay. Send each request under each other account's session. 5. Compare. Check status, body and headers against the baseline. 6. Run controls. Repeat with nonexistent IDs, wrong record types and another account's token. 7. Prove. For any candidate, read the effect back through the owner's session. 8. Record. Save request, response and timestamp, and link them to the finding. ## What does a worked differential test look like? The demonstration runs a read test, a write test with read-back, and the controls on a fictional app. > **Demonstration: two-account authorization test on Harbor Notes:** This is a demonstration on a fictional app, Harbor Notes, hosted on example.com. No real customer system was tested. Account A and account B are test accounts created for this example. Session values are shortened. > > **Setup.** Account A owns note 1001. Account B owns note 2002. Both are "member" role in different workspaces. > > **Step 1: baseline (owner reads own note).** > > ```http > GET /api/notes/1001 HTTP/1.1 > Host: harbor.example.com > Cookie: session=A-token > ``` > > ```http > HTTP/1.1 200 OK > {"id":1001,"workspace":"ws-a","title":"Q4 plan","body":"Launch on the 14th"} > ``` > > **Step 2: variant (account B reads A's note).** > > ```http > GET /api/notes/1001 HTTP/1.1 > Host: harbor.example.com > Cookie: session=B-token > ``` > > ```http > HTTP/1.1 200 OK > {"id":1001,"workspace":"ws-a","title":"Q4 plan","body":"Launch on the 14th"} > ``` > > B received A's private note. The body matches the baseline. This is a candidate finding. > > **Step 3: controls.** > > ```http > GET /api/notes/1001 (no cookie) -> 401 > GET /api/notes/999999 (B-token) -> 404 > GET /api/notes/2002 (B-token, B's own) -> 200 (B's note) > GET /api/notes/1001 (C-token, third tenant)-> 200 (same body) > ``` > > The anonymous control returns `401`, so authentication works. The nonexistent ID returns `404`, so the server does look up the record. Account C, in a third workspace, also reads note 1001. The failure is not tied to one pair of accounts. > > **Step 4: write test with read-back.** > > ```http > PUT /api/notes/1001 HTTP/1.1 > Host: harbor.example.com > Cookie: session=B-token > Content-Type: application/json > > {"title":"changed by B (test data)"} > ``` > > ```http > HTTP/1.1 200 OK > {"ok":true} > ``` > > The status alone proves nothing. The agent reads back through the owner's session: > > ```http > GET /api/notes/1001 HTTP/1.1 > Cookie: session=A-token > ``` > > ```http > HTTP/1.1 200 OK > {"id":1001,"title":"changed by B (test data)", ...} > ``` > > The title changed. The write is confirmed. The agent then restores the original title, because the record is test-owned data and the test must leave the app as it found it. > > **Result.** Broken object-level authorization on read and write of `/api/notes/{id}`. Evidence: steps 2 and 4, controls in step 3. ## Which test cases and controls should an authorization run cover? Each row lists what to compare for one kind of flaw and what counts as proof. | Flaw | Test | Proof | |---|---|---| | Object-level (IDOR/BOLA) | Account B requests account A's object ID | Body holds A's data, and it is not public by design | | Function-level (BFLA) | Low-role account calls an admin-only endpoint | Action succeeds, and a read-back shows the effect | | Tenant isolation | Account in tenant 2 requests tenant 1's object | Cross-tenant data appears; a third tenant also reads it | | Property-level | User sends extra field such as `"role":"admin"` | Read-back shows the field changed | | Method switch | Replace `GET` with `PUT` or `DELETE` on a protected path | State changes on read-back | | Version drift | Call `/v1/` after `/v2/` is fixed | Old version still returns the data | [OWASP API5:2023](https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/) covers function-level flaws. [WSTG-ATHZ-04](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References/) covers the web version of the object-level test. Controls stop the agent from calling a lenient server a vulnerable one. The controls in the demonstration are the ones we run: nonexistent identifiers, wrong record types, another account's token, and anonymous versus signed-in comparisons. The rule behind them comes from our evidence standard: a write is proven by reading the changed record back through another session. Three more rules limit risk: - Destructive proofs use only test-owned accounts and records, marked as test data. - Tests of uploads, password guessing, email sending and paid third-party APIs are bounded, and the report states their cost. - A person reviews the evidence for each finding ([human-in-the-loop pentesting](/guides/human-in-the-loop-pentesting/)). [AI pentesting false positives](/guides/ai-pentesting-false-positives/) covers the failure modes these controls address. ## What does an agent still miss? An agent cannot test a rule it cannot see. If your app lets a manager approve only invoices under a limit, the traffic does not state the limit. Give the tester an access matrix: roles, objects and the expected result for each pair. The accounts must also hold the right data. [Testing signed-in flows](/guides/testing-signed-in-flows-with-ai-agents/) covers account setup. [How AI pentesting works](/how-it-works/) covers the full flow from scope to report. The [example assessment](/example-assessment/) shows a validated finding next to a rejected one. ## Questions ### Why does authorization testing suit AI agents? The method is mechanical. The agent replays many requests under different accounts and compares results. That is repetitive work with a clear check. It does not replace the human step that decides whether a result breaks a business rule. ### How many test accounts does an agent need? At least two accounts in the same role to test object-level access, one account per role to test function-level access, and two tenants to test tenant isolation. An unauthenticated caller is the baseline for all of them. ### Can the agent find authorization bugs if it has no access matrix? It can find many by observation, because it records what each account sees. It cannot know the intended rule for every endpoint. A short access matrix from your team removes guesswork and cuts false positives. ### Does a blocked cross-account request prove the endpoint is safe? No. It proves that one request was blocked. Other methods, other parameters, older API versions and bulk endpoints can behave differently. The report states which paths were tested. ## Sources - [OWASP API Security Top 10 2023: API1 Broken Object Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa1-broken-object-level-authorization/) - [OWASP API Security Top 10 2023: API5 Broken Function Level Authorization](https://owasp.org/API-Security/editions/2023/en/0xa5-broken-function-level-authorization/) - [OWASP Web Security Testing Guide v4.2: WSTG-ATHZ-04 Testing for Insecure Direct Object References](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/05-Authorization_Testing/04-Testing_for_Insecure_Direct_Object_References/) - [About Excession Labs](https://excessionlabs.ai/about/) --- # Human-in-the-loop pentesting: approval rules for AI agents Source: https://aipentestservices.com/guides/human-in-the-loop-pentesting/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 Human-in-the-loop pentesting: set allow, ask and deny rules for an AI agent, decide which actions need approval, and where people review. Includes a rule table. > **Short answer:** Human-in-the-loop pentesting puts people at fixed points in an AI-run test. Each tool gets a rule: allow (runs alone), ask (waits for approval) or deny (blocked). Humans set scope and rules before the test, approve risky actions during it, and check the evidence for each finding before the report. A rule table you can adapt is included. Human-in-the-loop pentesting means that people hold fixed control points in a test run by an AI agent. They set the scope and tool rules before the test, approve risky actions during it, and check each finding before it reaches the report. The agent does the repetitive work. People keep the decisions that carry risk. ## Why does an AI pentest agent need human control points? An agent acts on its own reading of responses, so it can take a harmful action that it thought was safe. OWASP names this class of risk in its LLM list. The 2026 edition lists Excessive Agency as LLM03: a system that can take damaging actions on unexpected, ambiguous or manipulated model output. A pentest agent has real tools. It can send requests, run scripts and submit forms. A wrong guess against a live system can delete data, send email or spend money on a paid API. Control points limit what a wrong guess can do. Each tool the lab's AI agents can use has a rule, and Excession Labs sets the rules for each scope. The three values are: - Allow: the tool runs on its own. - Ask: the tool waits for a person to approve the exact call. - Deny: the tool is blocked. The rule applies to the tool and, in a good setup, to the target and the kind of action. A read-only request to an in-scope host can be "allow". The same tool aimed at a bulk write can be "ask". A request to a host outside the written scope is "deny". ## Which actions should need approval? Put an action under "ask" when it has side effects that cannot be undone, costs money, touches people, or is hard to bound. Adapt the starting set below to your scope document. | Action | Suggested rule | Reason | |---|---|---| | Read-only requests to in-scope hosts | Allow | Low risk; the core of the work | | Comparison of responses between test accounts | Allow | No change to the target | | Write or delete on test-owned records | Allow, with test-data marker | Needed for read-back proof; records belong to the tester | | Write or delete on records the tester does not own | Deny | Could harm real data | | File upload tests | Ask, bounded | Storage cost and malicious-file risk | | Password guessing or login brute force | Ask, with a stated cap | Can lock accounts; cost must be stated | | Any action that sends email or SMS | Ask | Reaches real people and costs money | | Calls to paid third-party APIs | Ask, with a cost cap | Spend lands on your account | | Heavy load, fuzzing at volume | Ask, with a rate cap | Can degrade the service | | Hosts or paths outside written scope | Deny | No authorization | | Exploit development beyond proof | Deny unless scoped | Proof of effect is the goal, not damage | | Production access in a first run | Ask for each step, or use staging | See the [safety page](/safety/) | Tests of uploads, password guessing, email sending and paid third-party APIs are bounded in our reports, and the report states their cost. ## Where do humans review the work, and how do approvals stay useful? Five review points apply. 1. Scope and authorization. Before any test, the system owner confirms the scope in writing, and Excession Labs agrees it with you. 2. Rule review. Before the run, an operator checks the allow, ask and deny rules against the scope. 3. Live approvals. During the run, a person approves or rejects each "ask" call. 4. Evidence review. Before the report, Excession Labs checks the evidence for each finding and writes the report. 5. Report review and retest. You review the report. Fixed findings can be retested. Point 4 controls false positives. [AI pentesting false positives](/guides/ai-pentesting-false-positives/) has the checklist. A good approval prompt shows the exact request and its likely effect. A person cannot judge "run upload test". They can judge this: > **Sample approval request:** ```text > ASK: http_request > Target: https://staging.harbor.example.com/api/notes/import (in scope) > Method: POST, 25 requests, 1 per second > Body: test-owned CSV, 10 KB, marked "TEST DATA" > Purpose: check that import enforces the 1 MB size limit > Side effect: creates up to 25 notes in account test-a > Cleanup: delete the notes after the check > Approve / Reject / Edit limits > ``` The prompt lets the person lower the limits. A tool that shows only "approve command?" invites people to click through. Approval fatigue happens when people see too many prompts and stop reading them. Three practices keep the ask list useful. - Allow safe, repeated actions. Do not ask for every read. - Group related calls into one approval with a stated cap. - After the first run, move actions that people always approved unchanged to "allow", but only if their risk is low. OWASP lists human-agent trust problems in its [Top 10 for Agentic Applications](https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/) (ASI09 Human-Agent Trust Exploitation). That entry covers agents that people over-trust. A tired approver is the same weakness in a pentest. ## What should you ask a provider about human control? Ask these questions of any AI pentest provider. - Who sets the tool rules, and can I see them? - Which actions wait for approval, and who approves? - What stops the agent from leaving the scope? - Who checks the evidence for each finding? - What does the report say about actions that were refused or skipped? [How AI pentesting works](/how-it-works/) answers these for Excession Labs. [AI versus manual pentesting](/ai-vs-manual-pentesting/) covers when a person must lead the work. ## Questions ### Does human-in-the-loop slow the test down? Some. Approvals add waiting time at the points where a mistake would cost most. Most requests, such as reads and comparisons, run under allow rules. Good rule design keeps the ask list short, so people review the few actions that matter. ### Who should approve actions during a test? A person who knows the scope and can say yes or no for the system owner. The agreement names that contact before testing starts. A tester who cannot reach the contact should stop the risky action and move to other work. ### What happens when the agent reaches something out of scope? It stops that line of work. Out-of-scope hosts and actions sit under deny rules, and the finding is noted for the operator. Scope changes need a written update from the system owner. ### Is approval fatigue a risk? Yes. If everything asks, people approve without reading. Keep ask rules for actions with real side effects, and show the exact request the agent wants to send. ## Sources - [About Excession Labs](https://excessionlabs.ai/about/) - [OWASP Top 10 for LLM Applications 2026: LLM03 Excessive Agency](https://github.com/GenAI-Security-Project/GenAI-LLM-Top10/tree/main/2026/final) - [OWASP Top 10 for Agentic Applications: announcement (9 December 2025)](https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/) --- # AI pentesting guides Source: https://aipentestservices.com/guides/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 Guides on AI-assisted penetration testing: how agents test web apps and APIs, how findings are validated, where AI falls short, and how to judge results. Plain explanations of AI-assisted penetration testing for engineering and security teams. Each guide shows how the testing works in practice, where it needs a person, and how to check the results. - [AI pentest agents vs DAST scanners: what each does and what neither replaces](https://aipentestservices.com/guides/ai-pentest-agents-vs-dast-scanners/): AI pentest vs DAST: how a fixed-check scanner and an adaptive agent differ, what each finds, a comparison table and a seven-step way to test both on one build. - [AI pentesting false positives: why agents over-claim and how to validate](https://aipentestservices.com/guides/ai-pentesting-false-positives/): Why AI pentest agents report bugs that are not real, the evidence standard that stops it, and a validation checklist you can apply to any AI-generated finding. - [AI pentesting for startups: when it fits and what to prepare](https://aipentestservices.com/guides/ai-pentesting-for-startups/): AI pentest for startups: when AI-assisted pentesting fits a customer security review or launch, a readiness checklist to prepare, and what it will not give you. - [Evaluating an AI pentest report: signs of real validation](https://aipentestservices.com/guides/evaluating-an-ai-pentest-report/): How to evaluate an AI pentest report: check for requests, read-back proof, controls, evidence labels and limits. Includes a scorecard with no numeric scores. - [How agentic pentesting works: planner, workers, tools and evidence](https://aipentestservices.com/guides/how-agentic-pentesting-works/): How agentic pentesting works: a planner splits work, workers run tasks in parallel, tool rules gate actions, and each finding must link to evidence. - [How AI agents test authorization: differential tests across accounts](https://aipentestservices.com/guides/how-ai-agents-test-authorization/): How an AI pentest agent tests your app for IDOR and broken authorization: replay requests across accounts, compare responses, and prove the effect by read-back. - [Human-in-the-loop pentesting: approval rules for AI agents](https://aipentestservices.com/guides/human-in-the-loop-pentesting/): Human-in-the-loop pentesting: set allow, ask and deny rules for an AI agent, decide which actions need approval, and where people review. Includes a rule table. - [Is AI pentesting safe in production? Rules, limits and a checklist](https://aipentestservices.com/guides/is-ai-pentesting-safe-in-production/): Is AI pentesting safe in production? Limits for destructive actions, data, request rate and third-party cost, plus tool rules, test data and stop conditions. - [Pentesting in CI/CD: which releases should trigger a test](https://aipentestservices.com/guides/pentesting-in-ci-cd/): Pentesting in CI/CD: which releases need a test, how to test on staging, how to send scope deltas and how to retest fixes. Includes a release trigger table. - [Testing signed-in flows with AI agents: accounts, sessions and MFA](https://aipentestservices.com/guides/testing-signed-in-flows-with-ai-agents/): Authenticated penetration testing with an AI agent: test accounts per role, session handling, MFA and SSO options, and why real user credentials stay out. - [What is AI penetration testing? Three kinds, and what each can do](https://aipentestservices.com/guides/what-is-ai-penetration-testing/): What is AI penetration testing? It covers AI-enhanced scanners, autonomous agents and AI-assisted humans. See what each does and where it stops. - [Where AI pentesting falls short: limits you should know before you buy](https://aipentestservices.com/guides/where-ai-pentesting-falls-short/): AI pentesting limitations: business context, novel chains, unwritten authorization rules, fragile systems, social tests, nondeterminism, and how we handle each. --- # Is AI pentesting safe in production? Rules, limits and a checklist Source: https://aipentestservices.com/guides/is-ai-pentesting-safe-in-production/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 Is AI pentesting safe in production? Limits for destructive actions, data, request rate and third-party cost, plus tool rules, test data and stop conditions. > **Short answer:** AI pentesting can be run safely on production only with limits set before testing. Agree written scope, set allow, ask and deny rules for tools, use test-owned accounts and records marked as test data, bound uploads, password guessing, email and paid API tests, and define stop conditions. Use staging for risky checks. No test removes all risk. AI pentesting is safe on a production system only when you set limits before the test starts. The limits cover which actions the agent may take, which data it may touch, how fast it may send requests, and when it must stop. No test removes all risk. The controls are written scope, tool rules, test-owned data, bounded costs and stop conditions. Use staging for anything risky. The [safety page](/safety/) states our position. ## What can go wrong in a production pentest? Four things can go wrong: destructive actions, data exposure, load, and third-party cost. Each has a matching control. | Risk | Example | Control | |---|---|---| | Destructive action | Agent deletes or changes a real record while proving a bug | Destructive proofs only on test-owned accounts and records, marked as test data | | Data exposure | Test pulls real customer records into logs | Scope to test accounts. Read-only requests where possible. Store only what the finding needs | | Load | High request rate slows the service | Rate limits in the rules. Stop conditions on errors and latency | | Third-party cost | Test sends email or calls a paid API many times | Bounded tests. The cost is stated in the report | An agent works fast, and a mistake that a human makes once can repeat many times in parallel. For this reason the controls sit in the harness and in the instructions to the model. ## How do tool rules and test-owned data keep production safe? Each tool the lab's AI testing agents can use has a rule: allow, ask or deny. Allow runs on its own. Ask waits for approval. Deny is blocked. Excession Labs sets the rules for each scope. Use this mapping as a start: - Allow: read-only requests to in-scope hosts, reading client-side JavaScript, listing public pages. - Ask: any request that changes state, account creation, file uploads, password-guess runs, email-sending flows, calls to paid third-party APIs. - Deny: hosts outside scope, tools that change infrastructure, any action on real customer accounts, anything on your forbidden list. Approval slows the test. Move a tool from ask to allow only after you trust its behavior in that scope. See [human-in-the-loop pentesting](/guides/human-in-the-loop-pentesting/) for where approvals fit and [how agentic pentesting works](/guides/how-agentic-pentesting-works/) for the harness. Test-owned data lets the tester prove a destructive effect without harming a real user. Create the accounts and records for the test. Mark them as test data. Prove writes and deletes only against them. A cross-account proof needs two test accounts. The tester acts as account A against a record that belongs to account B, then reads the result back from B's session. Count the proof only when the read-back from B's session shows the change; a "success" response alone is not enough. Reproduction scripts should be read-only where possible. Anyone who reruns them must have authorization and use test-owned identifiers. Never run a script against identifiers that belong to real users. ## How do you bound costs and stop a test? Set a request budget for each test class and write it into the scope. OWASP lists [unrestricted resource consumption](https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/) as API4:2023 and names the cost of SMS, email and paid services as a risk. A test can trigger the same cost. Bound these four classes of test: 1. Uploads: a fixed number of files with a size cap. 2. Password guessing: a small list against a test account, with a lockout plan. 3. Email and SMS flows: a few messages to inboxes you own. 4. Paid third-party APIs: a call budget in currency or count. We bound these tests and state their cost in the report. A stop condition is a rule that halts the test without debate. Write them in advance. Name who can call a stop and how it is confirmed. Good stop conditions: - Error rate or latency passes the threshold you set. - The agent reaches a record that is not test-owned. - An alert from your monitoring that you marked as a stop alert. - A request would leave the agreed scope or hit a denied host. - Your named contact asks for a stop. After a stop, the team reviews the saved requests before the test resumes. Saved requests carry timestamps, so the review can follow the order of events. ## Production safety checklist > **Production safety checklist:** Use this before any AI pentest on a live system. > > **Authorization and scope** > - [ ] Written authorization from the system owner. > - [ ] Written scope: hosts, roles, forbidden actions. > - [ ] Provider rules for security testing checked. > > **Data** > - [ ] Test accounts per role, plus two in different tenants. > - [ ] Test records marked as test data. > - [ ] No real customer data in scope for write or delete proofs. > > **Tools** > - [ ] Every tool set to allow, ask or deny. > - [ ] State-changing tools set to ask. > - [ ] Out-of-scope hosts denied. > > **Limits** > - [ ] Request rate set. > - [ ] Upload, password-guess, email and paid-API tests bounded. > - [ ] Cost cap written down. > > **Stop** > - [ ] Stop conditions written. > - [ ] Named contact reachable during the test. > - [ ] Rollback and backup confirmed. > > **After** > - [ ] Test data removed or kept by agreement. > - [ ] Reproduction scripts handled per authorization. ## When should you test staging instead? Choose staging when the check could change or delete data, send many messages, or stress a fragile service. Staging carries less risk to customers, but it only helps if its code, configuration and roles match production. When staging differs, say where. Then agree a bounded production check for the gap, using test-owned data. The [CI/CD guide](/guides/pentesting-in-ci-cd/) shows how to set up a staging copy and send a scope delta. [NIST SP 800-115](https://csrc.nist.gov/pubs/sp/800/115/final), published in 2008 and still listed as final, also advises planning and rules of engagement before technical testing. That advice is old and still applies to an agent. The full service flow is on the [how it works](/how-it-works/) page. ## Questions ### Can an AI pentest delete my production data? It can if the rules allow destructive actions on real records. Set destructive tools to ask or deny. Prove destructive impact only on test-owned accounts and records marked as test data. Never point such a test at customer data. ### Who stops the test if something goes wrong? Both sides can. You name a contact who can call a stop. The operator can halt the agent at any time. Agree the stop conditions in writing before the test starts, and agree how a stop is confirmed. ### Should I tell my hosting provider? Check your provider's rules for security testing first. Policies differ by provider and change over time. Read the current policy page, and keep the written authorization from the system owner for your own records. ### Is staging always safer? Usually, because a mistake there does not reach customers. It is only useful if staging matches production. When it does not, agree a bounded production check with test-owned data. ## Sources - [NIST SP 800-115: Technical Guide to Information Security Testing and Assessment (2008, final)](https://csrc.nist.gov/pubs/sp/800/115/final) - [OWASP API Security Top 10 2023: API4 Unrestricted Resource Consumption](https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/) --- # Pentesting in CI/CD: which releases should trigger a test Source: https://aipentestservices.com/guides/pentesting-in-ci-cd/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 Pentesting in CI/CD: which releases need a test, how to test on staging, how to send scope deltas and how to retest fixes. Includes a release trigger table. > **Short answer:** Do not run a pentest on every commit. Test after releases that change authentication, authorization, data access, payments, file handling or public API surface. Use a staging copy with test accounts, send the tester a scope delta for each release, and retest fixes. Excession Labs offers recurring testing after releases, with scope agreed in writing. Pentesting in CI/CD ties security testing to your release process. You choose which releases need a test, give the tester a staging copy and a list of changes, and retest the fixes. A full pentest on every commit is outside this model. Excession Labs does not offer automated per-commit testing. We offer recurring testing after releases, with the scope for each round agreed in writing. See [per-release testing](/per-release-testing/). ## Which releases warrant a pentest? A release warrants a test when it changes who can do what, or what data leaves the system. Small copy and style changes do not. Copy this table into your release checklist. > **CI/CD trigger decision table:** | What changed in the release | Test? | What to hand the tester | > |---|---|---| > | Login, sessions, password reset, MFA, SSO | Yes | Changed flows, test accounts per role | > | Roles, permissions, tenant or org logic | Yes | Role matrix, new and changed endpoints | > | New or changed API endpoints that read or write user data | Yes | OpenAPI diff, auth requirements | > | Payments, billing, plans, entitlements | Yes | Test mode details, price and plan list | > | File upload, import, export, webhooks | Yes | Limits, allowed types, target hosts | > | New third-party integration with data flow | Yes | What data goes out, which keys are used | > | Infrastructure or gateway change (CORS, headers, WAF) | Yes, small | The config diff | > | Dependency update with no behavior change | Usually no | Rely on dependency scanning | > | UI text, styling, internal refactor with tests passing | No | Nothing | > | Hotfix for a known security bug | Retest only | The finding ID and the fix commit | Use the table as a default, then adjust. If you are unsure, ask what an attacker would gain from the change. Compliance programs may add their own timing. PCI DSS 4.0 requirement 11.4, for example, covers penetration testing methodology (see the [PCI SSC summary of changes](https://listings.pcisecuritystandards.org/documents/PCI-DSS-v3-2-1-to-v4-0-Summary-of-Changes-r1.pdf)). Read the text with your assessor. Do not assume a test satisfies a standard. ## What belongs in CI, and how should you test on staging? A pentest is not a unit test. A pipeline check runs in minutes and has a fixed answer. A pentest needs authorization, a scope, judgment and review of the evidence. Match each check to its job: - Every commit: unit tests, static analysis, dependency checks, secret scanning. - Every deploy to staging: smoke tests, authorization regression tests that your team writes. - After a risky release: a scoped pentest on staging. - After a fix: a retest of that finding. Authorization tests that your team writes for CI catch many regressions. A test that logs in as user A and requests user B's record should fail the build if it returns data. The pentest then looks for what those tests missed. Test on staging when the risky checks could harm production data. Staging should match production in code, configuration and roles. If it does not, say where it differs. A finding on staging that does not exist in production wastes time, and a clean result on a staging copy with different settings can mislead you. Prepare four things: 1. A staging URL that matches the release you want tested. 2. Test accounts for each role, plus two accounts in different tenants. 3. Synthetic data, not copies of customer data. 4. A rollback plan and a named contact who can answer during the test. Written authorization comes first. We test only with written authorization from the system owner. If your staging runs on a cloud or SaaS you do not own, check that provider's rules for security testing before you start. ## How do you send a scope delta and retest fixes? A scope delta is the difference between the last tested state and the release to test. It tells the tester where to look first. Your CI/CD system already holds most of it. Send these items with each request: - The release tag or commit range. - New, changed and removed endpoints (an OpenAPI diff works well). - Changed roles, permissions or feature flags. - New integrations, webhooks or file handlers. - Known issues you do not want re-reported. The tester still checks nearby areas, because a change to one endpoint can break a control on another. The delta focuses effort. It limits the report to the listed items only if the written scope says so. The [OWASP Web Security Testing Guide](https://wstg.owasp.org/) lists the areas that sit near a change: session management, authorization, input validation and business logic. Retest each fix with the same request that proved the finding, plus controls. Excession Labs can retest fixed findings. Agree in the written scope whether a retest is free and how long it takes. A retest answers three questions: 1. Does the original effect still happen? (It should not.) 2. Do the controls still hold? (Nonexistent IDs, another account's token, anonymous callers.) 3. Did the fix open a nearby path? (Same class of check on sibling endpoints.) Link each fix commit to its finding in your tracker. When the retest passes, close the ticket with the evidence reference. The [retesting page](https://penetrationtestservices.com/retesting/) on penetrationtestservices.com shows what a retest result looks like. ## What does a release flow with pentest triggers look like? This flow works for most teams: 1. Merge and deploy to staging. Fast checks run. 2. The release manager checks the trigger table. 3. If a trigger applies, send the scope delta and confirm authorization. 4. The test runs on staging with test accounts. 5. You fix findings. You ask for a retest. 6. You release to production when the high-severity items are fixed or accepted. 7. For a risk that staging cannot show, agree a bounded production check with test-owned data. The [production safety guide](/guides/is-ai-pentesting-safe-in-production/) gives the rules. For the price drivers of recurring work, see [pricing](/pricing/). ## Questions ### Can I run an AI pentest on every pull request? We do not offer automated per-commit testing. Use fast checks, such as tests and static analysis, on each commit. Use a pentest for releases that change risk. A scoped test needs written authorization and review of the evidence. ### Should I test staging or production? Prefer staging for risky or destructive checks. Use production only when staging differs too much from it. Production tests use test-owned accounts and data, with bounded tests and stop conditions. ### What is a scope delta? A scope delta is the list of what changed since the last test: new endpoints, changed roles, new integrations and removed controls. It lets the tester focus on the change, not on the whole app again. ### How do I know a fix worked? Retest the finding with the same request that proved it, plus controls. A fix is confirmed when the original effect no longer occurs and the working protections still hold. ## Sources - [OWASP Web Security Testing Guide](https://wstg.owasp.org/) - [NIST SP 800-115: Technical Guide to Information Security Testing and Assessment (2008, final)](https://csrc.nist.gov/pubs/sp/800/115/final) - [PCI SSC: PCI DSS v3.2.1 to v4.0 Summary of Changes (requirement 11.4)](https://listings.pcisecuritystandards.org/documents/PCI-DSS-v3-2-1-to-v4-0-Summary-of-Changes-r1.pdf) --- # Testing signed-in flows with AI agents: accounts, sessions and MFA Source: https://aipentestservices.com/guides/testing-signed-in-flows-with-ai-agents/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 Authenticated penetration testing with an AI agent: test accounts per role, session handling, MFA and SSO options, and why real user credentials stay out. > **Short answer:** Authenticated testing lets an AI pentest agent reach the parts of an app behind login. Give it test accounts for each role, created for the test and labeled as test data. Pick an MFA and SSO option that keeps the agent signed in without weakening production controls. Never give the agent a real user's credentials. To test signed-in flows with an AI agent, give it dedicated test accounts, one for each role, and tell it how to keep its session alive. Most of an application's risk sits behind login: records, settings, payments and admin tools. An agent that tests only the public pages sees little of it. Never use real user credentials in this setup. ## Why does signed-in testing matter, and which test accounts does the agent need? Signed-in testing reaches the features where access control, session handling and business rules apply. An anonymous test reaches the login page and the marketing site. Authorization flaws, such as one user reading another user's record, appear only when the caller is signed in. Our method compares anonymous and signed-in callers, and reads back from a second account to prove cross-account effects. The agent needs a set of accounts that matches your role model. Create them before the test, for this purpose only. | Account | Purpose | |---|---| | Admin (one) | Reach admin functions; used as the baseline for what is restricted | | Standard user A | Owns test records; the "owner" in read-back checks | | Standard user B (same role as A) | Tests access to A's records | | Low-privilege or read-only user | Tests function-level limits | | Second tenant, user C | Tests tenant isolation | | Unauthenticated | Baseline for every request | Each account should hold some test data, so cross-account reads have something to read. Mark the data as test data. Write the accounts and their roles into the scope document. ## What session handling does the agent need? The agent needs a way to sign in, notice when a session ends, and sign in again. Web apps and APIs end sessions in different ways, and an agent that misses an expiry will report errors as findings. 1. Record the login flow. Give the sign-in steps, or the token endpoint for an API. 2. Name the session carrier: a cookie, a bearer token, or a custom header. 3. Define expiry. State the lifetime and refresh rules, so the agent renews the session instead of failing. 4. Keep sessions apart. Each account gets its own session store, because a mix-up between accounts invalidates the differential test. 5. Check for silent logout. If a response suddenly returns a login page with `200`, the agent must treat the session as lost. Log it in the run log. Do not report it as a finding. 6. Test the session itself. Logout, token reuse after logout and cookie flags are valid tests. See [OWASP API2:2023 Broken Authentication](https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/). State-changing requests may need an anti-CSRF token. The agent must fetch a fresh token per session. Browser-observed checks cover this: the [WSTG CSRF test](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery/) describes it, and we show CSRF and stored XSS results in a real browser. ## How do you handle MFA and SSO? Choose an option that lets the agent sign in without lowering the controls on real accounts. OWASP states that "MFA is a critical security control, and is recommended for all applications", so turning it off for everyone is wrong. | Option | How it works | Use when | Watch for | |---|---|---|---| | Test account with TOTP secret shared with the tester | The tester holds the seed and generates codes | You want to keep MFA on in the test environment | Store the seed in a secrets store; rotate after the test | | MFA waived for named test accounts in staging | An allow-list skips the second factor for the listed accounts | Staging, where the MFA flow is not in scope | The test then does not cover the MFA flow; say so in the report | | Pre-issued session or token | You issue a session for each test account | SSO or passkeys block automation | Short lifetime; the login path is untested | | Test identity provider tenant | A separate SSO tenant with test users | Apps with SAML or OIDC login | Config must match production, or the result misleads | | Self-sign-up by the agent | The agent creates its own accounts | Sign-up is in scope | Sends email and creates records; needs approval and bounds | If the login and MFA flow is itself in scope, test it on purpose with accounts you control. OWASP also notes that "account recovery is just an alternate way to authenticate so it should be no weaker than regular authentication". Test password reset and recovery separately. ## How do you keep credentials safe and scope signed-in testing? Never give an agent real user credentials. They put real people and data at risk, and they break the test's own safety rules. The scope covers systems and test-owned accounts, and a real user has not agreed to a test. A write or delete during testing would change a real person's data. Credentials in an agent's logs and saved evidence also get copied into more places. Destructive proofs use only test-owned accounts and records, marked as test data. The [human-in-the-loop pentesting](/guides/human-in-the-loop-pentesting/) guide covers the rule set, and the [safety page](/safety/) covers scope and stop conditions. Treat test credentials as secrets, even though the accounts are not real users. 1. Create accounts for the test only, with distinct email addresses on a domain you control. 2. Pass credentials to the tester through a secrets manager or an encrypted channel, not through chat or tickets. 3. Keep credentials out of saved evidence. Replace session values with placeholders in reports. 4. Give the accounts the lowest rights that match the role. 5. Set an end date. Disable the accounts and revoke tokens when the test ends. 6. Run the test in staging when you can, with data that is not real. The scope should name each account and role, how to sign in, how MFA is handled, who to contact when a session breaks, and the clean-up step. Excession Labs agrees the scope with you in writing before testing, and written authorization from the system owner comes first. [How AI agents test authorization](/guides/how-ai-agents-test-authorization/) has a worked example of the test itself. [How AI pentesting works](/how-it-works/) covers the whole flow. To ask about a small, scoped test, see the [pilot page](/pilot/). ## Questions ### How many test accounts should we provide? At least one per role, plus a second account in each role that holds data. The second account lets the agent test whether one user can reach another's records. Add a second tenant if your app has tenants. ### Should we turn MFA off for the test? Not in production. Prefer a test account with a known second factor the tester can use, or a staging copy where the rule is changed on purpose. Say so in the scope so the report notes it. ### What do we do with the accounts after the test? Disable or delete them, and reset any test-owned data. Rotate any API keys or tokens you issued. Write the clean-up step into the scope, so it does not depend on memory. ### Can the agent sign up its own accounts? Only if the scope allows it. Self-sign-up can send email, create records and trigger fraud checks. Under our rules, tests that send email are bounded and need approval. ## Sources - [OWASP Multifactor Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html) - [OWASP Web Security Testing Guide v4.2: WSTG-SESS-05 Testing for Cross Site Request Forgery](https://wstg.owasp.org/v4.2/4-Web_Application_Security_Testing/06-Session_Management_Testing/05-Testing_for_Cross_Site_Request_Forgery/) - [OWASP API Security Top 10 2023: API2 Broken Authentication](https://owasp.org/API-Security/editions/2023/en/0xa2-broken-authentication/) --- # What is AI penetration testing? Three kinds, and what each can do Source: https://aipentestservices.com/guides/what-is-ai-penetration-testing/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 What is AI penetration testing? It covers AI-enhanced scanners, autonomous agents and AI-assisted humans. See what each does and where it stops. > **Short answer:** AI penetration testing is security testing of a web app or API in which an AI model plans or runs part of the work. The term covers three different things: scanners with AI features, autonomous or agentic testers, and humans who use AI tools. They differ in who decides the next test and who checks the result. AI penetration testing is security testing of a web application or API in which an AI model plans, runs or reviews part of the work. The label covers three different kinds of product and service. Identify which kind you are looking at before you compare prices or results. ## What are the three kinds of AI penetration testing? The three kinds differ in who chooses the next test and who decides that a result is real. | Kind | Who chooses the next test | Who judges the result | Typical output | |---|---|---|---| | AI-enhanced scanner | A fixed check list, with AI used to rank, deduplicate or explain | The tool, with a confidence score | A findings list | | Autonomous or agentic tester | An AI agent, from what it saw in earlier responses | The agent, then (in a controlled design) a human | Findings with evidence | | AI-assisted human testing | The human tester | The human tester | A written report | The kinds blend in practice: a vendor can sell an agent whose findings a human reviews. For each finding, ask who looked at the raw request and response before it reached you. An AI-enhanced scanner is a vulnerability scanner that adds a model to a fixed engine. The model might write better payloads, group duplicate alerts, or explain a finding in plain words. The scan itself still follows a defined set of checks. [OWASP describes dynamic scanners](https://owasp.github.io/www-project-devsecops-guideline/latest/02b-Dynamic-Application-Security-Testing) as black-box tools that inject payloads into a running application. [AI pentest agents versus DAST scanners](/guides/ai-pentest-agents-vs-dast-scanners/) covers the difference. An agentic tester is a program in which a model runs a loop: it reads a response, picks the next request, calls a tool, and records what happened. A planner can split the engagement into tasks, and several workers can run the tasks at the same time. "Autonomous" describes the loop only. Real engagements add scope limits, tool rules and review around it. See [how agentic testing is built](/guides/how-agentic-pentesting-works/). In this kind, a human pentester owns the engagement and uses AI tools for single tasks. Examples are reading a large JavaScript bundle, drafting a script, or summarizing a long response log. The human decides what to test and what to report, so the speed gain is real but limited by the human's time. ## What can AI penetration testing do, and where does it stop? AI agents do best on work that is repetitive, well defined and checkable. They can repeat the same request across many roles, endpoints and parameters without tiring, read client-side code for hidden routes, and compare what an anonymous caller and a signed-in caller receive. Authorization testing is a good fit because the procedure is mechanical: log in as two accounts, replay each request with the other account's identifiers, and compare. [How AI agents test authorization](/guides/how-ai-agents-test-authorization/) has a worked example. AI agents are weaker where the answer depends on context that is not in the traffic. Three limits stand out. 1. Business rules the agent cannot see. An agent does not know that a refund must never exceed the order total unless the rule is written down or visible in the app. 2. Novel attack chains. Chaining several small weaknesses into one impact still needs creative judgment. Agents sometimes manage it, but not reliably. 3. Proof discipline. Language models can state that a request "succeeded" when nothing changed. Without strict evidence rules, this produces false findings. See [AI pentesting false positives](/guides/ai-pentesting-false-positives/) and [where AI pentesting falls short](/guides/where-ai-pentesting-falls-short/). ## What do public benchmark results tell you? Public results show that AI agents can find real bugs, but each tests a specific target with its own scope. None tells you how an agent will do on your application. > **Public results, with dates and scope:** - XBOW and HackerOne. On 24 June 2025 XBOW wrote that "for the first time in bug bounty history, an autonomous penetration tester has reached the top spot on the US leaderboard". The claim covers the US leaderboard, not the global one. XBOW also states that its security team reviewed findings before submission to comply with HackerOne's policy on automated tools. This is a vendor claim, from the vendor's own blog. > - DARPA AIxCC. In the final, announced 8 August 2025, DARPA reported that the competing systems found 54 synthetic vulnerabilities in 63 challenges and patched 43 of them. The challenges were memory-safety style bugs in open-source code, not web application logic. > - CyberGym. A 2025 research benchmark of 1,507 real vulnerabilities in 188 software projects. Its abstract reports that the top combinations reached about a 20% success rate on the models tested then. Newer models would score differently. Those benchmarks do not measure authorization and business-logic bugs in your application. ## How does Excession Labs use AI, and how should you evaluate an AI penetration test? Excession Labs is a security lab, and its AI testing agents run test tasks in parallel. Each tool the agents can use has a rule: it runs on its own (allow), waits for approval (ask), or is blocked (deny). Excession Labs sets the rules for each scope. A task is done only when each finding links to its evidence. Excession Labs agrees the scope with you in writing, checks the evidence for each finding, and writes the report. [How AI pentesting works](/how-it-works/) walks through each step, and the [example assessment](/example-assessment/) shows a labeled example, including a rejected false positive. For a market view of vendors, see the [comparison of automated pentesting tools](https://pentestcompare.com/guides/automated-pentesting-tools/) on pentestcompare.com. Excession Labs publishes that site and discloses it. Ask any AI pentest provider, including us, these four questions. 1. Who authorizes the scope, and how is it written? 2. Which actions run without approval, which wait for approval, and which are blocked? 3. What proves a finding: a status code, or a read-back of the changed state? 4. Who reviewed each finding before it reached me? A benchmark score answers none of the four. To read the output, see [how to evaluate an AI pentest report](/guides/evaluating-an-ai-pentest-report/). ## Questions ### Is AI penetration testing the same as an automated scan? No. A scanner runs a fixed set of checks. An agent chooses its next request from what it saw in the last response. That lets it follow a flow, but it also lets it over-claim, so the evidence standard matters more. ### Can an AI agent replace a human pentester? For some work, such as repeatable authorization and input checks, an agent does a lot. Scoping, business-logic judgment and review of findings still need people. Our model keeps a human review step for every finding. ### Do the benchmark wins prove an AI tool will find bugs in my app? No. Public results test specific targets: bug bounty programs, memory-safety bugs in open-source code, and CTF tasks. They say little about authorization and business logic in your own application. ### Do you need source code for AI penetration testing? Not for black-box testing. The agent works from the running app and its client-side code, as a tester would. Code review is a separate, optional kind of engagement. ## Sources - [XBOW: The Road to Top 1: How XBOW Did It (24 June 2025)](https://xbow.com/blog/top-1-how-xbow-did-it) - [DARPA news release on the AI Cyber Challenge final results (8 August 2025)](https://www.darpa.mil/news/2025/aixcc-results) - [OWASP DevSecOps Guideline: Dynamic Application Security Testing](https://owasp.github.io/www-project-devsecops-guideline/latest/02b-Dynamic-Application-Security-Testing) - [CyberGym: Evaluating AI Agents' Real-World Cybersecurity Capabilities at Scale (arXiv 2506.02548)](https://arxiv.org/abs/2506.02548) --- # Where AI pentesting falls short: limits you should know before you buy Source: https://aipentestservices.com/guides/where-ai-pentesting-falls-short/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 AI pentesting limitations: business context, novel chains, unwritten authorization rules, fragile systems, social tests, nondeterminism, and how we handle each. > **Short answer:** AI pentesting has limits. It lacks your business context, can miss novel multi-step chains, struggles when authorization rules are unwritten, needs care on fragile or rate-limited systems, cannot do social or physical tests, and gives different runs different paths. Excession Labs handles these with written scope, tool rules, evidence for each finding, and stated limitations in the report. AI pentesting has real limits. It does not know your business rules unless you write them down. It can miss a novel multi-step chain. It cannot test people or buildings. For each limit below, we say how Excession Labs handles it or that it is out of scope. A buyer who knows the limits before requesting a test reads the report better. ## What are the main limits of AI pentesting? AI pentesting is strong on repeatable, evidence-driven checks of web apps and APIs. It is weaker where the answer depends on context that is not in the traffic. The table lists six limits and our position on each. > **Limits table: what AI pentesting cannot do alone:** | Limit | Why it matters | How Excession Labs handles it | > |---|---|---| > | Business context | A tester must know what "wrong" means for your product | We agree scope in writing. You tell us which actions and data matter. Open questions go in "Limitations and open questions", not in confirmed impact | > | Novel multi-step chains | New attack paths may need creative links across features | Findings need evidence of a real effect. Inferred paths are labeled separately. We do not claim to find all chains | > | Unwritten authorization rules | The tool cannot read who should see what | Test with accounts per role. Compare anonymous and signed-in callers. You confirm the intended rules | > | Rate-limited or fragile systems | Heavy testing can cause outages or cost | Tool rules (allow, ask, deny). Bounded tests. Cost stated in the report | > | Social or physical access | Phishing, phone pretexts and building entry are not web traffic | Out of scope for this service | > | Model nondeterminism | Two runs can take different paths | Requests and responses saved with timestamps. Retest of a finding is supported | ## How do business context, novel chains and ambiguous rules limit results? Business context is what makes a response correct or wrong for your product. A scanner or agent can see that a request returned 200. It cannot know that a refund of a negative amount breaks your finance rules unless someone says so. Excession Labs handles this at scoping. We agree the scope in writing with you: assets, roles, test accounts and the actions you care about. Name your risky workflows, such as invitations, billing changes or exports, and we test them with evidence. A gap remains where we were not given a rule. The report states it under "Limitations and open questions", and it appears neither as a confirmed finding nor as a clean result. Novel multi-step chains are a second limit. AI finds them sometimes, but do not rely on it. A novel chain joins several small weaknesses in a way nobody has listed before. Human specialists with deep product knowledge often find these. Our evidence standard limits the damage of a wrong guess. A finding needs evidence of a real effect: a write is proven by reading the changed record back through another session, and a "success" response alone does not count. If a path is plausible but not reproduced, the report labels it as inferred, apart from the confirmed items. We do not claim that our AI agents find all vulnerabilities. If your risk is a high-value target with unusual logic, raise it on the call. The [AI vs manual pentesting](/ai-vs-manual-pentesting/) page explains when human specialist work fits better. Ambiguous authorization rules are a third limit. Authorization testing needs a rule to test against. "Users can only see their own invoices" is a rule. "Managers see what they need" is not. The tool cannot invent the missing part. The method uses differential tests. The agents compare anonymous and signed-in callers and reads back changes from a second account. Controls run next to each exploit request: nonexistent identifiers, wrong record types, another account's token. [How AI agents test authorization](/guides/how-ai-agents-test-authorization/) has a worked example. When two behaviors both look plausible, the report lists the question and you decide which behavior is intended. ## How do fragile systems, out-of-scope tests and nondeterminism limit results? Fragile systems can fail under normal test load. Rate-limited systems can block the tester, or charge you for each call. OWASP lists [unrestricted resource consumption](https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/) as a top API risk, so a rate limit is also something to test, with care. Each tool the agents can use has a rule: it runs on its own (allow), waits for approval (ask), or is blocked (deny). Excession Labs sets the rules for each scope. Tests of uploads, password guessing, email sending and paid third-party APIs are bounded, and their cost is stated in the report. If a system is very fragile, test a staging copy. The [production safety guide](/guides/is-ai-pentesting-safe-in-production/) has the stop conditions and a safety checklist. AI pentesting also cannot do social engineering or physical access tests. Phishing, phone pretexts, badge cloning and tailgating involve people and places, and web traffic does not show them. These tests are out of scope for aipentestservices.com, as are internal network tests and other work outside web apps and APIs. [NIST SP 800-115](https://csrc.nist.gov/pubs/sp/800/115/final) (published in 2008, still listed as final) treats social engineering as a separate technique from technical testing. Pick a provider for those tests on its own merits. Model nondeterminism is the last limit. A language model may take a different route on a second run, so two runs of the same scope may not find the same set of issues. A confirmed finding stays reliable, because each finding links to its evidence, with saved requests and responses and timestamps. You can replay them. Key evidence can carry a SHA-256 manifest, so you can check that the files did not change after the test. One clean run is not proof that nothing is there. Add coverage over time: test after meaningful releases and retest fixes. See [per-release testing](/per-release-testing/). ## What should you ask before buying an AI-assisted test? Ask these five questions of any provider, including us: 1. Which of my business rules did I give the tester, and where are they written? 2. What would a human specialist add for my riskiest workflow? 3. Which tools may run without approval, and which are blocked? 4. Where does the report list what was not tested? 5. Can I replay a finding from saved evidence? To check a finished report, see [how to evaluate an AI pentest report](/guides/evaluating-an-ai-pentest-report/). ## Questions ### Does AI pentesting replace a human tester? Not in every case. The lab's AI testing agents do the testing work under tool rules. Excession Labs agrees scope with you, checks the evidence for each finding and writes the report. Some work needs a human specialist. See the AI vs manual page for the split. ### Can AI pentesting find every vulnerability? No. No test finds every vulnerability, and we do not claim that our AI agents do. A report lists what was tested, what was proven and what stayed open. Treat a clean result as 'nothing found in this scope', not as 'secure'. ### Will two runs of the same test give the same result? Not always. Language models can choose different paths on different runs. Saved requests and responses let you check any finding again. A retest of a fixed finding is a separate, targeted check. ### Does AI pentesting include phishing tests? No. Social engineering, phishing and physical access tests are out of scope for this service. Ask a provider that offers them, and agree rules of engagement for those tests in writing. ## Sources - [NIST SP 800-115: Technical Guide to Information Security Testing and Assessment (2008, final)](https://csrc.nist.gov/pubs/sp/800/115/final) - [OWASP Web Security Testing Guide](https://wstg.owasp.org/) - [OWASP API Security Top 10 2023: API4 Unrestricted Resource Consumption](https://owasp.org/API-Security/editions/2023/en/0xa4-unrestricted-resource-consumption/) --- # How AI penetration testing works, step by step Source: https://aipentestservices.com/how-it-works/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 How AI pentesting works in nine steps, from scoping call to retest: written authorization, planner and workers, tool rules, evidence checks and the report. > **Short answer:** An AI-assisted pentest with Excession Labs runs in nine steps: scoping call, written scope and authorization, access setup, planning, parallel testing under allow, ask and deny tool rules, evidence-linked findings, evidence check by Excession Labs, report, then fixes and retest. You see a defined output at each step. An AI-assisted pentest follows nine steps. People agree the scope and check the evidence, and the lab's AI testing agents do the testing work in between. For each step we list what you see. ## What are the nine steps, and what happens before any test starts? Scoping callA short call to understand the app, the API and the reason for the test. You get questions and a list of what we need. Written scope and authorizationExcession Labs writes the scope. The system owner authorizes the test in writing. Testing starts only after this. Access setupYou provide test accounts, roles and the environment to test. We confirm access works. PlanningA coordinator splits the engagement into objectives and tasks. Parallel testingSeveral workers run tasks at the same time. Tool rules (allow, ask, deny) limit what they can do. Evidence-linked findingsA task finishes only when each finding links to its evidence. Evidence checkExcession Labs checks the evidence for each finding. ReportYou receive the written report in HTML, PDF and Markdown, with proof-of-concept scripts. Fixes and retestYou fix. We can retest the fixed findings. Three steps come before the first request: a call, a written scope and your access setup. Nothing runs against your system until the owner authorizes the test in writing. 1. Scoping call. We ask which apps and APIs matter, which roles exist, which data is sensitive and what the test is for. You get a short list of open questions. 2. Written scope and authorization. The scope names the hosts, the API base paths, the environments, the roles and the things we will not touch. It also states the bounded tests and their cost (for example email sending or paid third-party APIs). The system owner signs the authorization, and we test only with it. The [safety page](/safety/) lists the limits. 3. Access setup. You create test accounts for each role. Two accounts in the same role help prove cross-account effects. You also confirm the environment, any allowed IP addresses and a contact for stop requests. You then get a short access check: which accounts work, which roles they cover and what we could not reach. ## What does the agent do during testing? The agent plans, then runs tasks in parallel under tool rules. A task counts as finished only when every finding carries evidence. 4. Planning. The coordinator turns the written scope into objectives, such as "compare what each role can read" or "test the upload endpoint within the stated bound". It splits each objective into tasks. 5. Parallel testing. Workers take tasks and run them at the same time. Each worker keeps its own notes and findings. Tool rules apply to every call: | Rule | What it means | Example use | |---|---|---| | Allow | The tool runs on its own | Read-only HTTP requests inside scope | | Ask | The tool waits for approval | A state-changing request against test-owned data | | Deny | The tool is blocked | Anything outside the written scope | The operator sets the rules from the scope. 6. Evidence-linked findings. A task is done only when each finding links to its evidence. The evidence is a saved request and response with timestamps, or a browser-observed result. A write is proven by reading the changed record back through another session. A "success" response alone is not proof. Controls run next to the exploit request: a nonexistent identifier, the wrong record type, another account's token, anonymous versus signed-in. Controls that held are kept for the report. ## How do findings become a report, and who does what? Excession Labs checks the evidence for each finding and writes the report. The agent does not write the final report alone. 7. Evidence check. Excession Labs reviews each finding against its saved evidence. A finding that has no real effect shown does not become a confirmed finding. Inferred paths are labeled separately. Open questions go in "Limitations and open questions". 8. Report. You receive HTML, PDF and Markdown versions, plus proof-of-concept scripts. The report has these parts: - Project details: scope, assets and severity scale - Assessment method and safety constraints - Evidence labels ("Observed", "Browser-observed") - Executive summary with priority actions - Findings at a glance - One section per finding: description, impact, verified results, reproduction, remediation - Controls that held - Remediation plan - Limitations and open questions - Evidence index and appendix of reproduction scripts The severity scale has four levels: Critical, High, Medium and Low, each with a written definition. CVSS vectors are not added by default. If your program needs CVSS, say so during scoping. 9. Fixes and retest. Your team fixes the issues. You then ask for a retest of the fixed findings. The agents can rerun the original steps for a finding. For testing after later releases, see [per-release testing](/per-release-testing/). Each step has one owner: | Step | Done by | |---|---| | Scoping call, written scope | Excession Labs with you | | Authorization | The system owner | | Test accounts and environment | You | | Planning and parallel testing | The AI testing agents, under the tool rules | | Approval of "ask" actions | The operator | | Evidence check and report | Excession Labs | | Fixes | Your team | [AI vs manual pentesting](/ai-vs-manual-pentesting/) explains the split. The [example assessment](/example-assessment/) is a labeled sample run. For targets with special setup, read [AI pentesting for SaaS](/ai-pentesting-for-saas/) (tenants, roles, releases) and [authenticated web app testing](/authenticated-web-app-testing/) (signed-in roles and test accounts). Dates are agreed in the written scope. ## Questions ### Do I need to give the agent production access? No. You choose the environment during access setup. Many teams test staging with test accounts first. If you want production in scope, the written scope says so, and the safety rules for production apply. ### Who decides which tools the agent may run? The tool rules decide. Each tool runs on its own (allow), waits for approval (ask), or is blocked (deny). The rules are agreed as part of the scope, not left to the agent. ### What happens to a finding that cannot be proven? It does not become a confirmed finding. A task is done only when each finding links to evidence. A path that was inferred but not reproduced is labeled as inferred, and open questions go in a limitations section. ### Can I see progress during the test? Agree this in the scope. The steps above show what you receive at each stage. We do not state fixed timings, because they depend on the scope. --- # AI penetration testing services for web apps Source: https://aipentestservices.com/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 AI penetration testing services for web apps and APIs from Excession Labs. AI agents test, we review each finding's evidence, and we can retest your fixes. AI penetration testing services for web apps The lab's AI testing agents work through your web app and API as each user role you give them. Excession Labs, a security lab, checks the evidence for each finding, writes the report, and can retest your fixes. Apply for a free pilotRead the sample report Demonstration Pinecart (demo app): what the agent claimed, and what held up CandidateCheckVerdict buyer_A reads /v2/orders/ord_test_B1 and gets 200Nonexistent order returns 404. buyer_B's own session shows the same order and total.Confirmed, High /v2/me/orders?user=buyer_B returns 200The response holds buyer_A's own orders. The API ignores the parameter.Dropped Refund endpoint accepts a negative amountState-changing request: rule set to ask. Approved by Excession Labs, run on a test order.Confirmed, Medium Password guessing on /loginRule set to deny for this scope. Not run.Out of scope Every confirmed finding links to its requests, responses and controls. See the full example What we test Scope is written down before any request is sent. Out of scope here: internal networks, physical and social engineering tests, and testing of AI models themselves. For LLM apps and agents see AI red teaming. TargetHow we test it Web applicationsSigned-in flows for each role you provide, checked in a real browser where it matters (for example CSRF and stored XSS). See authenticated web app testing. REST and GraphQL APIsDirect HTTP requests, with or without documentation, plus review of client-side JavaScript bundles. Authorization between users and tenantsAnonymous and signed-in callers compared, and read-back from a second account to prove cross-account effects. See AI pentesting for SaaS. Sessions, login and account flowsTests with wrong or unsigned cookies and another account's token as controls. Input handling and uploadsInjection, stored scripts and file uploads, with bounded tests and the cost stated in the report. Admin panels and internal tools exposed to the webThe same role comparisons, run against the admin routes you put in scope. What you receive The report in HTML, PDF and Markdown, with proof-of-concept scripts An executive summary with priority actions, and findings at a glance For each finding: description, impact, verified results, reproduction steps and fix guidance Saved requests and responses with timestamps, labeled "Observed" or "Browser-observed" A "Controls that held" section, so fixes do not break protections that work A four-level severity scale (Critical, High, Medium, Low) with a written definition for each level A "Limitations and open questions" section, kept apart from confirmed impact A retest of fixed findings, on request The example assessment shows this layout on a fictional app. Who does what StepAI testing agentsExcession Labs Scope and authorizationAgrees it with you in writing Tool rulesFollows themSets them for your scope Mapping and testingRuns tasks in parallel, as each roleApproves actions that need approval EvidenceLinks each finding to requests, responses and controlsChecks the evidence ReportDrafts findings with reproduction stepsWrites and signs off the report RetestReruns the proof against your fixConfirms the result A language model can read a 200 response as a breach when the server ignored a parameter. That is why every candidate carries its requests, responses and controls, and why a person checks them. How false positives are kept out How a test runs The agents split the engagement into tasks and run them in parallel. Tool rules decide what they may do, and a task ends only when its findings link to evidence. Dates are agreed in the written scope. The full process Scope and authorizeHosts, roles, test windows and off-limits actions, signed by the system owner. Set the rulesEach tool runs, asks for approval, or is blocked. Costly and state-changing actions can wait for a person. Test in parallelWorkers test roles, endpoints and flows at the same time, and keep notes. Prove or dropControls and read-back from a second account decide what is real. Review and reportExcession Labs checks each finding's evidence and writes the report. Then we can retest your fixes. How pricing works, and how to bookWe quote after scoping and publish no price list. A short call comes first, then a written scope and proposal. You can start with a free pilot: a small written scope, authorized by the system owner, with every finding in scope delivered with evidence and fix guidance. Places are limited and reviewed by hand. We agree in writing which actions must never run, such as deleting data, sending real email or charging cards. See pricing, safety and control and testing after releases. Apply for a free pilotAI vs manual pentestingGuides ## Questions ### What is AI penetration testing? It is penetration testing in which an AI agent runs much of the testing work: mapping the application, sending requests as different users, comparing responses and collecting evidence. At Excession Labs, a security lab, our AI agents run the tests; the lab scopes the work, checks the evidence for each finding and writes the report. ### Is this the same as testing an AI chatbot? No. This site uses AI to test ordinary web applications and APIs. If you need your own LLM application, RAG system or agent tested for prompt injection and data leakage, see [airedteamingservices.com](https://airedteamingservices.com/). ### Does the agent run without supervision? It runs under tool rules we set for your scope. Each tool either runs on its own, waits for approval, or is blocked. State-changing and costly actions can require approval. Excession Labs checks the evidence before anything goes in your report. See [safety and control](/safety/). ### How is this different from a vulnerability scanner? A scanner sends known payloads and reports pattern matches. The agent works through the application as different users, follows multi-step flows and must link each finding to evidence. Read [AI pentest agents vs DAST scanners](/guides/ai-pentest-agents-vs-dast-scanners/). ### How much does it cost? We quote after scoping, because the work depends on the number of applications, roles, API endpoints and environments. You can start with a [scoped pilot](/pilot/). See [pricing](/pricing/). ### Do I still need a human pentester? Excession Labs checks the evidence for each finding and writes the report, so a person reviews every result. Business logic flaws need a person to reason about how the product should behave. Read [where AI pentesting falls short](/guides/where-ai-pentesting-falls-short/). ### Can I use the report for an audit? Ask your auditor. We cannot say that any auditor, customer or regulator will accept a report. --- # Per-release penetration testing after meaningful releases Source: https://aipentestservices.com/per-release-testing/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 Pentesting after each release: scope only the delta, retest earlier findings and get a report with evidence for that release. No fixed cadence is promised. > **Short answer:** Per-release testing means a scoped pentest after a meaningful release. We test the changed features and the paths they touch, and we retest findings from earlier work. You agree the delta in writing first. We do not promise a fixed cadence, always-on testing or a turnaround time. Per-release testing is a pentest of what changed. After a meaningful release, you send us the delta. We test the new and changed paths, retest earlier findings and send you a report for that release. ## When is a release worth testing, and what is a scope delta? A release is worth a test when it changes who can do what, or how data moves. Small copy and style changes do not need one. These do: - a new role or permission - a new API endpoint or version - a change to login, sessions, password reset or MFA - a payment, billing or entitlement change - a new file upload, import or export - a new integration or webhook - a change to tenant boundaries You and Excession Labs decide the trigger during scoping. We set no fixed cadence. A scope delta is the written list of what changed since the last test. It names the new or different features, endpoints, roles and environments, and the test focuses there. | Part of the delta | What you provide | What we test | |---|---|---| | New endpoints | Route list or API spec change | Authorization, input handling, error behavior | | Changed roles | Role matrix and a test account per role | Differential checks across roles | | Changed auth flow | Description of the new flow | Session handling, reset and token paths | | Unchanged areas | A statement that they are unchanged | A light check only if the scope asks for it | | Earlier findings | The previous report | Retest of fixed items | If the delta is wrong, the test can miss a change. The report states what the scope covered, so gaps show. ## How does the retest work, and what do you receive? We replay the original steps for each finding you say is fixed. The controls that held run again, so we can see that a fix did not break a working protection. The agents can rerun the original steps for a finding. The report for the release shows each earlier finding as retested and fixed, retested and still open, or not retested. We save the new request and response with timestamps as evidence for each retest. Each release report has the same structure as any other engagement, sized to the delta: scope, method, safety constraints, findings with evidence, controls that held, remediation plan and limitations. Formats are HTML, PDF and Markdown, plus proof-of-concept scripts. Excession Labs checks the evidence for each finding and writes the report. [How it works](/how-it-works/) covers the full sequence. ## What do we not promise, and how do you set it up? We do not promise testing on every deploy, always-on coverage, a start date, a turnaround time or a retest window. Each release test is a scoped job with a written scope, owner authorization and a report. The [safety page](/safety/) lists the limits. 1. Run a first full or pilot test, so you have a baseline report. 2. After a meaningful release, send the change list and any new test accounts. 3. We agree the delta in writing and confirm authorization. 4. The test runs under the usual [tool rules](/safety/). 5. You receive the report and fix. 6. You ask for a retest of the fixes. [Pentesting in CI/CD](/guides/pentesting-in-ci-cd/) covers test placement near your pipeline. [Testing signed-in flows with AI agents](/guides/testing-signed-in-flows-with-ai-agents/) covers role and session setup. [Pricing](/pricing/) lists what drives the quote. ## Questions ### Do you test every commit? No. This service targets meaningful releases, such as a new role, a new API area, a payment change or an auth change. You and Excession Labs agree which releases are worth a test. ### Is a retest included? We can retest fixed findings. Whether a retest is part of a quote is agreed during scoping. Ask for it in the scope. ### Can this run in my CI pipeline? The service is not a CI gate. A person agrees each scope, and Excession Labs checks the evidence. The CI/CD guide shows how teams place pentests near their release flow. ### How do I know what changed? You send release notes, a list of changed endpoints or a diff summary. We write the delta into the scope. If the change list is incomplete, the report says so. --- # Start an AI pentest pilot Source: https://aipentestservices.com/pilot/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 Apply for a free AI pentest pilot of your web app or API. Small written scope, written authorization, and every finding in scope with evidence and a fix. The pilot is the way to book an AI pentest with Excession Labs. It is a small, real test of your web application or API. We agree a narrow written scope, set the tool rules with you, and run the lab's AI testing agents against it under written authorization. You receive every finding in scope with evidence, reproduction steps and a fix, at no cost. Places are limited, and we review each application by hand. [Use the form on this page](https://aipentestservices.com/pilot/) After you apply, we reply by email to agree the scope, the test accounts and the rules. Testing starts only after the system owner signs the authorization. Related pages: [how it works](/how-it-works/), [safety and control](/safety/) and an [example assessment](/example-assessment/). --- # AI pentest pricing: what changes the quote Source: https://aipentestservices.com/pricing/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 AI pentest pricing: we quote after scoping, with no price list. Six factors change the quote: apps, roles, API size, environments, deadline and retests. > **Short answer:** Excession Labs quotes prices after scoping. We publish no price list. The quote depends on the number of apps, the number of roles, the size of the API, the environments in scope, your deadline and your retest needs. A free pentest pilot with a small written scope is available, with limited places. We quote after scoping and publish no price list. The quote depends on six things you can describe up front, so prepare them for the scoping call. ## What changes the quote? Six factors change the amount of testing work, and you know each one before the call. | Factor | Why it changes the quote | What to prepare | |---|---|---| | Number of apps | Each app has its own routes, logic and sign-in flow. | A list of apps and URLs | | Number of roles | Each role adds a set of differential checks. | A role list and a test account per role | | API size | More endpoints and objects mean more authorization checks. | An OpenAPI spec or a route list | | Environments | Staging, production and multiple tenants each need setup and care. | Which environment to test, and its limits | | Deadline | A tight date narrows what we can schedule. | A date, and the reason for it | | Retest needs | Retests add work after your fixes. | Whether you want one, and for which findings | Other things matter less but still count: bounded tests with a cost (uploads, email sending, paid third-party APIs), a need for CVSS vectors, and special report requirements. ## How do you get a price, and what is the free pilot? 1. Tell us about the apps, API and goal. Use the [contact page](/contact/) or the pilot form. 2. Join a short call. We ask about the six factors above. 3. Receive a written scope and proposal. The price is in the proposal. 4. The system owner authorizes the scope in writing. 5. Testing starts. [How it works](/how-it-works/) covers the steps after that. If you test after each meaningful release, [per-release testing](/per-release-testing/) explains how a scope delta keeps later tests smaller. The free pilot is a small, written-scope test. The system owner gives written authorization before testing. You receive every finding in the agreed scope with evidence and fix guidance, and the results have no paywall. Places are limited and we review each request by hand. We do not publish capacity, turnaround times or dates. You can apply on [the pilot page](/pilot/). The pilot shows you the report structure and evidence standard before you scope a larger job. ## What paid work exists, and how do you compare quotes? We offer two kinds: - One-off tests for a specific need, such as a launch, a customer security review or a new API. - Recurring testing after releases, scoped as deltas. See [per-release testing](/per-release-testing/). Prices for both are quoted after scoping. A single-role marketing site and a multi-tenant app with five roles and a large API are different jobs, so a published number would be wrong for most buyers. Compare scope, not totals. Ask each provider: - Which roles and environments are included? - Is a retest included, and for which findings? - What evidence does each finding carry? - Who checks the evidence and writes the report? - What are the stated limits and bounded tests? Our answers are on the [AI vs manual pentesting](/ai-vs-manual-pentesting/) and [safety](/safety/) pages. For a provider comparison, see pentestcompare.com. The [example assessment](/example-assessment/) is the sample report: it shows what each finding carries before you ask for a quote. ## Questions ### Do you publish prices? No. Prices are quoted after scoping, because the same app name can mean very different work. We would rather give a price for a written scope than a guess for a vague one. ### Is there a free option? Yes, a free pentest pilot with a small written scope. Places are limited and reviewed by hand. You receive every finding in the agreed scope with evidence and fix guidance, with no paywall on the results. ### Is the retest part of the price? We can retest fixed findings. Whether a retest is included in a quote is agreed during scoping. Say that you want one when you describe the need. ### How long until I get a quote? We do not state timings. The first step is a short call to understand the need, then a written scope and proposal. --- # Privacy notice Source: https://aipentestservices.com/privacy/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 What AI Pentest Services collects when you visit or send a request, why, where it is stored, how long we keep it and how to contact Excession Labs about your data. Effective 9 November 2026. AI Pentest Services (aipentestservices.com) is operated by **Excession Labs**. Contact: [privacy@excessionlabs.ai](mailto:privacy@excessionlabs.ai). ## When you send a form We collect what you type in the form, for example your name, work email, company, application address and your answers about the test you need. We also record: - the page you sent it from, the first page you visited in that browser session, the referring website and any campaign tags in the link (such as `utm_source`); - your country, your browser's user-agent string and a one-way hash of your IP address, used to stop abuse. We use these details only to reply to you, to scope and deliver the work you asked about, and to understand which pages bring requests. We store submissions in a Cloudflare D1 database and send a copy to the Excession Labs team mailbox by email. Do not send passwords, API keys, system prompts or real customer data through a form or by email. We agree access to test systems separately and in writing. ## Spam protection Forms use [Cloudflare Turnstile](https://www.cloudflare.com/turnstile-privacy-policy/) to check that a person sent them. Turnstile processes signals from your browser to do this. ## Analytics We use [PostHog](https://posthog.com/privacy) (EU cloud) in cookieless mode to count page views and clicks on calls to action. It does not set cookies and does not record sessions. PostHog may use your IP address to estimate your location. We also keep our own log of some clicks (for example on calls to action or links to other sites) with the page, time and country, without cookies. The site keeps the landing page, referrer and campaign tags of your visit in your browser's session storage, so a form can include them. Session storage is cleared when you close the tab. ## Sharing We do not sell your data and we do not use advertising pixels on this site. Service providers that process data for us: Cloudflare (hosting, database, email routing and Turnstile) and PostHog (analytics). ## How long we keep it We keep enquiries for as long as we need them to reply, to do the work you asked for, and to follow up on that business relationship. Then we delete them. You can ask us to delete them at any time. ## Your choices Email [privacy@excessionlabs.ai](mailto:privacy@excessionlabs.ai) to see, correct, export or delete the data we hold about you. You can block analytics with any content blocker; the site works without it. --- # Research Source: https://aipentestservices.com/research/ Publisher: Excession Labs (aipentestservices.com) Last updated: 2026-11-09 Lab research on AI-assisted penetration testing: what the lab's AI testing agents found in deliberately vulnerable apps, what it got wrong, and the evidence for each. We test our own AI agents in public. Each lab study runs the lab's AI testing agents against a deliberately vulnerable open-source application in an isolated lab, and reports what it confirmed, what it claimed and could not prove, and how long it took. Studies list the application version and setup so anyone can rerun them. Case studies from authorized tests of real systems appear only with the system owner's written permission, and are labeled as case studies. Research is in progress. --- # 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 do the scope and the allow, ask and deny rules 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. 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 the lab's AI agents do 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 and control cost? 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. 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, and where should it run? 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. 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, and what should you tell your team? We will not: - 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. 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. The lab's AI testing agents run the tasks in parallel under the tool rules Excession Labs sets for the scope. [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.