Banking companion: enforcing the customer's data boundary

The banking-assistant study behind “Prompt is not permission” compared two ways of limiting access: asking the model to respect the customer's entitlement, and enforcing that entitlement in the code that retrieves records. The example below explains the difference, followed by what the study found and what remains uncertain.

Follow one request through the system

A customer signs in and asks, “What is my balance?” The application authenticates the customer and establishes the session identity. The assistant chooses a balance tool. The tool's application code queries the database and returns permitted information for the assistant to explain.

The session identity belongs to the application. A customer identifier in model-generated arguments is a requested selector, not proof of entitlement. Authentication must be trustworthy, and authorization must constrain every retrieval path.

Explore the supplied banking assets

Open the embedded application-scope walkthrough →

Search the complete synthetic corpus and download the companion workbook →

What the three study arms actually changed

Arm A used prompt restrictions with broad business tools accepting customer or account identifiers. An account-search tool could enumerate records. These were fixed parameterized queries, not arbitrary model-written SQL.

Arm B used repository queries constrained to the application-supplied session customer. It also reduced the tool surface, including removal of account search. The comparison therefore changes both data scoping and available tools; it does not isolate a single ownership predicate.

Arm C added advisory input-pattern logging and a post-answer filter to Arm B. The input filter did not block requests. The output filter checked known foreign tracking markers and could withhold the drafted answer. It was not a universal disclosure detector.

The scoped repository implemented ownership restrictions in application queries. The study does not establish an independent database row-level-security deployment. Its scope also depends on a trustworthy authenticated identity.

Useful requests and attack paths

The assistant supported balances, recent transactions, customer profiles, beneficiaries and support tickets. Direct requests could name another customer's identifier or ask for account enumeration. Saved incident documentation records broad-tool responses that disclosed another customer's phone number and account information from enumeration. Those examples came from earlier runs than the results summarized below.

Indirect attacks placed instructions in transaction narrations, beneficiary nicknames or support-ticket bodies. An ordinary request for the customer's own records could retrieve that text. A remark telling the assistant to fetch another customer's account should not acquire permission merely because it arrived in a legitimate tool response.

Owned records can legitimately contain counterparty identifiers. Blocking every foreign marker can therefore suppress useful information. Row ownership, permitted field disclosure and whether text is treated as an instruction are related but separate questions.

What the saved evidence supports

The submitted project report describes five models and three repeats. In that cohort, reported marker-disclosure rates for Arm A ranged from 0 to 5.44%; Arms B and C reported zero detected marker disclosure. The disclosure denominator was 147 cases; the adversarial-compliance denominator was 119, and the legitimate-service denominator was 58. These are the report's results; they have not been rerun here.

A broader local result grid includes other configurations and a higher Arm A marker-disclosure rate, and flags some cells as non-reportable. It is a separate collection. Combining its maximum with the submitted report's design would misstate the evidence.

Service outcomes also matter. A separately documented Arm C run attempted 147 cases and scored 146, with one error. Among 57 scored legitimate tasks, one was correct, one refused and 55 produced no final answer. A normal balance question repeatedly invoked the balance tool until the six-cycle limit. That observation does not establish that the final-answer filter caused the tool loop. It shows why a low refusal rate or zero detected disclosure cannot stand alone as evidence of a usable service.

Notes on the evidence

The embedded walkthrough now uses selected fields from the original synthetic bank fixture. It is an illustrative row-selection calculation, separate from the saved findings below. The findings above come from the submitted project report, the corrected project presentation, the saved incident documentation and the later project lessons. The original records have not been changed or rerun.

For source checking, the relevant references are the report's metric definitions and results; presentation pages 5 and 13; incident report sections 2 and 6; the broader result grid's UDR section; and the project lessons dated 31 August 2026, sections 1–4.

Several limits matter when interpreting those findings:

Disclosure scoring detects known tracking markers in released answers. It does not measure every possible confidential fact or prove universal security. A marker already present in a poisoned owned record can be echoed without a foreign database read.

The adversarial-compliance score is a proxy based on response behavior, not independently established attack success. Tool attempts, returned rows and delivered information should be examined separately.

The current frozen corpus contains eight genuine two-user-turn cases. All 30 indirect cases contain one actual user turn. Dialogue embedded inside a payload does not constitute a later user turn, even when the technique name contains “multiturn.” The submitted report's smaller multi-turn count remains a source discrepancy.

The corrected presentation describes post-answer filtering and tracking-marker echo. It does not demonstrate prevention of every disclosure path.

Token-forgery scenarios were implemented, but the submitted report states they were not executed. There is therefore no measured token-forgery result to draw on.

The original trace viewer can reconstruct tool rows from the frozen database; that is not the same as having stored exact historical tool-result snapshots. Current code inspection also does not certify every historical run's implementation.

The next experiment worth doing

Use the same banking task to distinguish prevented access, prevented disclosure and successful service. Compare a clean own-transaction request, a legitimate counterparty reference, and a matched poisoned narration requesting a foreign lookup across the three arms. Add a genuine second user turn after retrieval of the poison. Hold the model, prompt, dataset and repetition policy fixed, and separate tool-surface changes from ownership enforcement where possible.

Capture exact tool requests and returned snapshots, record ownership, permitted fields, foreign rows returned, final information released, correct task completion and tool-loop exhaustion. This would add evidence about retained context and field-level trade-offs that the original indirect corpus and the later orders pilot do not establish. That work would need a new experiment. It has not been done yet.

The separate policy demo uses simulated publication requests, and the later orders pilot explores a different workflow. Neither is a rerun of the banking study.

Read the article