A support console lets any agent open any customer's full record — how do you model and answer that disclosure risk?
answer
- Nothing is broken; the design grants it
- Identity controls never fire here
- Shrink the read, or see the read
- One compromised agent equals everyone
- Residual risk with a named owner
basics
~20 sThis is Information Disclosure where the reader is authorised, so identity-based controls never fire. Answer with narrower reads — lookups scoped to an open case, only the fields needed — plus per-agent volume detection, and record what remains as accepted risk.
solid answer
~50 sThis is the Information Disclosure case people miss, because nothing is broken: the design grants the read, so authentication succeeds, authorisation says yes, and protections that sit below the application hand over plaintext for a legitimate query. The threat is a curious, disgruntled or phished agent seeing customer data they had no business reason to see. Because you cannot block the read outright — support must see data to do the job — the answer is to shrink each read and make the exceptional read expensive. Scope lookups to a customer with an open case rather than free search over everyone; return the fields the workflow needs and reveal the sensitive ones on request instead of by default; require a documented reason for anything outside the current case. Then detect: per-agent read volume, off-hours and out-of-region patterns, periodic review. Record what remains as accepted residual risk with an owner.
go deeper
Be ready to say that a legitimate user reading data they had no business reason to read is still an information-disclosure threat, and that the record of who looked is what makes it noticeable.
Explain why authentication and storage-layer protection do not fire when the reader is authorised, and describe narrower reads: case-scoped lookup, only the fields the workflow needs, sensitive values revealed on an explicit action.
Show that you rate the breadth of standing access rather than the single lookup, and that you treat one compromised agent account as equivalent to the whole customer base. Pair prevention with per-agent volume detection someone actually reads.
Own the position that this risk is managed, not eliminated: where the friction budget goes, which fields justify the strongest controls, how you avoid pushing support into workarounds, and what residual risk you sign off with a revisit trigger.
## Why this one is hard Every other Information Disclosure finding has a moment where a control could have said no. Here there is none. The agent is who they claim to be, the role grants the read, and the application decrypts and renders the record because that is what it was built to do. The threat is not a flaw in a mechanism — it is a **property of the design**: broad standing access to sensitive data, held by many people, checked by nothing at the moment of use. The attacker position is the insider with legitimate access, and the asset is customer personal data. The variants are worth naming, because they need different answers: - **Curiosity** — looking up a public figure, a neighbour, an ex-partner. High volume, low sophistication, the most common by far. - **Grievance or gain** — an agent taking data on the way out, or selling lookups. - **Coercion or compromise** — the agent's account is phished or their session hijacked, and the attacker inherits *exactly* the broad read the design grants. This is why the design property matters even if you trust every employee: the blast radius of one compromised agent equals the whole customer base. ## What does not work Be explicit about the controls that feel right and do nothing here: - **Stronger authentication** raises the bar for becoming the agent; it does not narrow what the agent may then read. It genuinely helps the compromise variant and not the other two. - **Protecting the data below the application** does not fire, because the application is entitled to the data and hands it to the caller in the clear. - **A blanket policy document** creates a rule with no enforcement point. It matters for the disciplinary path, not for the threat. The useful controls all attack one of two quantities: how much each read exposes, or how visible a read is. ## Shrinking each read - **Relationship or case scoping.** The lookup requires an open case that names the customer, or a caller verified in the current session. Free search over the whole customer base becomes the exception rather than the default. - **Field minimisation.** The screen shows what the workflow needs. Full identifiers, dates of birth and payment details are hidden by default and revealed on an explicit action that is recorded — the reveal becomes a deliberate, attributable act rather than a side effect of opening a page. - **Search that returns matches, not records.** "Yes, this reference belongs to an account" answers most support questions without rendering the account. - **Time-bounded access.** Elevated views expire with the case rather than persisting for the agent's employment. - **An expensive exception path.** Out-of-case access needs a stated reason, or a second person's approval for the most sensitive fields. Friction is the point; the cost is what makes casual browsing not worth it. ## Making reads visible What you cannot prevent, you detect: - **Per-agent read volume** against their own baseline and their team's — the strongest single signal for curiosity browsing. - **Pattern alerts** — access with no matching case, bursts on a small set of accounts, unusual hours or locations. - **Notable-account monitoring** for records that attract attention. - **Review** by the agent's manager, and a customer-facing path so "who looked at my account" is an answerable question. Detection is a genuine mitigation here, not a consolation prize: for insider misuse, the credible deterrent is a high chance of being noticed, and the control's value depends on someone actually reading the alerts. ## The judgment call You will not drive this risk to zero without breaking support, so the principal-level output is a defended position rather than a fix: 1. **Rate what a single agent can reach.** If the answer is "every customer, forever, unlogged", that is the finding — the volume, not the individual lookup. 2. **Spend where sensitivity is highest.** Not every field deserves reveal-on-demand; the ones whose exposure harms the customer directly do. 3. **Measure the friction.** Case-scoped access has a real cost in handling time, and a control that makes support unworkable gets routed around — the workaround becomes the new, unmodelled channel. 4. **Write down the residual.** Threat, controls applied, what remains, who owns it, and the trigger for revisiting — a new data category, a bigger support organisation, an outsourced tier. One more framing worth offering unprompted: this is **Information Disclosure, not Elevation of Privilege**. No boundary was crossed; the design handed over the privilege. If an agent had exploited a flaw to reach data outside their role, that would be a different letter and a different fix. Naming that distinction correctly is a good marker that the candidate models properties rather than pattern-matching on "insider".
- Why is this Information Disclosure rather than Elevation of Privilege?Because no privilege boundary is crossed. The role already grants the read, so nothing was escalated — the property lost is confidentiality of customer data, which is Information Disclosure. Elevation would be the agent exploiting a flaw to reach data their role does not cover, such as another tenant's records or an administrative function. The distinction matters because the fixes differ: narrower grants and detection here, a fixed boundary check there.
- The team proposes stronger authentication for agents. Does that address the threat?Only one variant of it. Stronger authentication makes it harder for an outsider to become the agent, which reduces the compromised-account case, and that is worth doing. It does nothing about a genuine agent browsing out of curiosity or for gain, because that person passes every check. The threat is the breadth of the grant, so the controls that move it are scoping, field minimisation and read visibility.
- How do you decide how far to go, given support has to see customer data?Rate by what one agent can reach and how sensitive it is, not by whether a single lookup is legitimate. Spend the strongest controls on the fields whose exposure harms the customer directly, keep the common workflow fast, and measure handling-time impact — a control support routes around creates an unmodelled channel. Then write the remainder down as accepted residual risk with an owner and a revisit trigger.
It is the difference between a locked filing room and one where every clerk holds a master key. The lock works perfectly; the question is why one person's key opens every drawer.
saying these in an interview costs you the question
- Says it is fine because agents are trusted employees
- Answers with stronger authentication for agents
- Calls it Elevation of Privilege though the role grants it
- Treats a policy document as the control
- Assumes protecting stored data stops an authorised read