A lot of software running today was written quickly: by hand under deadline pressure, or with help from earlier, weaker AI models. Much of it has never had a careful security review. At the same time, attackers are using AI agents to find weak spots faster and at far greater scale than before (our AI Hacks timeline tracks the incidents).
The good news is that the same models can be pointed at your own code. Here is a practical 90-day plan for small teams and solo builders to audit existing software with a frontier model, fix what matters and keep it fixed.
Days 1–30: inventory and first audit
1. List what you actually run
Write down every app, API, admin panel, script and scheduled job you are responsible for, where it runs, what data it touches and whether it is reachable from the internet. Internet-facing internal tools with weak logins are a favourite target, so mark those first.
2. Pick one frontier model and learn it properly
Use a current, capable model inside a coding agent that can read your whole repository. Spend a few sessions learning how to brief it well: what the code does, where the sensitive parts are, and what you want back.
3. Run the first review on the riskiest code
Start with the parts where a mistake costs the most. Ask for specific findings, each with file, line, what could go wrong and a suggested fix. Focus areas:
- Authentication and sessions: password handling, token expiry, missing checks on admin routes, “forgot password” flows.
- Authorisation: can one user see or change another user's data by editing an ID?
- APIs: unauthenticated endpoints, missing rate limits, overly detailed error messages.
- Input handling: injection risks in database queries, shell commands and templates; file uploads.
- Secrets: keys and passwords in code, config files or logs.
- Backend configuration: debug modes left on, open storage buckets, default credentials.
4. Triage before you fix
Models produce false alarms. Sort the findings into “real and serious”, “real but minor” and “not a problem”, and check the serious ones yourself. A second model from a different lab is a quick way to confirm or reject a finding; see our builder + reviewer workflow.
Days 31–60: fix, shrink and harden
5. Fix the serious findings first
Have your coding agent prepare each fix with a test that proves the hole is closed, then review and merge it yourself. Re-run the audit prompt on the fixed code.
6. Cut unnecessary dependencies
Every package you install is code you didn't write and probably haven't read, and poisoned packages are a growing problem. Ask the model to list dependencies that are unused, abandoned, duplicated or replaceable by a few lines of your own code, then remove what you can. Pin versions for the rest and turn on automated vulnerability alerts.
7. Tighten the obvious defences
- Turn on multi-factor sign-in for every admin and cloud account.
- Rate-limit and alert on failed sign-ins, so automated password-spraying is caught early.
- Put internal tools behind a VPN or single sign-on instead of leaving them open to the internet.
- Patch internet-facing software quickly; automated attackers can find unpatched systems within minutes to hours.
- Give every service and every AI agent the least access it needs.
Days 61–90: make it continuous
8. Review every risky change, not just old code
Add a review step for changes that touch login, payments, data access or infrastructure, so new holes don't replace the ones you closed.
9. Schedule a monthly re-audit
Models improve every few months, and a newer one often finds problems an older one missed. Re-run your audit prompts on the riskiest code each month and whenever you switch to a stronger model.
10. Watch your own agents
If you use AI agents to write code or run tasks, treat them like a new employee with keys: log what they do, keep their permissions narrow, and require human approval before anything is deployed, deleted or sent. Our guide to AI agent security covers the risks in more detail.
11. Stay adaptable
Tools, models and attack methods are all changing quickly. Keep a short written record of your audit prompts, what they found and what you changed, so the routine survives staff changes and model upgrades.
One-page checklist
| When | Do this |
|---|---|
| Week 1 | Inventory systems; mark internet-facing and data-heavy ones |
| Weeks 2–4 | Frontier-model audit of login, permissions, APIs, inputs, secrets, config; triage |
| Weeks 5–8 | Fix serious findings with tests; remove unneeded dependencies; MFA, rate limits, patching |
| Weeks 9–12 | Review step for risky changes; monthly re-audit; agent permissions and logging |
Frequently asked questions
Is it safe to give an AI model my source code?
Check the provider's data and training settings and your organisation's policy first. For sensitive code, use a business plan that excludes your data from training, or run a capable model locally.
Can an AI audit replace a professional penetration test?
No. It is a fast, cheap way to find many common problems, but systems that handle money, health data or large numbers of users still warrant an independent professional assessment.
What if the model reports hundreds of issues?
Ask it to rank findings by real-world impact and likelihood, then work only on the top ones first. Many low-severity findings can wait.
Do I need to be a developer to do this?
The inventory, the account security steps and the agent permissions don't need coding skills. For the code review itself, a developer, or at least someone comfortable reading code, should check the findings.