Keep AI Security Agents Within Scope

An AI security agent can follow your instructions perfectly until two rules conflict. For example, you might tell it never to test an out-of-scope host while also instructing it to investigate every possible vulnerability. If the agent decides that an external request is necessary to complete its investigation, it might prioritize the second instruction.

This creates a serious problem in automated penetration testing and bug bounty workflows:
a written scope policy alone cannot guarantee that an autonomous agent will stay within authorized boundaries.

A more reliable approach is to control the entire request execution flow. Instead of relying on the agent to decide whether a request is permitted, every outbound request must pass through an independently enforced scope guard.

Here's how to design that workflow using AGENTS.md, security testing skills, controlled tools, and a restricted transport system.

---

1. Why AGENTS.md Rules Alone Are Not Enough​

The AGENTS.md file is useful for defining how an AI coding or security agent should behave.
You can use it to establish rules such as:

• Never test hosts outside the authorized scope.
• Use an approved security testing skill for each vulnerability category.
• Never send arbitrary HTTP requests.
• Do not follow redirects to unauthorized destinations.
• Use only approved tools for network communication.

However, these are instructions, not technical enforcement mechanisms.

An agent might encounter conflicting instructions. For example:

• Rule A: Never send requests outside the authorized scope.
• Rule B: Investigate every possible vulnerability before completing the assessment.

If the agent interprets Rule B as more important, it could attempt an unauthorized request.
The solution is to remove that decision from the agent entirely.
The agent should request an action, but an independently controlled tool should decide whether that action is allowed.

---

2. Build a Skill-Based Security Testing Workflow​

The first layer is to require an approved skill before any security test can run.
Each vulnerability testing skill defines the permitted testing procedure, including:

• The vulnerability category being tested.
• The approved testing tool.
• Required parameters.
• The testing technique.
• Any additional restrictions.

For example, an agent investigating an access control issue should select the corresponding approved skill instead of improvising a new testing method.
The skill provides the testing procedure, while the tool controls execution.

A simplified workflow looks like this:

AI Agent
   |
   v
Approved Security Skill
   |
   v
Controlled Testing Tool
   |
   v
Scope Guard
   |
   +---- DENIED ---> Stop
   |
   +---- ALLOWED --> Execute Request

This separation is important.
The agent decides what it wants to investigate. It does not receive unrestricted authority to choose arbitrary network destinations.

---

3. Validate Every Request Before Sending It​

The scope guard is the most important component of this architecture.
It should be implemented inside the controlled execution tool and run before the tool performs any network operation.
The original workflow uses two independent sources of scope information.

Source A: Scope Check Results​

These files contain the results of previous scope validation checks, including the host and path being evaluated.
They provide structured information that the tool can use to determine whether a destination has passed the required checks.

Source B: scope.md​

The scope.md file contains the program's actual scope rules and exceptions, collected from the target's program page.
These rules might include:

• Authorized domains and subdomains.
• Excluded hosts.
• Restricted URL paths.
• Program-specific testing limitations.
• Explicit exceptions.

Both sources must approve the destination.
If they disagree, the request is rejected.
A simplified decision table illustrates the policy:

Scope Checks	scope.md	Decision
Allowed	Allowed	Permit
Allowed	Denied	Reject
Denied	Allowed	Reject
Unknown	Allowed	Reject

This is a fail-closed design: missing information, conflicting rules, or an uncertain destination should never result in automatic approval.
Important: The guard should validate the actual destination, not simply look for an approved domain name somewhere inside the URL.
It should also account for redirects, DNS resolution, alternate IP representations, and other ways a request could reach an unexpected destination.
Otherwise, an apparently authorized URL could still lead to an unauthorized host.

---

4. Use a Controlled HTTP Transport Ladder​

Once a request passes scope validation, the same controlled tool is responsible for sending it.
The workflow uses a transport ladder rather than allowing the agent to freely choose between different networking tools.

First: cURL as the Primary Transport​

cURL acts as the transport of record.
It is the default method for sending approved HTTP requests and collecting responses.
This creates a consistent execution path and makes request handling easier to audit.

Second: Browser Fallback​

A browser is used when cURL cannot provide a useful verdict.
Examples include:

• A browser challenge prevents a meaningful response.
• The expected HTTP status cannot be obtained.
• The response requires normal browser interaction to evaluate.

The browser provides a real-user perspective, but it does not receive unrestricted network access.
Every navigation and subresource request must still pass through the scope enforcement layer.
This includes requests triggered indirectly by page content.

---

5. Use Caido as a Passive Sensor, Not an Autonomous Transport​

