Testing AI Agents Before They Touch Production :

Why ordinary testing is not enough

Standard application security testing still matters. It covers the web application, the APIs, and the infrastructure the agents run on. It does not cover the part that decides what to do next. An agent chooses tools at run time based on what it reads, and what it reads can come from anyone. Functional testing has a similar gap. A fixed script checks one path, while an agent can take many. Testing a digital workforce needs its own method, and it should start before the agent is built, with the acceptance cases written down.

First, test the job

Before trying to break an agent, prove that it does the work. Build an acceptance set from real cases, with personal data removed or replaced, and the correct result for each.

• Include ordinary cases, awkward cases, and cases where the right answer is 'I cannot tell from this information'.
• Measure the error rate and compare it with the same work done by people today. That comparison decides whether the agent is worth running.
• Check that the agent stops and asks when it should, instead of guessing.
• Run the set several times. Agents are not perfectly repeatable, and a result that passes once can fail on the next run.
• Keep the set. It becomes the regression test for every future change.

Then, try to make it do the wrong thing

Adversarial testing assumes someone will try to redirect the agent, whether deliberately or through a document that happens to contain instructions. The table at the end of this guide lists the main categories. A few habits make the testing productive.

• Test through the channels the agent actually reads. Instructions hidden in an attached invoice or a forwarded email are more realistic than a hostile chat message.
• Give each test a clear success condition, such as data leaving the agent's scope or an action taken without approval, so results are not a matter of opinion.
• Try the same attack several ways. A defense that blocks one phrasing often misses the next.
• Record every attempt, including the ones that failed. They show what the controls stopped.

Most important: test the controls, not just the model

No current model can be relied on to resist injected instructions every time, so the model cannot be the last line of defense. The controls around it have to be. For each agent, verify directly that the protections hold even when the model has been fooled.

• The tool gateway refuses a call that is not on the agent's list.
• The data layer refuses a read outside the agent's scope, whatever the agent asks for.
• A consequential action cannot happen without a recorded human approval, and the agent cannot approve itself.
• The spending and step limits stop a loop before it becomes expensive.
• The stop switch pauses the agent within the time you promised the owner.
• The log captures each of these events well enough to reconstruct them afterward.

Test the people in the loop

Approval gates depend on people reading what they approve. OWASP's agentic list names the risk directly: an agent, or an attacker working through one, can present a confident and persuasive summary that leads a person to approve something harmful. Test this with planted errors. Send approvers a small number of realistic items with deliberate mistakes and see how many are caught. If few are, the fix is usually in the approval screen: show the evidence, highlight what the agent could not verify, and keep the queue short enough to read.

Scoping a test

Whether the testing is done by your team, your build partner, or an independent firm, agree on these points first.

• Which agents, tools, and data sources are in scope, and which environment the testing runs in. Never test attacks against production data.
• Which categories from the table are in scope, and which are excluded and why.
• What access the testers get: outside only, as a normal user, or with full knowledge of the design.
• What counts as a finding, how severity is judged, and how fast serious findings are reported.
• What the report must contain for your auditors or customers, if anyone else will rely on it.

Findings people can act on

Each finding should give a reproduction someone else can run, the business effect in plain terms, the control that failed or was missing, a specific fix, and a retest result after the fix. 'The agent is vulnerable to prompt injection' is not a finding. 'An instruction hidden in a supplier invoice caused the agent to email the vendor list to an outside address, because outbound email had no approval step' is one.

When to test again

Retest before launch, and again whenever something that shapes the agent's behavior changes: a new or updated model, changed instructions, a new tool, or a new kind of document it reads. Model providers update and retire models on their own schedules, so plan for it. Run the acceptance set on every change, and repeat the adversarial and control tests at least when a change is significant. For agents that make high-stakes decisions or face determined attackers, add periodic red-team exercises by people who did not build the agent.

How LYFYE tests

Every agent LYFYE builds is tested this way before it goes into production: an acceptance set agreed with the department that owns the work, adversarial tests through the channels the agent reads, and direct checks that the controls hold. Our own review agents are set up to try to break the work, not to confirm it. We do not sell standalone penetration test reports for compliance purposes. If your auditor or customer requires an independent test, use an independent firm, and we will give them the design, the test set, and the access they need.