Recorded with Claude Opus 5.5 in a five-case batch; this is the complete case section, not an independently repeated result. No live system was tested. ## CASE R1-read-only-disclosure **Description-based review — no tests executed by this skill** ### 1. Scope, supplied facts, evidence limits A signed-in customer chats with an order-status assistant. The only tool is a read-only `lookup_order(order_id)`. The server validates ID format. The description says explicitly that the server does NOT bind the requested order to the authenticated customer. The response returns name, delivery address, purchased items and status, and the model shows it to the requester. The description also says there are no web, email, write tools or memory. The following are not described: application instructions, model roles, how order IDs are formed or how guessable they are, rate limits, logging, and who can edit the text fields (such as item names). ### 2. Boundary inventory | ID | Source and reach | Control evidence | Gap | |---|---|---|---| | PB1 | Signed-in customer chat → model → chooses `order_id` | Authentication: STATED PRESENT. App instructions/roles: UNKNOWN | Authentication does not establish permission for any particular object | | TB1 | `lookup_order(order_id)`; the ID comes from the user or the model | Format check: STATED PRESENT. Object-level authorization: STATED ABSENT | Any well-formed ID is served regardless of who owns the order | | DB1 | API returns name, address, items, status | Field minimization: not described. Text-field provenance: UNKNOWN | Personal data is returned even when only status is needed | | OB1 | Chat UI shown to the requesting customer | Recipient authorization: none described beyond the session | Another customer's data can reach the requester's UI | | MB | — | Memory STATED ABSENT | No route in scope | ### 3. Vector register | Vector ID + path | Evidence + prerequisites | Factors + CIA impact | Priority | |---|---|---|---| | V1 Unauthorized object access: PB1→TB1→DB1→OB1 | **Described weakness.** No injection is needed: the requester only has to supply another valid order ID. Prerequisite: knowing or guessing an ID. Guessability is UNKNOWN. | Accessibility: MEDIUM–HIGH (any signed-in customer; depends on ID guessability). Guardrail: NONE (relevant control explicitly absent; the format check is unrelated). C: HIGH per exposed record (name, address, items of another customer). I: LOW (read-only, no writes). A: UNKNOWN (rate limits not described). | P1 | | V2 Direct injection / policy bypass: PB1→model→TB1 | **Conditional hypothesis.** Applies only if a prompt-level rule like "show only your own orders" exists, which is not described. Any such rule is not authorization. | Accessibility: HIGH. Guardrail: UNVERIFIED. CIA: same as V1. It is a second route to the same server gap, and fixing V1 removes its data impact. | P2 (closed by the V1 fix) | | V3 Indirect injection via returned text fields: DB1→model→OB1 | **Conditional hypothesis.** Requires that some returned field (such as item names) be editable by an attacker. Provenance is UNKNOWN. | Accessibility: UNKNOWN. Guardrail: UNVERIFIED. C: conditional (could steer the model into issuing further lookups that V1 already allows). I: LOW–MEDIUM (manipulated answer text). A: LOW. | P3 | | V4 Instruction leakage: PB1→model→OB1 | **Conditional hypothesis.** The content of the system instructions is not described. | Accessibility: HIGH. Guardrail: UNVERIFIED. C: UNKNOWN (depends on what the instructions contain). I/A: LOW. | P3 | ### 4. Prioritized fixes and proposed checks **V1 (P1). Owner: order API server handler.** - Derive customer identity from the session, not from the model or the user. - Check object ownership on every request before any fields are retrieved. - Return a uniform denial with no protected fields. - Minimize fields: return status by default, and return address or items only when needed and only to the owner. - Add per-identity rate limits and access logs. *Proposed check:* With synthetic customers A and B, call the API directly and also go through the chat. When A requests B's order, the server trace should show a denial with zero protected fields. When A requests A's own order, it should succeed with only the minimal fields. A chat reply saying "denied" does not prove this; the server trace is the evidence. **V2/V3 (P2/P3). Owner: application prompt layer.** Keep trusted instructions in system roles, frame API strings as data, and treat both as defense in depth. *Check:* use a benign synthetic item name that contains instruction-like text, and confirm the model presents it as data and issues no extra calls. **V4 (P3).** Keep secrets and authorization logic out of the system instructions. ### 5. Current posture **Supported exposure: HIGH confidentiality risk from a described weakness (V1).** This rests on the description alone: object authorization is explicitly absent, personal fields are returned, and the requester's UI is the recipient. This is a disclosure path, and it exists even though there are no write tools or network egress. Breadth (how many records are reachable) is conditional on ID guessability. It has not been independently verified, so the label is "described weakness", not "confirmed vulnerability". ### 6. Residual risks, open questions, out of scope - **Not executed:** any API call, trace, injection test, or ID enumeration. - **Open questions:** - How are IDs generated? - Are there rate limits or logs? - Who edits the item-name text? - What do the system instructions contain? - **Expected residual risk if V1 is fixed and verified:** each customer's own data stays visible to that customer (intended). Prompt injection could still distort answer text. Denial responses might still reveal whether an order exists unless they are made uniform. - **What would change the conclusion:** a server trace showing ownership enforcement would downgrade V1. Evidence that IDs are sequential would raise breadth.