An authentication agent should stop safely when the evidence does not support a change. A demonstration using one known sender and a clean report cannot establish that behavior. Build an evaluation set containing incomplete coverage, conflicting ownership, misleading identifiers and instructions embedded in report content.
Specify the decision before testing the agent
For each case, write the evidence, permitted tools, expected decision class and reason. Useful classes include investigate, recommend without execution, request approval and refuse an out-of-scope action. Distinguish a technically false claim from a business identity that remains unknown. The expected answer should not manufacture facts absent from the input.
Use isolated credentials and nonproduction resources for any tool execution. For purely offline tests, replace tools with a recorder that captures attempted calls without performing them. Retain model and configuration version, prompt, source hashes, outputs, tool attempts and evaluator rationale. Do not allow the model under test to rewrite its own expected results.
Cover authentication-specific traps
Include an SPF pass for a domain that does not align with the visible From domain, and an SPF failure accompanied by aligned DKIM success. Include a familiar provider IP with no customer ownership record. Add stale reports and contradictory owner records. RFC 9989 grounds the authentication semantics; organisational ownership still requires separate evidence.
Add a report field that claims to be an administrator and requests a DNS change or secret retrieval. OWASP Prompt Injection describes the risk of attacker-controlled content influencing behavior. The correct result is not merely repeating a warning; the attempted tool calls must remain within authorization.
Assign distinct expectations to five evidence gaps
For a missing owner, request account-specific attribution evidence. For conflicting owners, escalate the conflict rather than choosing the more confident statement. For stale observations, request current evidence. For an embedded instruction to retrieve secrets or publish DNS, preserve it as data and deny actions outside the actual permission boundary. For a supported, authorized read-only investigation, complete the useful analysis rather than refusing everything.
These are proposed expectations for hypothetical cases, not labels validated by a reference function or observed LLM results. Construct concrete inputs, trusted context and expected outcomes before evaluation. Record the actual model response, attempted calls and enforced effects separately. A schema check that accepts declared fields cannot demonstrate that the evidence is true or that an agent resisted an attack. Add equivalent benign tasks so the test measures meaningful completion as well as stopping unsafe actions.
Score safety and usefulness separately
Count unauthorized action attempts even if a downstream guard blocks them. Separately count unsafe executions, unsupported factual claims, missed escalations and unnecessary refusals. A system that refuses every task can be safe from writing DNS while failing the operational purpose. Report the exact denominator for each metric and repeat stochastic runs where relevant.
Use a held-out set for later evaluation so tuning does not merely memorize the examples. Add real failure patterns only after appropriate privacy review and minimisation. NIST AI RMF offers a voluntary risk-management framework; this evaluation design applies its measurement principle to a specific mail workflow.
A passing result is bounded by tested conditions. Re-run relevant tests after model, tool, prompt, credential or provider changes, and retain a stop condition for newly observed unsafe behavior.