Sanctioned AI Assistant, Shadow Uploads, and a Tenant-Wide OAuth Grant
Northwind Health (6,200 staff) approved one enterprise generative-AI assistant 90 days ago; it now has 1,800 weekly active users. Three findings cannot be reconciled. First, proxy and CASB telemetry shows 38 distinct unsanctioned AI tools used in the last 30 days, including 214 users who uploaded more than five files per week to one consumer chat tool. Second, identity logs show a tenant-wide OAuth consent granted to a note-taking app requesting Mail.Read and offline_access across all 6,200 mailboxes; the vendor's marketing page advertises an 'AI summarizer'. Third, the 140-person research division says it will miss a clinical-trial deadline in six weeks unless the sanctioned assistant can accept full protocol documents, which contain PHI. There is one engineer assigned to AI security this quarter, and a hard rule that patient data cannot leave the approved tenant. Outright category blocking requires a legal review that takes three weeks.
1. Rank the three findings by the order in which you would act, and justify the ranking by the loss each one can cause.
Read the worked answer
Rank by (1) whether exfiltration or abuse is happening now, (2) blast radius, and (3) how quickly the actor can be evicted.
First: the OAuth grant. It is the only finding with machine-speed, user-independent access to 6,200 mailboxes. A token with Mail.Read and offline_access survives password resets and does not need a user to click again. Containment is revoke the grant, then hunt the token's mailbox access history and mailbox-rule creation, then check for any second app consent from the same publisher.
Second: the 214-user upload pattern. This is likely PHI leaving the tenant today, so it is a reportable-event risk, but it is human-paced and the content volume is bounded. Throttle it at the egress layer (block uploads in the generative-AI category while still permitting read access) rather than blocking the category, notify the affected users, preserve logs for legal.
Third: the 38-app inventory. Breadth looks alarming but most entries will be low-volume browser tools. Its value is as input to policy design, not as an incident.
The research deadline is not a security event; it is the constraint that shapes how you build the exception path in the next task. Doing the OAuth work first also buys the credibility needed to negotiate that path.
2. Design a control that lets the research team submit full protocol documents while keeping PHI inside the approved tenant. State what must be true for it to work and what you will not rely on.
Read the worked answer
The control has to move the inspection point to the tenant boundary rather than trying to classify content inside a consumer chat box.
Required elements: a tenant-restricted assistant instance with a written zero-retention and no-training commitment; pre-send DLP that classifies protocol documents and either blocks unsafe field types (direct identifiers) or routes them to a private deployment inside the approved tenant; tenant restrictions so identity cannot be used to sign in to other tenants' AI services; egress rules permitting only the sanctioned AI endpoints, with the sanctioned app's audit API feeding the SIEM; a managed browser or endpoint agent that owns clipboard and file-upload behaviour for the research group so paste-around does not bypass the policy.
What must be true: the DLP can recognize protocol documents as a data class with acceptable false-positive rate on a sample the research team supplies; legal can approve the private-deployment exception in under six weeks; and the research team accepts a per-file review step for the first month.
What I will not rely on: user training as the only control, category blocking after the upload has begun, filename or keyword matching alone, and the vendor's marketing page as evidence of retention behaviour. If the private deployment cannot be stood up in time, the honest answer is a scoped six-week exception on one endpoint with logging and a named owner, not a policy everyone routes around.
3. Which telemetry would you add to detect exfiltration through the sanctioned assistant itself, given that prompt content sits inside an encrypted session?
Read the worked answer
Accept that full content inspection of a pinned, encrypted AI session is not reliably achievable without breaking the client, so build detection from metadata plus endpoint context.
Layers: (1) the sanctioned app's security API, if it exposes per-user request counts, attachment metadata, and model or connector configuration changes; (2) TLS forward proxy on a defined user cohort (research and finance first), with decryption exceptions documented per destination; (3) endpoint telemetry for paste volume and file reads preceding a request to an AI domain; (4) UEBA baselines on outbound request size, session length, and hour-of-day per identity, alerting on deviations rather than absolute thresholds; (5) identity-side signals, because a token theft will show as access from a new ASN with the same user agent.
The design rule is that no single layer must be complete. A user pasting a 40-page protocol into the chat should trip endpoint paste-volume and egress size together, which is enough to open a case even without payload. Test the detection with a controlled exercise before claiming coverage, and record the expected detection latency for each layer so the 90-day review has a number to compare against.