Caido can be integrated into the workflow without giving the AI agent permission to send requests through it.

The browser launches with the appropriate proxy configuration, allowing its traffic to pass through Caido.
In this design, Caido serves as an observation layer.

Its permitted responsibilities are limited to:

• Reading proxy history.
• Providing passive leads for further investigation.
• Sending selected requests to Replay for manual review.

The agent must not use Caido as an autonomous HTTP transport.
This restriction is explicitly documented in AGENTS.md to prevent the agent from bypassing the approved execution flow through an MCP integration.
There is another important requirement: any potential finding observed through the proxy must be independently verified without the proxy.
This helps distinguish genuine application behavior from behavior introduced or modified by the proxy environment.

---

6. Apply the Same Restrictions to Burp Suite​

The same principle applies to Burp Suite.

A bridge may exist between the agent and Burp Suite, but that does not mean the agent should be allowed to use it as another request execution channel.
Instead, its role is restricted to supporting manual proof-of-concept investigation.
For example, Send-to-Repeater can prepare an interesting request for a human tester to review.

The distinction is straightforward:

Capability	Agent Permission
Read approved proxy history	Allowed
Identify potential findings	Allowed
Prepare requests for manual Replay	Allowed
Autonomously send requests through Burp	Denied
Bypass the central scope guard	Denied

This prevents additional security tools from becoming alternative routes around the primary scope policy.

---

7. Protect Browser Navigation and Subresources​

Controlling the initial URL is not sufficient.
A browser can generate additional requests while loading a page, even when the agent never explicitly asks for them.
Examples include:

• JavaScript resources.
• CSS files.
• Images and fonts.
• Background API calls.
• Iframes.
• Redirects.
• WebSocket connections.

⚠️ Consider an authorized application that loads a JavaScript file from an external domain.
If the browser automatically retrieves that resource, the agent's workflow has already contacted a destination that might be outside the permitted scope.
The browser therefore needs an enforcement mechanism covering every network request, not just top-level navigation.
For stronger isolation, combine request interception with network-level restrictions. Browser hooks alone should not be treated as a complete security boundary.
The same restriction must apply to every other available outbound transport, including direct shell commands and MCP tools.

---

8. Define Explicit Rules for Conflicting Instructions​

One of the most useful lessons from this architecture is that security policies can conflict with other operational instructions.
An agent may be instructed to investigate thoroughly, but thoroughness must never override authorization.
A suitable policy for AGENTS.md would be:

SECURITY SCOPE POLICY
1. All network requests must use approved tools.
2. Every request must pass scope validation.
3. Scope restrictions take priority over
testing completeness and investigation goals.
4. Missing or conflicting scope information
must result in denial.
5. Never use an alternative transport to
bypass a rejected request.
6. Caido and Burp Suite must not be used
as autonomous request transports.
7. If a test cannot be completed within
scope, stop and report the limitation.
8. Never expand testing authorization
without explicit human approval.

These instructions establish the intended behavior.
However, they should be backed by actual tool permissions, sandbox restrictions, and network controls.
If the agent still has access to an unrestricted HTTP client or shell environment, it may retain a route around the approved workflow.

---

9. Recommended Architecture for Scope-Safe AI Agents​

The complete design can be summarized as follows:

AI Security Agent
|
v
AGENTS.md
|
v
Approved Test Skill
|
v
Controlled Execution Tool
|
v
Scope Guard
/       
/         
Scope Checks    scope.md
\         /
\       /
Decision
|
+------+------+
|             |
DENY          ALLOW
|             |
STOP           v
Transport Ladder
|
+------+------+
|             |
cURL        Browser
|
Request Guard
|
Proxy (Optional)
|
Caido / Burp
Passive Leads

The most important architectural principle is that every request-capable component must operate behind the same authorization boundary.
A security skill should not be able to bypass it. A browser should not be able to bypass it. An MCP integration should not be able to bypass it.
For production use, request decisions should also be logged so a human reviewer can understand what was approved, rejected, or blocked.

---

10. Final Takeaway​

Keeping an AI security agent within scope requires more than writing a strict rule in AGENTS.md.
The more reliable approach is to build an execution environment where the agent can complete authorized tasks without needing unrestricted network access.
Give it approved skills, controlled testing tools, a fail-closed scope guard, and a clearly defined transport ladder.
Use Caido and Burp Suite for observation and manual investigation rather than autonomous request execution.
Most importantly, make scope validation an enforced technical requirement instead of a decision the agent can reinterpret.
Don't rely on an AI agent to remember where the boundaries are. Build the boundaries into the tools it is allowed to use.