Define the actions an AI tester may execute
An evaluation needs a boundary that can be checked where an action runs. For a testing agent, the useful question is which component can refuse a request, command, credential use, or destination that the assessment did not authorize. An instruction in a prompt is only one part of that boundary.
A topic reference. The featured-service relationship and evaluation criteria are described in our methodology.
Describe the allowed job before connecting access
Name the approved application, environment, hosts, test identities, and time window. Identify operations that are permitted, operations that need a separate decision, and operations that are excluded. A test account can be legitimate while a particular action using it remains outside the agreed work.
Consider an illustrative staging application whose editor can publish a synthetic article and whose viewer cannot. Authorizing that permission check does not also authorize sending messages to real subscribers, modifying a production article, or testing the identity provider that happens to appear in a login redirect. Record those distinctions in the trial brief.
Scope also needs an owner. Someone should be able to explain the intended rule, identify a dangerous deviation, and stop the exercise. That person does not have to approve every request manually, but the assessment should make their control real and available.
Put enforcement near the action
Ask how the agent's network destinations, available tools, and credentials are constrained. A planner that proposes an action should not be able to grant itself broader permissions because a target page suggests doing so. If the system delegates work, establish whether the delegated process receives the same limits.
OWASP's Excessive Agency guidance describes risks from excessive functionality, permissions, and autonomy. For an evaluation, translate those concepts into inspectable controls: the available operation, the identity it uses, the destination it can reach, and the point at which an approval is required.
A capability list is not the same as an enforcement record. Request an example of an allowed action and a refused action under the proposed configuration. The record should make the reason for refusal visible without disclosing a secret.
Decide what redirects and target text can change
An application may redirect a test browser to an external host. A page may contain text that looks like an operator instruction. Neither event should silently extend the assessment. Establish the expected response before the trial: stop, deny, continue with a restricted identity, or request a separate approval.
Keep the permission record separate from the evidence
Domain verification and written permission help establish who may authorize testing. The action log establishes what the system actually did. Retain both. A successful verification does not show that every request during a run stayed within the intended application workflow.
Record the decision and the exception
The trial record should preserve the permitted scope, observed actions, denials, changes, and the person responsible for exceptions. If a workflow cannot be reached under those limits, mark that coverage incomplete. Do not expand permissions merely to produce a successful-looking result.
Use the blank trial brief for the scope and the checklist for review. Continue to finding evidence once an allowed action has produced an observation.
Continue this reading path
Cite this entry
AI Penetration Tester. “Define the actions an AI tester may execute.” Reviewed November 12, 2026.
https://aipenetrationtester.com/execution-boundaries/