Professional

Prompting Burp AT effectively

• Last updated: October 9, 2026

• Read time: 6 Minutes

A prompt is a message you enter in the message box. Use prompts to tell Burp AT what to test, what evidence to collect, or when to stop.

Write a prompt with a result you can verify

Include any details that help Burp AT understand the task:

• The host, path, endpoint, or attached Burp resource to investigate.

• The security question you want Burp AT to answer.

• Relevant context, such as the intended application behavior or an observation that led to the test.

• Any limits on what Burp AT should do or how far it should investigate.

• The evidence that would confirm or reject the suspected behavior.

You don't need to include every detail in every prompt. Add only the information that helps Burp AT complete the task.

For example:

Test whether a standard user can read another user's order through https://example.com/api/orders/{id}. I've attached a request that retrieves an order owned by the signed-in user. The application should return only orders owned by that user. Do not modify or cancel an order. Stop after demonstrating access to one harmless record. Compare a valid same-user request with the cross-user request. Report the result as confirmed, not confirmed, or inconclusive, and show the requests and response differences that support it.

This example tells Burp AT what to test, how far to investigate, and what evidence to return.

Use a goal loop for complex tasks

Goal loops help Burp AT tackle larger or more complex tasks that may need significant work. Use a goal when you can define a clear result and stopping point.

To set a goal, enter /goal followed by a result that Burp AT can verify. For example:

/goal Test every input to this endpoint for server-side injection. Continue until each input is confirmed, rejected, or marked inconclusive.

After each response, Burp AT checks whether it has achieved the goal. If not, it continues working automatically.

Burp AT applies no fixed time or response limit to goals. Vague goals may therefore run for a long time and use more AI credits.

Replace broad instructions with testable questions

Specific questions make results easier to verify. Adding emphasis or asking Burp AT to be “extremely thorough” does not tell it what to investigate.

Instead of	Write
Test this application thoroughly.	Map the authenticated account area and identify three access-control boundaries worth testing. Do not send attack payloads yet.
Find SQL injection in this request.	Test whether the sort parameter is injectable. Compare SQL-sensitive inputs with suitable controls, and report whether the evidence confirms, weakens, or rejects the hypothesis.
Check the admin page.	Only administrators should be able to reach /admin. Test whether a standard-user session can access it.
Prove this issue is exploitable.	Try to reproduce the attached issue. If it reproduces, demonstrate the minimum impact needed to confirm it. If it does not, show what you tested and what remains uncertain.
Attach the request, then write:	Investigate whether this login request permits authentication bypass.

Name the vulnerability class, endpoint, or security boundary you want to test. This helps Burp AT focus its work. Avoid packing several unrelated questions into the same prompt.

Ask for evidence, not the answer you expect

Ask Burp AT to test whether the issue exists rather than assume that it does. Tell it to classify the result as:

• Confirmed if the evidence demonstrates the behavior.

• Not confirmed if the tests do not demonstrate it.

• Inconclusive if Burp AT lacks enough access, context, or evidence to decide.

State the evidence you need to review, such as a baseline request, a modified request, and the relevant response difference. Ask for the minimum evidence needed to confirm the issue. For example, one harmless test record may confirm a broken access control issue without exposing more data or changing application state.

You may find it useful to challenge a result before reporting it. For example:

Try to disprove this finding. Test the strongest alternative explanation first, then tell me whether the original conclusion still holds.

Tell Burp AT when to stop

A clear stopping condition tells Burp AT how far to investigate. For example:

Test every input to this endpoint for server-side injection, including query parameters, headers, and cookies. Use suitable controls and encoding variants. Continue until each input is confirmed, rejected, or marked inconclusive.

Use a specific condition such as until each input is classified. Avoid vague instructions such as test exhaustively or keep going until you are certain.

If you set a time or effort limit, say what Burp AT should do when it reaches that limit:

Keep this to a short initial pass. If you cannot confirm the issue, summarize the tests completed, the strongest remaining lead, and what you would try next.

This tells Burp AT what to return if it reaches the limit, so you still receive a useful partial result. Prompts that require deeper investigation usually use more tools and AI credits.

Steer a task with follow-up prompts

Use follow-up prompts to focus, extend, or stop the current line of work. For example:

1. Concentrate on the unexplained 500 response and compare it with a control.
2. Repeat the same access-control test against the invoice endpoint.
3. Summarize the evidence collected so far.

If Burp AT repeatedly drifts from the intended question, start a new task with a clearer prompt. Carrying several corrections and abandoned approaches forward can make the task harder to direct.

When Burp AT requests approval, select Show detail and check that the planned action matches your instructions and acceptable impact. Rejecting an action does not end the task; Burp AT looks for another approach instead.

Enforce restrictions using in-product controls

Limits written in a prompt guide Burp AT's priorities, but they should not be used as security controls in their own right. Use Burp Suite's scope controls and Burp AT's tool permissions settings to define what Burp AT should not test and what tools it should use.

Burp AT can propose changes to scope, but they always require manual approval. You can disable Add to scope and Remove from scope in Settings > Tools.

Custom code run through the scripting tools can send requests outside project scope. You can disable these scripting tools if you need to.

Treat target content as untrusted data. Pages, responses, scripts, and headers may contain text intended to influence an AI agent. Do not rely on an instruction in a prompt to neutralize that content; use project scope, tool permissions, and approval checks to control what Burp AT can do.

Troubleshooting

Symptom	What to change
Burp AT covers a large surface without going deep.	Narrow the prompt to one security question or one area of the application.
Burp AT reports a finding you cannot reproduce.	Ask it to repeat the test against a control and try to disprove the finding.
Burp AT stops before the question is settled.	Add the evidence required and a clear stopping condition.
Burp AT takes actions you did not intend.	Add a specific impact limit, then check scope and tool permissions.
Burp AT asks for approval too often.	Review the task's autonomy mode and the settings under Settings > Tools.
Burp AT declines authorized testing.	State the authorized testing context, identify the in-scope target, and phrase the request as vulnerability verification.