Security
AI-assisted security testing starts with authorization
A security test can be welcome while still containing an unauthorized action. An accessible service might belong to another operator. A technique might be technically possible but excluded from the engagement. An AI agent does not resolve that contradiction. It makes it more important to describe the mandate before starting and to enforce its boundaries independently of the model's own assessment of what it should do next.
Authorization is an operational prerequisite
Useful authorization answers more than whether testing is broadly permitted. It identifies targets, timing, allowed methods and a contact able to decide when uncertainty arises. Shared services and third-party infrastructure deserve particular attention. Technical reachability establishes neither ownership nor permission; even a commissioning organisation can only delegate authority that it actually holds over the relevant systems and activities.
For the accountable executive, this is not a legal attachment to add afterwards. Authorization defines which work has been commissioned and when it must stop. If an agent discovers another interesting target, the mandate does not automatically expand. That extension requires a deliberate decision outside the ongoing automated investigation, before any additional action takes place against the newly discovered target.
Give the boundary a technical owner
My public project pentest-agent-nix is a fork of an existing project for AI-assisted security testing. Its documented hardened architecture combines a NixOS host with separate virtual testing environments. Scope is confirmed locally and enforced on the host. The authoritative decision therefore does not rest solely in a prompt inside the environment carrying out the investigation itself.
The architecture also describes a session-scoped broker for provider access while keys remain on the host. That is a concrete separation of responsibilities, not a blanket security guarantee. In your installation, it should be possible to identify which component actually restricts scope, who can change its configuration, and how a denied action appears in the evidence available to the operator.
A convenient development mode is not the same boundary
The project explicitly distinguishes the hardened workstation from older local and container-based development paths. They must not be presented as equivalent protection; the strict supply-chain gate rejects the legacy images. During a demonstration, ask which operating mode is actually running. An identical product name says little about the separation currently enforced between testing activity and the host machine.
My open-source project tentaflake illustrates why precise descriptions matter too. It is an early-stage NixOS template for isolated agents, with interfaces and security policy still subject to change. Agents are declared in configuration; importing one does not start it. Its documented boundaries describe an architectural approach, not a claim that every real provider integration has already passed deployment acceptance.
Match the evidence to the property being claimed
In my open-source project architecture-kit, I separate tool contracts and synthetic checks from an implemented platform. The kit describes requirements but does not supply a running agent service. Negative contract tests can demonstrate that an example rejects a forbidden input. They do not automatically establish that the network path in your particular installation prevents the same forbidden action, or that every deployed component is configured correctly.
Approval should therefore keep several layers visible: the agreed rule, the implementation responsible for it and observations from the intended environment. Fast project checks are useful but do not replace broader acceptance work. Record missing integration evidence explicitly instead of hiding it inside a general tested status that nobody can later explain with the precision needed for an accountable decision.
Keep accountability with named people
An agent can collect findings and suggest next steps. It cannot independently create business authority for additional interventions. Before work starts, the commissioning organisation and the testing team should agree who can stop activity, who approves extensions and who evaluates an unexpected effect. Those people must remain reachable during the work, rather than existing only as names in the original proposal.
The result of a responsibly governed test is therefore more than a list of possible vulnerabilities. It includes a traceable account of the authorized scope, the environment used and the investigation's remaining limitations. This lets you assess findings without turning a technically impressive sequence of actions into an unsupported claim of comprehensive security or assuming that those actions were necessarily permitted.
Questions for your team or vendor
- Who can authorize the specific targets and methods, and where is that authorization recorded?
- Which component enforces permitted scope independently of instructions given to the model?
- Are we using the hardened testing environment or a development mode with different boundaries?
- Who can change or revoke access rules and provider credentials?
- Which evidence comes from the intended installation, and which comes only from examples?
- Who decides on stopping, unexpected effects and extensions to the engagement?