To audit an AI agent someone else built, first collect the code, prompts, tool credentials, provider and hosting accounts, logs and any test set. Map every action it can take and check that irreversible ones need approval enforced in code, not just in the prompt. Measure accuracy on 30-50 real cases from the logs, try to instruct it through content it reads, work out the cost per conversation, and confirm the accounts and keys are in your name and the model version is pinned. Rank findings by what they could cost, then keep, fix or rebuild.
When do you need to audit an AI agent someone else built?
Usually at one of four moments: a freelancer or agency has handed over an agent and moved on; you have inherited one through an acquisition or a new role; a customer has complained about something it did; or the bill has grown faster than the usage. In each case the question is the same. Is this system safe to keep running, and what would it cost to make it so?
An audit answers that in days, not weeks. It is not a rebuild and it is not a code review for style. It checks the handful of things that decide whether an agent is a liability: what it is allowed to do, whether anyone has measured how often it is right, who controls the accounts, and what happens when something changes underneath it.
What do you need before you start an AI agent audit?
Collect access first. An audit stalls on a missing login more often than on a hard question, and a supplier who cannot produce these is itself a finding.
- The source code repository, with history.
- Every prompt and system instruction, wherever they live - code, a database, a vendor dashboard.
- The list of tools and integrations the agent can call, and the credentials it uses for each.
- Admin access to the model provider account, the hosting account and any vector database.
- Conversation or run logs for at least the last month.
- Any test set, evaluation results or acceptance criteria from the original build.
- Whatever documentation and handover notes exist, however thin.
How do you audit an AI agent, step by step?
- 01
Map what it can do
List every tool the agent can call and every system it can write to. Mark each action as read, reversible write or irreversible write. This is the blast radius, and it decides how hard the rest of the audit needs to look.
- 02
Check the boundaries
For each irreversible action - sending email, issuing refunds, deleting records - find where approval happens in code, not in the prompt. A prompt saying 'never refund over $100' is a suggestion. A code check is a boundary.
- 03
Measure accuracy on real cases
Take 30-50 real requests from the logs, write down the correct outcome for each, and run them. If an evaluation set already exists, check that it contains hard cases rather than the five examples from the demo.
- 04
Test the security model
Try instructing the agent through the content it reads - an email, an uploaded file, a web page. Check whether one user can reach another user's data, and where the API keys are stored.
- 05
Read the bill and the logs
Work out the cost per conversation and what drives it. Check that failures are logged, that someone is alerted, and that you can reconstruct why the agent did what it did last Tuesday.
- 06
Check ownership and change risk
Whose name are the accounts and keys in? Which model version is pinned, and when is it scheduled for retirement? Could someone else maintain this from the documentation alone?
What should an AI agent audit check, and what are the red flags?
| Area | What to check | Red flag |
|---|---|---|
| Permissions | Every tool and write action, scoped per user | One admin credential shared by every user |
| Boundaries | Approval before irreversible actions, enforced in code | Limits that exist only as instructions in the prompt |
| Accuracy | A labelled test set of real cases and a recent score | No test set, or one made of easy examples |
| Retrieval | Source documents current, superseded versions removed | Answers quoting documents that were replaced |
| Security | Behaviour when content contains instructions; secret storage | Keys in code or prompts; agent obeys text in emails |
| Cost | Cost per conversation, caching, per-step model choice | The largest model on every step, nothing cached |
| Observability | Logged runs, alerts on failures and cost spikes | Nobody is told when it fails |
| Model risk | Pinned model version and its retirement date | An unpinned alias, or a model retiring next quarter |
| Ownership | Accounts, keys and repos in your company's name | The builder's personal account or credit card |
| Maintainability | Documentation another engineer could follow | One person understands it, and they have left |
The accuracy row deserves the most time. Our post on evaluating LLM output in production covers how to build the test set. If the agent answers from documents, the warning signs in 7 signs your RAG chatbot is giving wrong answers are a fast first pass.
How do you decide whether to keep, fix or rebuild an AI agent?
Rank each finding by what it could cost you, not by how much work it is to fix. Then the decision usually falls out of the pattern.
Keep, with small fixes
The boundaries are enforced in code, accuracy on real cases is acceptable, and the gaps are operational: missing alerts, keys in the wrong account, no documentation. These are days of work, and the system is worth more than its flaws.
Fix before it does anything else
The agent works but can take irreversible actions without approval, or one user can reach another's data. Restrict it to read-only or draft-only while the boundaries are moved into code. This is urgent and usually not large.
Rebuild
Accuracy on real cases is poor and nobody can say why, the architecture puts everything in one enormous prompt, and nothing is tested. Fixing a system like this tends to cost more than rebuilding it with what you have now learned - and the logs and the test set from the audit are the most valuable inputs to the rebuild.
What should you ask for so the next handover doesn't need an audit?
Most audits exist because the original handover was thin. If you commission an agent again, put these in the contract as deliverables rather than favours:
- Repositories, cloud accounts and model API keys in your name from the first commit.
- A written capability boundary: what the agent may do, what needs approval, what it must never do.
- The evaluation set, the score at launch and the command that re-runs it.
- Runbooks for the failures you can predict: provider outage, model retirement, cost spike.
- A recorded walkthrough of the architecture by the engineer who built it.
Our checklist for hiring an AI development partner covers the rest of the contract.
How do you audit an AI agent someone else built?
Get access to the code, prompts, accounts and logs. Map every action the agent can take and check that irreversible ones need approval enforced in code. Measure accuracy on 30-50 real cases, try to instruct it through the content it reads, read the bill, and confirm the accounts and keys are yours and the model version is pinned. Rank findings by what they could cost, then keep, fix or rebuild.
If you would rather hand the audit to someone who has built these systems, see AI agent development or get in touch with what you have inherited.