AI trust and data handling

When you use an AI feature, Burp sends your data to PortSwigger's AI infrastructure, which manages communication with the AI provider:

1. Request: Your data, such as an HTTP request or vulnerability description, is sent to PortSwigger's AI infrastructure. In Burp Suite Professional, this is sent from your desktop client. In Burp Suite DAST, it is sent from a dedicated scanning resource created specifically to handle the investigation.

2. Authentication: PortSwigger verifies your license. Only licensed users can access the AI service.

3. Task processing: A temporary processing agent is created to handle your request. It is decommissioned immediately after the task is complete, and is never reused across requests or users.

4. Provider transmission: The agent passes your data to the AI provider.

5. Provider processing: The AI provider processes your data and returns a response to Burp. It does not retain any of your data once processing is complete.

6. Storage: PortSwigger stores your prompt, the AI response, and related metadata to support troubleshooting, auditing, and billing.

All communication between Burp, PortSwigger, and the AI providers is encrypted using TLS 1.2 or later.

No. Our contracts with our AI providers prohibit them from monitoring your data, storing it, or using it for model training. Your data passes through provider infrastructure while a request is being processed, but the provider does not retain it once the request is complete, and our contracts prohibit any secondary use.

PortSwigger reserves the right to use anonymized data to improve its AI features and diagnose issues.

Not currently. PortSwigger uses a multi-model approach to get the best results across a wide range of security testing tasks, and selects the model for each task based on extensive performance testing, matching each feature to the model that delivers the most accurate and reliable results. We currently use models from OpenAI and Anthropic.

We only use models that meet our strict data privacy standards, and providers that can guarantee your data is not used for training. Our infrastructure manages the connection to these models, so we can upgrade model versions after assessing them. These updates happen automatically, giving you access to current AI versions without the need to update Burp.

PortSwigger's AI infrastructure runs on AWS in the US-East (Virginia) and EU-West (Ireland) regions. Our AI providers process requests in US data centers. Routing between the US and EU regions is handled automatically based on latency. You cannot currently choose a specific geographic location.

Our AI infrastructure has protections against common attack types, including prompt injection and data exfiltration. Specific controls include server- and client-side input validation, rate limiting, and token-based authentication.

In this case, PortSwigger would respond according to its ISO 27001-aligned incident response process and its contractual obligations with the affected provider. AI usage is logged internally to support our investigations.

We operate failover systems to keep the AI features available. If the infrastructure serving a request becomes unavailable, requests are automatically routed to other infrastructure to maintain service.

Yes. PortSwigger's AI is covered by PortSwigger's ISO 27001 certification, and PortSwigger's Data Processing Agreement covers all personal data processed on your behalf. For full details, see the PortSwigger Trust Center.

No. Burp AT only runs when you open it and give it a goal. It does not take any action, or send any data to PortSwigger or our AI providers, otherwise. Once running, it works within the autonomy levels you set and pauses for approval on anything you haven't allowed it to do on its own.

Yes, but only if you configure it to. You have full control over what each tool can do without approval. When a tool call needs approval, Burp AT pauses and waits for your decision. For more information, see Configuring autonomy.

Burp AT works within the scope you set, and checks whether a target is in scope before it acts.

Burp AT can change scope itself if you allow it, using its Add to scope and Remove from scope tools. You can restrict or disable these individually in Settings > Tools. For details on what each tool can and can't do, see Configuring autonomy.

This scope check applies to Burp AT's own tool actions. Custom code that it runs through its scripting tools can send requests directly, including to targets outside your defined scope. If you need to prevent this, disable the scripting tools in Settings > Tools.

Burp AT sends the same kinds of requests to your target that you would when testing manually - it has no ability to affect a site beyond what Burp's tools can already do. It only acts within the scope you define, which is enforced by Burp's own tooling rather than by the AI, and high-impact actions always require your approval.

If you need tight control on a sensitive target, set the relevant tools to Ask, or require approval for every request in the task, so nothing is sent until you've reviewed it. For more information, see Configuring autonomy.

Yes. While Burp AT is working, click Stop to stop it immediately.

Yes. To turn off all of Burp's AI, go to Settings > AI and select Disable AI features. This stops all AI communication, including Burp AT, and grays out AI options throughout Burp.

To limit what Burp AT can do without turning it off completely, set its autonomy for each tool instead. For more information, see Configuring autonomy.

