Using an AI for security work — and staying on the right side of the line

An assistant that will help you test systems is only useful if you use it within the rules. A short guide to scope, authorisation and keeping records.

The interesting thing about a capable security assistant is that it stops asking permission for every sentence — which means the discipline has to come from you. Whether that is a feature or a risk depends entirely on what you point it at.

Authorisation comes first

Before a single probe goes out, you need the right to test the target: it is your own system, you have written permission, or you are inside a defined program scope. An assistant cannot grant that permission, and neither can enthusiasm.

Write the scope down, then give it to the assistant

• In scope: the exact domains, hosts or applications you may assess.
• Out of scope: everything else, stated explicitly.
• Limits: rate, timing, and systems that must not be touched.

Keep an audit trail

For every action, keep what you ran, when, and against what. It protects you if a log later looks alarming, and it is the difference between a professional engagement and a story you tell afterwards.

Use isolation for anything that executes

Code that reaches out to a system should run in an isolated sandbox with visible limits — not on the machine holding your keys. Isolation is a guardrail, not a formality.

A tool that removes friction is only as safe as the person deciding where to aim it.

Report honestly

Say what you found, what you could not confirm, and what you did not test. An inflated finding is worse than an empty report: it destroys trust the next time you say something is urgent.