When people picture guard rails for AI, they usually imagine something dramatic: a kill switch, or a model refusing a bad instruction.
We do have a kill switch, and we’ll come to it. But in penetration testing, the most important guard rails are much less cinematic. They’re set before a single packet is sent, when you decide what’s in scope, what’s out and when testing happens.
If your systems run payroll, bookings or patient records, that isn’t paperwork. It’s the difference between a controlled test and an unplanned outage.
Here’s how Block8.ai builds those decisions into the platform instead of leaving them in an email thread.
You define the boundary
Every Block8.ai engagement starts in the customer portal. You specify:
• the test type (black-box, grey-box or white-box)
• the targets: URLs, IP addresses or endpoints
• out-of-scope items, stated explicitly
• the compliance frameworks the test should align with
• any test credentials, which are encrypted in a vault and never re-displayed
The scope comes from you, in writing, inside the platform. The tester doesn’t infer it.
The Rules of Engagement are generated from your scope
Once the scope is set, the platform generates test-specific Rules of Engagement from it, including a summary of your chosen compliance frameworks and any notes you’ve added. You review and accept them, and a snapshot of exactly what you accepted is kept for audit.
If anyone later asks “what did we actually agree to?”, there’s a record to check.
You choose when testing happens
You decide when testing runs. AI-only and Human in the Loop tests can start straight away, or be scheduled for a time that suits your operations team. Human in the Loop tests for CREST accreditation run within a fixed five-day window. The portal updates in real time as the test moves through Planning, Scheduled, Active, Completed and Report Published, with a notification at every step.
The engine starts from the authorised scope
When testing begins, the first thing the AI testing engine does is load the authorised scope and validate the credentials. Techniques such as privilege escalation and lateral movement are explicit opt-ins, recommended only for internal network tests where the engagement calls for them.
When a suspected vulnerability is validated, exploitation stops at proof: enough to show the risk is real, not enough to cause damage.
And if something needs to stop, you can stop it. You can pull the kill switch yourself at any time. It halts every testing agent, even mid-task, usually within two minutes. Our team has a separate emergency stop that shuts the whole testing environment down in about five seconds.
Everything is logged, and cleaned up
Every command the testing engine runs is logged. After the report is generated, the testing environment is torn down, and idle testing containers shut down automatically. Nothing is left running once the job is done.
What guard rails do, and don’t do
Guard rails don’t make penetration testing risk-free. Testing live systems always carries some risk, which is why the scope and timing decisions matter so much. The out-of-scope items you list, for example, become extra rules the AI sets for itself during testing. That’s a best-effort control, not a hard block, so the surest way to keep a system out of a test is to leave it off the target list.
What guard rails do is make testing accountable: you know what was agreed, you know when it will happen, and you can check what happened.
Three tips for your next test
• Keep anything you can’t risk off the target list, and name it as out of scope as well. Fragile legacy systems, third-party services you don’t own and production databases you can’t risk all belong there.
• Tell your operations team when testing will run. An alert that’s expected is an alert nobody escalates at 2am.
• Use dedicated test accounts for grey-box and white-box testing, not real users’ credentials.
What to do next
Want to see the scoping workflow for yourself? See How It Works.
Watch the demo videos