No. Each task is tied to the Burp project you're working in. Burp AT only sees and acts on the data in that project, so work from one project can't be seen by another.

Burp AT sends requests to the targets you've told it to test, in the same way you would when testing manually. All of that traffic is captured in the Logger, and is fully visible to you. It is also attached to every issue Burp AT raises, so you can see exactly what happened and reproduce any findings.

It can. Burp AT sends requests to the targets you've authorized. Depending on what you're testing this may include sensitive data, which it does not automatically redact. Its tool autonomy model lets you configure exactly what Burp AT can do without approval. If you need a higher level of manual control, you can configure it to require approval for all requests in the open task. For more information, see Configuring autonomy.

No. Burp AI requires explicit setup before it can run:

• Burp Suite Professional: a feature only runs when you actively use it. No data is sent to PortSwigger or our AI providers in the background.
• Burp Suite DAST: AI features are not available by default. An administrator must enable them for your installation before they appear in the UI. Once enabled, they only run against sites you have configured.

Yes, in both Burp Suite Professional and Burp Suite DAST:

• Burp Suite Professional: go to Settings > AI and select Disable AI features. Burp then cannot access PortSwigger's AI infrastructure, and all AI-related features are grayed out in the UI.
• Burp Suite DAST: access is managed at the organization level by an administrator. Go to Settings > Burp AI and toggle Enable Burp AI. You need the Enable/Disable Burp AI for the installation permission to change this setting. When disabled, AI features are removed from the UI and any AI results from previous scans are hidden.

Yes, in both Burp Suite Professional and Burp Suite DAST:

• Burp Suite Professional: for multi-step processes such as Explore Issue or Repeater tasks, pause or stop execution at any time from the Tasks panel.
• Burp Suite DAST: to stop AI-enhanced scanning, cancel the scan.

Yes. You can use Burp's scope settings to restrict Burp AI to specific hosts and URLs. In DAST, you can also control which issue severity and confidence combinations are investigated on a per-site basis.

• For scope in Burp Suite Professional, see Target scope.
• For scope in Burp Suite DAST, see Configuring AI-enhanced scanning.

It can. Burp AI does not automatically redact or mask the data sent to AI providers. Depending on the features you use and the traffic you're testing, this may include sensitive data.

As an exception, AI-generated recorded logins replace actual usernames and passwords with placeholders before they are sent to PortSwigger or the AI providers. This is the same behavior as manually-recorded logins.

All Burp AI features use the same infrastructure, but the data sent varies by feature:

• Explainer: the highlighted text or code snippet, and the context type (for example, REQUEST_HEADERS or RESPONSE_BODY).
• Explore Issue / AI-enhanced scanning: the full HTTP request and response pair in which the issue was found, including headers; the issue name, target URL, and insertion point; and, in Burp Suite DAST only, the origin scan ID and site ID.
• Burp AI in Repeater: the full HTTP request and response pair from the Repeater tab you ran the task from, including headers; your prompt; and any notes attached to the tab.
• False positive analysis: a screen capture of the vulnerability finding, and the associated HTTP request and response.
• Broken access control: a screenshot of the page content returned during the access check.
• Recorded logins: the page text, HTML attributes of interactive elements, and a screen capture of the page.

Burp AI uses structured prompts to keep the AI focused on security testing, reducing the risk of hallucinations or unintended actions. There are also built-in limits on the number of steps the AI can take during a task.

In Burp Suite DAST, AI-enhanced scanning has additional guardrails that block destructive HTTP methods (such as DELETE and PUT) and SQL operations that could cause data loss. These run automatically and cannot be disabled by users.

PortSwigger stores your prompts, AI responses, and associated metadata to support troubleshooting, auditing, billing, and account management. This includes any data you include as context (such as highlighted HTTP headers or code snippets); task metadata such as which feature was used, issue details, and target URLs; the timestamp at which the request was started; your license details; and token counts, credit consumption, and request counts.

All stored data is encrypted using AES-256. Only authorized PortSwigger staff can access it, and only when necessary to support troubleshooting or resolve an issue. Access is managed through role-based permissions, and every internal interaction with your data is individually logged.

Retention depends on the type of data:

• Conversation and audit data (the record of your prompts, AI responses, and associated task details) is retained indefinitely to support troubleshooting and long-term feature development.

• Operational logs, such as error and infrastructure logs, are deleted after 31 days.

• Account identifiers are deleted after 7 days of inactivity.