Can I use an AI agent to test my own website?

Yes, on systems you own or have written permission to test. Set a scope, use a staging copy where you can, and review the results yourself.

Is it illegal to run a security scan on a website I don't own?

Usually, yes. Unauthorised access or testing can be a crime in most countries, even when you mean well. Get written authorisation from the owner first.

What should an AI security agent never be allowed to do?

Do not let it change data, delete anything, send messages to real customers, or spend money. Give it read-only access and a fixed list of allowed actions.

Using AI agents to test your own site, safely

To test your own site with an AI agent safely, get written permission, define the scope, use a staging copy, give the agent read-only credentials, cap its actions, and keep logs. Only test systems you own or have written authorisation to test. A person should review every finding before anything is changed.

Should I point an AI agent at my own systems?

Yes, if you own the systems or have written authorisation, and you set limits first. Anthropic’s research on AI for cyber defenders recommends that organisations begin experimenting with AI for security and build ways to measure the results. It also says these abilities are still early and trail experienced professionals. Treat an agent as a fast junior assistant, not an authority.

The background is in what AI penetration testing is.

What permission do I need?

You need written permission from whoever owns the system, and from any third party that hosts it. If it is your own site on shared hosting, read your host’s terms, because some providers restrict automated testing. Never test a system you do not own, even if the aim is to help. Unauthorised testing can be a criminal offence in most countries, so check the law where you operate.

NIST’s testing guide, SP 800-115, describes planning, running and reporting on technical tests, and it is a useful model for the paperwork.

How do I set up a safe test?

Follow these steps in order:

Write down the scope. List the exact domains and systems the agent may touch, and name the ones it must not.
Use a staging copy. Test a duplicate of the site with fake data where possible, not the live site.
Give read-only credentials. Create a dedicated test account with the least access that lets the test work. Do not hand over your own admin login.
Limit what the agent can do. Allow a fixed list of actions. Block deleting, editing, emailing and spending.
Set a time window and a stop button. Tell your host and your team when the test runs, and know how to cut the agent’s access instantly.
Keep full logs. Record every action and request the agent makes, so you can review what happened.
Review before acting. A person confirms each finding, then fixes are made on staging first.

Why do the limits matter so much?

AI agents can act quickly and make mistakes. Anthropic’s report on the GTG-1002 campaign shows both sides: an agent can work through target systems at very high speed, and it can also overstate or invent findings that need checking. That is why a defender’s agent needs a narrow scope and a human reviewing its results.

The same report notes that attackers talked an AI into helping by claiming to run defensive tests. A genuine test needs written scope and records, which also protect you if someone later asks what the agent did. See how an AI-run attack unfolded for the full case.

What credentials should the agent hold?

Give the agent a separate, read-only account that you can revoke, and keep real API keys and admin passwords out of its reach. Store test credentials in a secrets manager or environment variable, not in the agent’s instructions. When the test ends, delete the account and rotate anything the agent could see. The AI agent security checklist covers permissions and secrets for any agent your team runs.

What do I do with the findings?

Sort them by risk, confirm each by hand, and fix on staging before the live site. Re-run the same test after the fix to check it worked. If you want a broader baseline first, use the website weak-spot checklist, and consider a professional test for payments or customer data.

What are the common mistakes?

Most mistakes come from skipping a limit because the test is “only internal”. Watch for these:

Running the agent against the live site with an admin login, so a wrong step changes real data.
Leaving scope vague, so the agent wanders to a supplier’s or partner’s system that you do not own.
Forgetting to tell the hosting provider, which may treat the traffic as an attack and suspend your account.
Trusting the report without checking. Anthropic’s report on the GTG-1002 campaign found that an AI agent sometimes claimed credentials that did not work, so every finding needs a human check.
Leaving the test account active after the work ends.

A short written plan covering scope, accounts, dates and contacts avoids most of these. Keep it with the logs, so you can show exactly what was authorised.

What should I do if the agent causes a problem?

Stop the agent first by revoking its account and keys. Then check the logs to see what it did, restore any affected data from backup, and tell your host if the traffic caused an outage. Write down what happened and which limit failed, then tighten that limit before any rerun.

This is why backups and a staging copy come before the test, not after. If the agent changed or deleted something on a staging copy, you lose an hour. If it did the same on the live site with real customer records, the cost is much higher. Check that you can restore a backup before you begin, not when you need it.

How do I tell my team and my host?

Send a short notice before the test starts. It should name who authorised the test, the systems in scope, the dates and times, and a contact for questions. Share it with whoever runs your hosting, your IT support and any staff who watch the site’s alerts.

Without the notice, a monitoring tool or a host’s security team may treat the test traffic as a real attack and block your address or suspend the account. A short email, kept with the written permission and logs, avoids that and gives you a clear record of what was agreed.