Only with proper authorization and safeguards. An unrestricted AI model’s ability or willingness to generate security-testing steps does not give you permission to test a system or make those steps safe to run. Before testing, get authorization from someone empowered to grant it, define the assets and methods in scope, set limits and stop conditions, protect sensitive data, and keep a person responsible for oversight. Whether a particular test is legal depends on the jurisdiction, target, agreements, provider terms, and what the operator actually does.
What does “unrestricted” change—and what does it not?
“Unrestricted” describes a model’s behavior or safeguards. It does not change who owns a target, grant access rights, or make a test lawful. A scan, command, or exploit attempt generated by a model is still part of the activity directed by the person or organization using it.
Nor does a model’s ability to provide an answer establish that the answer is accurate, contained, or safe for a live system. The sources covered here do not establish the live-testing safety or effectiveness of any particular unrestricted model.
What can authorize a penetration test?
For a real target, look for permission that covers the specific systems and activities you intend to test. A public vulnerability disclosure policy can provide a route for research, but it is limited by its scope and rules; it is not blanket permission to test every service associated with the organization.
Recommended Free Tools
#1 Best Overall
| Authorization route | What to verify | Important limit |
|---|---|---|
| Direct approval from the system owner or an authorized representative | That the approver has authority over the listed assets, and that the written approval covers the dates, methods, and degree of exploitation planned. | Permission for one system or activity does not automatically cover related systems, vendors, or service providers. CISA’s vulnerability disclosure policy template advises confirming authority before including a third party’s systems. |
| An applicable vulnerability disclosure policy | That the exact target is in scope and your planned methods comply with the policy’s permitted and prohibited activities. | A policy applies only within its stated boundaries. Do not assume that a service, vendor, or technique is covered just because it is connected to the organization. |
If neither route clearly covers the planned test, do not treat silence, public availability, or a model’s instructions as consent. Resolve the authorization question with the party responsible for the target before proceeding.
What should be agreed before testing starts?
Put the rules in writing before a model or operator touches the target. CISA’s vulnerability disclosure policy template calls for defined in-scope systems and allowed or prohibited testing. PCI SSC guidance recommends documenting and agreeing on test conditions and the permitted degree of exploitation in advance; NIST SP 800-115 provides technical assessment guidance, but does not supply target-owner authorization.
- Identify the approving party and assets. Name the person or organization authorizing the work and list the in-scope hosts, applications, accounts, and environments. Confirm the approver’s authority over each asset, including any vendor or service-provider systems.
- Set the time window. Record start and end dates, approved testing hours, and an emergency contact who can be reached while testing is active.
- Define allowed methods and limits. Specify permitted scanning and exploitation techniques, prohibited actions, and how far exploitation may go. Set impact limits that protect service availability and users.
- Set stop and escalation conditions. Agree what should cause testing to pause, who receives notice, and how the team will resume or close the test.
- Agree on data handling and reporting. State how credentials, test artifacts, findings, and any sensitive information will be protected, retained, reported, and deleted.
How can you reduce risk when AI is involved?
Use the model as an aid to an authorized assessment, not as the authority deciding what is in scope or when to act. The following controls turn the written test rules into operating limits:
- Keep a human in control. Have a responsible tester review proposed actions and confirm they fit the authorized scope before execution. Do not let a model’s suggestion expand the target list or the permitted methods.
- Constrain the execution environment. Configure access and tooling to match the approved targets and limits. Avoid giving the model or its connected tools broader credentials or network reach than the test requires.
- Protect secrets and data. Do not provide the model with credentials, personal information, financial information, proprietary material, or other sensitive data unless the engagement expressly permits that handling and the environment is suitable for it.
- Monitor activity and impact. Keep an operator able to observe testing, pause it, and contact the designated escalation point. Use the agreed limits on test intensity and service impact.
- Record actions and decisions. Retain an appropriate record of what was tested, when, under whose authorization, and how findings were handled, consistent with the engagement’s data rules.
These are operational safeguards, not proof that a model is safe. NIST’s September 18, 2026 ARIA Evaluation Planning Manual describes holistic AI evaluation that combines model testing, red teaming, and user testing. NIST AI 100-2 E2023 addresses adversarial machine-learning attacks and mitigations. Neither publication certifies an unrestricted model for penetration testing against third-party systems.
What if testing reveals a vulnerability or sensitive data?
Follow the engagement’s stop and notification rules. CISA’s Vulnerability Disclosure Policy Template instructs researchers to stop testing, notify the organization immediately, and not disclose encountered sensitive data to anyone else. Its examples include personally identifiable information, financial information, and proprietary information or trade secrets. The template was accessed October 3, 2026.
Do not continue exploring merely to prove impact if doing so would exceed the agreed limits or expose additional data. Report the minimum necessary information through the agreed channel and wait for direction from the authorized contact.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Does DOJ’s CFAA policy make good-faith research automatically legal?
No. On May 19, 2022, the U.S. Department of Justice announced a revised federal charging policy stating that good-faith security research should not be charged under the Computer Fraud and Abuse Act (CFAA). DOJ describes good-faith research in terms of purpose—testing, investigating, or correcting a vulnerability—conduct designed to avoid harm, and use of findings primarily to promote the security or safety of the affected class of devices, machines, or services.
That is federal prosecutorial guidance, not permission from a system owner or a universal safe harbor. It does not settle state law, civil claims, contracts, foreign law, or whether a particular engagement is authorized. The DOJ policy should not be used to justify testing a target that its owner has not placed within scope.
What is established—and what remains uncertain?
The cited guidance supports a clear process: establish authority, define the target and permitted methods, agree on safeguards, and stop and report if sensitive data is encountered. It does not establish that any named unrestricted model is reliable or safe for live penetration tests, or compare models’ effectiveness. The reviewed material also gives no safety or success-rate statistic for unrestricted AI penetration testing.
Because the jurisdiction, target, contract, provider, model, and test plan vary by engagement, these general principles cannot determine the legality of a specific test. Check applicable local law, contracts, and provider terms, and have the authorization reviewed for the actual scope and conduct planned.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
