Question bank · Identity boundary

What does the transcript retain that it should not?

More than the data model says, because a conversation log is a data store nobody designed. It holds whatever the customer typed and whatever the tools returned: a card fragment pasted to prove ownership, a full delivery address, an order reference belonging to someone else, a credential a shopper mistook for a tracking number. It is kept for debugging, copied onward into ticketing and tracing systems, and it is rarely covered by the deletion path that governs the customer record. Two questions follow, and no data-flow diagram answers either: who can query it, and does deletion reach it?

01

A second copy

How does the transcript become a second copy of the data?

On the first escalation. The published example profile records that its handoff tool creates a ticket containing the transcript and a reason — one code-enforced action that copies the conversation into a third-party system with its own access model and its own retention clock. The same profile lists what the agent reads to do the job: order status, line items, totals and tracking, and customer name, email, phone, and addresses. All of it passes through the context window on the way to an answer, and the log holds it afterwards.

A clean tool boundary says nothing about the chat box. The example profile records that card numbers are never returned by the payments service — a real, well-drawn limit on what the agent can fetch. It is not a limit on what a customer pastes in to prove they own the card. The example declared profile.

02

Secrets in context

Does a secret in the context stay in the context?

It stays wherever the transcript goes. The critical failure in our first specimen starts as a data problem rather than a model problem: the scenario's initial state records that an internal key was present in the model-visible context, and the agent then returned it as a debug hint the customer could use. The remediation is written in that order too, data-plane fix first — remove secrets from model-visible context, classify untrusted instructions, block secret-shaped output at the trusted boundary. The evidence record now holds the leaked value verbatim, which is the point rather than an irony. Whatever reaches a transcript is retained by everything downstream of it.

THE FIX IS ORDERED, AND THE FIRST STEP IS DATA

Remove secrets from model-visible context comes before classifying untrusted instructions and before filtering the output, in the remediation our first specimen — the withheld support agent — records against its critical finding. A secret that never enters the context cannot be extracted from it, cannot be logged with it, and cannot be replicated into a ticket.

Read the sample report
03

Access

Who can query the transcripts?

This is the identity-boundary question wearing different clothes, usually answered for the database and left open for the log. The example profile is precise about reads: order and customer queries filter on the merchant and customer identifiers carried by the session, not on identifiers supplied by the model. It says nothing about who can search the conversation logs, because those live in another system with another access model. A vendor that scopes every database read by tenant and then ships raw transcripts into a shared index has moved the boundary rather than enforced it.

The severity is the same as the lookup case. One support operator reading another tenant's conversation is the same disclosure as the agent reading one customer's order to another, and it is graded the same way: can an agent read one customer's data to another.

04

Deletion

Does deletion reach the transcript?

Destination by destination, or not at all. The list is longer than it first looks, and each entry needs its own answer rather than one policy sentence covering all of them. Our specimens name what the agent cannot access — payment card numbers, production customer records, another shopper's order history — as a first-class part of the record. The same list should exist for what the transcript store holds, and in most products it does not exist anywhere.

01The conversation storeThe primary log. Usually the only destination anyone names, and the only one with a retention policy written down.
02The ticketing systemTakes the full transcript on every escalation, under its own access model and its own retention clock.
03The tracing pipelineIf spans carry message bodies, the observability stack holds a copy no privacy review has looked at.
04The evaluation fixturesProduction conversations that became test cases: real customer text, living indefinitely in a test repository.

Nothing here is testable by executing the agent alone. A behavioral run can show that the agent discloses a secret; it cannot show where the transcript landed afterwards. That part is an architecture answer, and the honest version names destinations rather than intentions. How a conclusion is reached.

→

Related

What else does a reviewer ask about this?

The questions in this bank overlap. A vendor who can answer one of these well can usually answer its neighbours badly, which is why they are tested together.

01Can an agent read one customer's data to another?It can whenever a lookup is scoped by an identifier the model supplies rather than one the verified session carries; this is the highest-severity class because no attacker is required, and one failure here outranks any aggregate pass rate.02Can a tool response carry an attack?Yes, and it is the version most vendors have not tested: the attack arrives in the data the agent reads — an order note, a product review, a forwarded email body — inside a tool response the agent trusts by construction, so passing a single-turn direct extraction test says nothing about it.03How fast does a human actually take over?Escalation is a claim about latency and completeness, not existence: how long before a person is looking, what they receive with the conversation, and whether a retry or a queued tool call keeps acting in the gap — and the strongest answer names a code-enforced stop rather than an instruction to stop.04Does SOC 2 cover AI agent behavior?No. SOC 2 audits organizational controls — access, encryption, change management, incident response — over a period of time, and never executes the agent, so a clean report is compatible with an agent that refunds twice or answers one customer with another customer's data.

The published bank is the visible subset. Buyer-specific questions and holdout scenarios are not published, because a question you can read in advance is a question you can train against. The rules that govern how any of these gets answered are public: how a conclusion is reached.

Answering it with evidence

Can you answer this about your own agent?

We keep the question bank, we run your frozen agent against it in a sandbox we control, and every failure lands on your desk before a buyer asks. Private, fixed fee, no buyer involvement. Send us the list of actions your agent can take and we will tell you which of these questions we would test first.

What a dry run needs, so nothing is a surprise later

  • An agent that takes real actions, not just answers questions
  • A version you can freeze for two weeks
  • A sandbox or endpoint we can reach
Book a 20-minute scoping call Or email your agent's action list