How do you evaluate an AI agent for private-data exposure across tools?

Evaluate private-data exposure as a bounded session property, not the result of one blocked action. Pre-register governed test targets and recipient authorization, declare every requester-visible and external exit, measure their union alongside normal task success, and reserve internal records for diagnosis.

Checking that an agent did not send one email, call one guarded API, or reveal a value in its final answer is useful. It does not establish what a recipient could see across the whole workflow. Tool-using agents can produce values in responses, previews, console feedback, files, notifications, and other interface-visible outputs.

ASLEval calls the gap between a local evaluation proxy and target-grounded exposure across a bounded session “privacy exposure displacement.” Its protocol fixes hidden targets, authorization, an expected outlet, and declared visible exits before the run. That suggests a practical test-design question: which outputs can the requester or an external recipient actually see during this workflow?

Separate the privacy question from the logging question

Both boundaries matter. An encrypted trace store does not make a console response safe for an unauthorized requester. A clean visible-output test does not decide whether a trace pipeline retains too much content.

NIST describes its Privacy Framework as a voluntary tool for identifying and managing privacy risk. Use that broader risk-management frame, but do not treat one test as a compliance verdict. For the telemetry boundary, start with protecting agent telemetry data.

Write the evaluation contract before the run

1. Governed target set.Create safe synthetic stand-ins for sensitive values relevant to the scenario. Give each a canonical form, controlled aliases, and provenance. Keep the target list outside the agent's prompt and inaccessible to the probe.
2. Recipient authorization. Record which recipient may receive which target. Agent access to a workspace is not, by itself, authorization for every requester or downstream recipient to receive its contents.
3. Visible-exit register. List every output surface visible to the requester or an external recipient: final response, streamed text, console or UI feedback, generated file, message, callback, and product-specific preview.
4. Diagnostic-record boundary. List internal tool arguments, returns, and execution metadata separately. Permit evaluator inspection through a restricted test path without counting those records as direct requester-visible exposure.
5. Utility measure. Define the task result that must remain meaningful: successful completion, correct state change, or another existing acceptance check.

Record output and recipient boundaries at the tool edge in a custom MCP server production plan. Do not decide what counts as exposure only after a surprising result.

Measure the visible-exit union

Run interface-valid scenarios with the governed targets. For each observed match, record the exit, recipient, target ID, authorization result, run ID, and release or policy version.

Calculate the union first, then preserve the per-exit evidence. The union answers whether the bounded session exposed the target; the per-exit view shows whether the failure occurred in a final response, preview, message, or another declared surface.

In ASLEval's common-log analysis of 245 exported sessions, an expected-outlet-only view missed 46.9% of the exposure recovered by that paper's declared-visible-exit union. This is a result from the preprint's synthetic setting—not a rate to copy into a production risk register.

Pair privacy with normal task success

“No exposure” is not sufficient if the control simply stops the workflow from doing useful work. Report both outcomes for the same build.

In the preprint's deliberately coarse minimization experiment, reduced model-visible returns coincided with zero measured unauthorized visible exposure and zero deterministic task success in a 15-task normal slice. The authors state that this does not characterize an optimized selective-return policy. The useful lesson is to measure the tradeoff, not to copy the intervention.

Use internal records to diagnose, not redefine the result

• Determine the exposure result from what the scoped recipient could see, not from an internal trace alone.
• Treat temporal ordering as diagnostic evidence rather than proof of causation unless the instrumentation records that relationship.
• Give test records a narrow audience and retention period. Do not expand general production logging merely to make one evaluation easier.

Turn the contract into a release check

Keep privacy cases beside the stable task suite when you evaluate agent harness changes. If a case fails, use verify–repair stopping rules to keep the repair loop finite and reviewable.

This gate supports a claim only about the targets, recipient assumptions, visible exits, and scenarios declared. It cannot prove that undeclared paths are safe or that a real-world policy will be applied correctly in every context.