AI Security Agents Need a Lab They Can Break
A useful AI security agent reproduces findings and verifies fixes. Give it a disposable Linux lab with private networking, realistic services, and recoverable state.
A security agent flags a missing authorization check. The report points to a route, explains the risk, and suggests a patch. An engineer opens it and asks the question that determines whether the finding is useful: can you reproduce it?
Answering that takes more than reading source code. The agent needs to start the application, create two test accounts, seed some records, exercise the request, inspect the result, and run the same test after the fix. It may need a database, a queue worker, a browser, and the application's real authentication flow.
The agent needs a lab it can change, break, and restore.
Freestyle VMs are built for this kind of investigation. They are hardware-virtualized machines running real Linux, with full system access, private networking, and snapshots of memory and disk. They can keep an investigation running for days, pause it for review, or branch the environment to explore another approach. That combination makes Freestyle a strong foundation for AI security testing.
Make the finding observable
Consider an agent reviewing a document-sharing application. It suspects that a user can read a document belonging to another organization.
The useful experiment has a small, concrete shape. Create two organizations in a test database. Give each its own user and document. Confirm that each user can read their own document. Then check whether the application rejects access across the organization boundary.
That last step needs the real request path. A reverse proxy might enforce a check before the request reaches the handler. A background worker might read records through a different path. A mocked database might omit the ownership field that makes the bug possible. Running the relevant services gives the agent evidence about the actual behavior.
The result should connect a specific version of the application, a known starting state, an action, and an observable outcome. An engineer can then inspect the same experiment, rather than reconstructing the agent's assumptions from prose.
This is where a security agent starts producing work a team can use: a finding with a reproducer and a test that can verify the repair.
Reproduce the application inside the lab
Build the lab from the application's development setup. Install its actual dependencies. Run its database engine. Start its services under the same process supervisor or container configuration the team already uses. Seed synthetic users, organizations, and records that exercise the boundary under investigation.
Freestyle provides the operating-system features that make this practical: root access, systemd, containers, and full Linux networking. Its Docker guide covers running Docker Engine and Compose inside a VM. A repository with a Compose setup can bring its application, database, and workers into the investigation together.
Keep external effects inside the fixture too. A local mail sink can receive password-reset emails. A test webhook receiver can record deliveries. A local service can stand in for an integration whose request format matters. The agent can inspect those effects without sending messages or changing records in a live customer account.
For many application investigations, one VM is a useful starting point. It contains the app, database, supporting services, and test tools in one environment. When the suspected problem depends on communication between machines, split the relevant services across VMs on a private network.
The choice follows the finding:
| Investigation | Useful lab shape |
|---|---|
| Authorization between application users | One application stack with separate synthetic accounts |
| Database permissions used by a worker | Application, worker, and database with distinct service credentials |
| Reachability of an internal service | Separate VMs with explicit network rules |
| Browser behavior after an account change | A running application and browser with test sessions |
| Side effects of a webhook retry | Application, queue, and a local receiver that records deliveries |
The goal is enough realism to answer the security question. A lab does not need every production dependency to make one finding reproducible.
Give the experiment an explicit network boundary
Security testing often asks what one component can reach. The lab's network needs to make that question testable.
Freestyle VPCs give VMs private addresses for communicating with databases and internal services. Firewall rules specify which sources may reach which destinations, including individual VMs, private networks, ports, and protocols. Sharing a VPC does not itself grant permission to communicate.
For an investigation with an application VM and a database VM, allow the application to reach the database on its service port. Put the test client where the user being modeled would actually connect. If the finding concerns an internal admin endpoint, preserve that separation in the fixture instead of giving every participant access to every port.
Account for the routes that sit outside those firewall rules as well. Freestyle's published domains and SSH gateway have their own routing and authorization paths. Removing an Internet ingress rule does not unpublish a domain. Keep the lab's public routes and access credentials explicit alongside its private-network rules.
The same principle applies to outbound access. Prepare dependencies before the experiment where practical, then allow the connections the test needs. A broad Internet rule changes the boundary you are measuring. A dedicated lab with controlled dependencies makes the result easier to interpret.
Preserve the baseline before trying the fix
Once the application is running and the finding reproduces, preserve that state.
Freestyle's VM snapshots capture memory and disk, allowing new VMs to start from the captured state. For a lab contained in one VM, that can preserve the running application, its local database, and the tools used to reproduce the issue. It saves the setup that made the investigation useful.
Use independent copies for the original behavior and the candidate fix. Run the reproducer against both. The original should demonstrate the finding; the patched copy should reject the same action while still allowing the legitimate case.
That positive control matters. If a patch makes every request fail, the security test may appear to pass while the application is broken. The two-account example should prove both that users retain access to their own documents and that they cannot read another organization's documents.
A VM snapshot covers that VM. If the fixture spans several machines, prepare and restore their state as a coordinated lab. A shared external database would let one branch change another branch's experiment. Give each attempt independent mutable dependencies, and reconnect clients as needed when restoring them.
Branching becomes valuable when it preserves a fair comparison: the same setup, one deliberate change, and a result the reviewer can explain.
Keep the investigation available for review
An investigation can outlast a model call, a browser tab, or a working day. The agent may need to wait for a long workflow, inspect a delayed job, or leave the reproducer available for an engineer.
Freestyle's pause and resume lifecycle preserves memory and running processes. Pause the lab while it waits for review, then resume the same machine when someone is ready to inspect it. For work that must remain active, the idle timeout is configurable.
Keep the report independently useful too. Record the source revision, fixture setup, test steps, expected behavior, observed behavior, and result after the patch. Export the relevant logs and artifacts before deleting the lab. The running environment helps an engineer investigate; the report and regression test let the team retain the result.
This is the workflow Freestyle is designed to support: long-running, stateful experimentation in a machine the agent can operate fully. The lab is a workbench for testing the application and validating changes. The application's production deployment can remain on its existing infrastructure.
Start with one reproducible finding
The first milestone for an AI security agent should be a finding that another engineer can reproduce and a fix that survives the same test.
Give the agent a real Linux environment, the services needed to exercise the behavior, a controlled network, and a baseline it can return to. Let it investigate deeply enough to distinguish a suspicious code path from an observable defect. Preserve the evidence when it succeeds.
Build the lab on Freestyle. Start with one application, one security boundary, and one experiment that can be repeated. Then give each new investigation its own place to work.

