Before an agentic pentest touches production: a review for system owners

Sources checked: 2 November 2026. FailSafe Research.

A good production-testing conversation starts with the system owner. Which workflow matters, what must keep working, and which actions would create an unacceptable consequence? Those answers shape the assessment before any agent begins exploring.

FailSafe uses restricted action modes and an execution gate, with unprivileged agents in ephemeral runtimes. The customer’s environment and agreed scope determine how that control model should be used. This review helps a security team turn a broad request to “test the application” into an assessment it can authorize.

Choose one meaningful boundary first

Start with an application or workflow, the identities it uses and the result the test should investigate. Record owned or authorized targets, excluded services and third-party dependencies. Authentication providers, payment services and linked external systems do not become test targets because the application uses them.

List permitted techniques, test windows and request limits. Agree how the configured controls will be checked before work begins. Written scope and technical verification should describe the same assessment.

Decide how much proof the environment can support

Safe mode is read-only-first and restricts configured mutations and recognized destructive operations. That can be appropriate for a smaller-impact assessment where the selected methods and access fit the production environment. Some potential exploit paths will remain unexecuted under those restrictions.

Cyber mode supports broader authorized validation and requires a target isolated from production with hard egress restrictions. If the question needs state changes or deeper execution, prepare that environment and agree the recovery responsibilities before selecting the mode.

A request’s method or appearance is not enough to establish its effect. Application behavior can make an apparently ordinary request consequential. Pattern checks and request caps need to be considered together with the actual target.

Prepare the people who will see the traffic

Tell the application owner and relevant security operators when the assessment will run and how to reach the responsible contacts. Agree the expected source traffic, the operational signals to observe and the conditions that require a pause.

Unexpected state changes, degraded availability, account lockouts and signs of scope drift should trigger review under the agreed plan. Confirm the mechanism for stopping and resuming work in the selected deployment. Do not assume a universal response time or that stopping new actions undoes effects already completed.

Use a narrow identity and data set

Where authenticated access is required, start with a deliberately scoped test role. Agree how credentials are supplied, accessed, rotated and removed. Synthetic data can make a boundary test easier to validate without involving unrelated customer records.

Review where model processing and evidence will be handled. Sensitive scopes may call for sovereign hosting and local inference. FailSafe does not train on customer assessment data by default; explicit permission is required for any training or fine-tuning use.

Finish with an assessment record

Before launch, confirm which activity records, finding evidence and artifacts will be available to your reviewers. Afterward, record what was tested, what was restricted, what the observed proof establishes and what remains uncertain. Agree cleanup, credential revocation and retention responsibilities.

A remediation retest should identify the changed build and the relevant path being repeated. Engineering ticket closure and an observed security result are separate pieces of evidence. Keep both connected to the assessment scope.

A short approval checklist

1. Named authorized targets and exclusions, including third-party services.
2. A selected mode and an environment that meets its prerequisites.
3. Permitted techniques, access, request limits and test windows.
4. Agreed monitoring, stop conditions, contacts and resume approval.
5. Documented inference, credential and evidence-handling boundaries.
6. A plan for artifact review, cleanup and remediation retesting.

Use the FailSafe Trust Center to review the documented controls, or plan the assessment with FailSafe. This checklist supports a configuration review; it does not establish that every production system is suitable for autonomous testing.

References: FailSafe’s public control summary, NIST SP 800-115 for security-test planning, and OWASP APTS for autonomous-testing governance. Editorial update: 2 November 2026.