Hiding data on screen is not enough if the AI judge's notes still hold it

Hiding sensitive data in the interface does not mean it is protected. Al Chen of Cisco argued on the AI Engineer show that an AI judge can still carry customer data in its written reasoning behind the screen. Chen said the stronger fix, a second judge reading redacted input, costs an extra model call on the same request.

What was said

Chen was describing how his team gets AI agents into major banks. Most banks think nothing sensitive leaks outside their private network, he said, but side doors may be open. He named two kinds of data: PII, meaning personal details about customers, and MNPI, meaning material non-public information. Redaction can happen in the SDK, at the gateway or in middleware.

On the interface, customer details look hidden. Chen asked about the judges. An LLM judge is a second model that scores how well an agent did a task and explains the score. His example prompt had one line asking for that explanation, so a human reviewer could check the work. He said that line may have let the judge repeat raw PII or MNPI. In his words: "So your UI still looks good, but then on the back end, your LLMS judge's reasoning may unredact customer information". He challenged the audience to read their judges' system prompts and check the traces.

He offered two fixes. First, let the judge read raw data, but do not store its reasoning. The score always shows. Application code checks whether the record is sensitive and suppresses the reasoning if it is. Second, add a judge whose input is already redacted, so its output can be trusted as clean. The price, he said: "having zero leakage and data sovereignty is not free." He tied that cost to running another model call on the same request.

Why it matters

Our reading: redaction has to be checked where text is saved, not only where it is displayed. A judge's explanation is output like any other, and it can land in traces and logs. Teams that added masking to the interface may believe they are covered when they are not.

For buyers, this is a question to put to vendors: where do judge explanations go, and who can read them? For builders, the stronger fix is a line in the budget. Chen's wider theme was showing your work to security teams. Evidence of how a judge is kept clean is part of that.

The other side

Chen hedged his wording. He said the prompt line may have let a judge leak data. He gave no figures on how often this happens, and the excerpt describes no confirmed leak at a bank.

The fixes have limits too. Suppressing reasoning removes what Chen said most banks want to see. The sensitivity check in application code is only as good as the check itself, and the talk did not say how reliable it is. It also did not say whether a judge reading redacted input scores as well as one reading raw data. The cost of the second judge was described only as one more model call, with no dollar figure.