Data plumbing · Auth and the boundary

Which credentials does the pilot need

Write the one-page credential list the customer keeps — each principal, what it reads and writes, what leaves the tenant and how revocation was tested — and defend it against a convenient shortcut.

designhardExercise · 4 min · 32 of 64

On this page

The security team wants the pilot's credential list by Friday, the DBA has offered a shortcut that works today, and you need to debug on site. The design is a one-page list that survives all three.

The situation

The triage pilot runs in the customer's cloud tenant, as module 3 decided. It reads the claims, policy and payments views in the tenant's managed database and the 340-page policy wording as PDFs in an object storage bucket, and it calls a hosted model API outside the tenant. It writes three tables: pilot.triage_output, a 30-day prompt log and the redaction's token map. The DBA, helpful and busy, offers the existing reporting account — SELECT on 80 tables, including the base claims tables with names, dates of birth and bank details — available today; a scoped role would take two weeks. You need to read prompts and outputs to debug, and last week you did that from your laptop under your own SSO session. The security team's questionnaire asks for every principal, what it reads, what it writes, what leaves the tenant, who revokes it and how you proved revocation works. The pilot is eight weeks at 1,200 claims a day, and the backfill for the eval set is waiting on the data.

The question

Write the credential list the customer keeps — each principal, its mechanism, exactly what it may read and write, and the revocation test — and decide what you do about the reporting account and your own debugging access.

A strong answer · Rubric · Where answers go wrong

Write your answer first, then open

A strong answer

Four entries, following auth and the boundary.

pilot-triage-svc, a workload identity: no stored secret. Role pilot_reader: SELECT on claims.fnol_v, policy.terms_v, docs.wording_v and payments.invoices_v, with a row filter to the three lines of business and claims since the pilot start; INSERT on pilot.triage_output, pilot.prompt_log and pilot.token_map; read on the wording's bucket prefix. No structured personal columns are in the views; the loss description is, and the service redacts it before any prompt.

The model API key, project-scoped, in the tenant's secret manager, readable by the service only, rotated at handover, revoked by the IAM lead deleting it. What crosses the boundary: the redacted loss description and the policy wording, nothing else.

You, through the customer's SSO as a named account in pilot-engineers, expiring at pilot end plus 14 days: read on pilot.triage_output and the prompt log. No grant on base tables; a raw row comes from the DBA with you watching. The IAM lead revokes it by removing you.

The reporting account: declined for the daily feed, since a leaked key exposes 80 tables and "which personal data does the service read" becomes "all of it". If the backfill cannot wait two weeks, one supervised run with the DBA, the grant removed the same day, dated on the list.

Revocation test, first live day: the IAM lead disables the identity; the poll fails within 60 seconds and the queue stops; the log line is attached. What would change the design: an on-premises database with nothing in front of it makes the first entry a service account, its key in the secret manager, rotated every 90 days by a named rotator.

Rubric

separates the service's principal from the engineer's, and gives the engineer's an end date
names the exact views, the operation and the row filter, not "read access to claims"
picks the mechanism from where the service runs and says what changes if that moves
keeps the model API key in the tenant and states what crosses the boundary
declines the 80-table account for the daily feed, with the reason the questionnaire will ask
includes a revocation test with a recorded result, not a promise

Where answers go wrong

"Use reporting for the pilot and scope it down later." Later is week 7. The questionnaire lists 80 tables against the pilot, the security team reads it the week before renewal, and nobody can say which of the 80 the service touched.

"The service runs under my SSO while I am on site; I am there anyway." The session expires at 02:00, the queue stops until 09:30, and the audit log shows one person reading 1,200 claims a day — the first item on the security review's agenda.

"Least privilege: the service gets read-only access to the claims data." That is a principle, not a list. The reviewer cannot verify it, the DBA cannot implement it, and the answer to "which personal data" is still unknown.