Data plumbing · Auth and the boundary

Auth and the boundary

Choose how the pilot service authenticates to customer data — client credentials, a service account or workload identity — keep your own access separate, and write the grant list the customer keeps.

Lesson · 9 min · 29 of 64

On this page

The pilot's service reads 1,200 claims a day from a database that also holds two million policyholders. The question the customer's security team asks is not whether the model is accurate; it is what, precisely, this service can do if its credential leaks. The answer is a short written list, and how the service authenticates decides how short.

Three ways a service proves who it is

OAuth 2.0 client credentials. The service is registered as a client in the customer's authorisation server and holds a client_id and a client_secret. It posts them to the token endpoint and receives a bearer token scoped to, say, claims.read, valid for 3,600 seconds; every data request carries the token, never the secret. This is the grant for a service calling an HTTP API inside the customer's identity domain (RFC 6749, section 4.4 (opens in a new tab)). The secret is long-lived and sits in the customer's secret manager; the token is short-lived and crosses the wire.

A service account. A database user or platform account with a password or key. This is what most on-premises claims systems offer, having no authorisation server in front of the database. The key is long-lived, so the only controls are the role it holds, where it is stored — the customer's secret manager, never a config file — and how often it rotates. Ninety days is common; at minimum once at handover, so the key you knew is not the key that runs.

Workload identity. The platform attests the running workload — this container, in this project, in this tenant — and issues short-lived credentials to it automatically. Nothing to store, nothing to rotate, no secret. It is available when the service runs in the customer's cloud tenant and the data sits in that tenant's managed services, one reason security teams prefer the in-tenant placement from module 3.

Mechanism	What you hold	Lifetime	Rotation	Fits when
Client credentials	a client secret	token: 1 hour	the secret, on a schedule	the data is behind an HTTP API in the customer's identity domain
Service account	a key or password	until rotated	manual, 90 days	a database with no authorisation server in front
Workload identity	nothing	minutes to an hour	automatic	the service and the data share a cloud tenant

The short lifetimes cost nothing: a token lives 60 minutes and the service refreshes at 50; at the 4-claims-a-minute peak one token covers 200 claims, and the token endpoint sees about twelve requests a day. The point is that a token lifted from a log is useless within the hour, and the secret crosses the wire only to the token endpoint, never to the data API.

The secret crosses the wire once per hour, to one endpoint; the data requests carry only the token. A refused refresh is the customer switching the pilot off, and the service treats it as an order.

The exchange, step by step

The service posts grant_type=client_credentials, its id, its secret and the scope it wants; the authorisation server answers with an access token and expires_in. Each poll of the claims API carries Authorization: Bearer and the token; the API checks scope and expiry and returns rows. At 50 minutes the service fetches a new token before the old one dies.

The branch that matters is the 401: the token is expired or revoked. The service requests one new token; if that succeeds, it was expiry. If the authorisation server refuses, the customer has disabled the client — their way of turning the pilot off — and the service stops and pages its owner. It does not retry in a loop: a loop against a revoked client is noise in the customer's audit log and a sign you did not understand whose switch it is. The authentication and authorisation lesson covers the general shapes; what a deployment adds is that the customer, not you, owns the off switch, and the service honours it in one request.

Your access and the service's access are two different things

In the worked pilot, the first four days after the view arrived ran under the engineer's own SSO session, because that was the credential on the laptop. At 02:00 on Thursday the session expired and the queue stopped until 09:30. The audit log for those days showed one named person reading 1,200 claims a day — the first item on the security review's agenda.

You authenticate through the customer's SSO as yourself. Your account sits in a named group with an end date — the pilot's end plus two weeks — and can read the prompt log and the pilot's output table. It has no grant on the base claims tables, because debugging a prompt does not need them. When you genuinely need a raw row, the customer's DBA pulls it with you watching, and that is written down.

The service authenticates as itself. Its credential outlives your badge; it keeps running the week after you leave, which is the point of the handover; and one switch revokes it when the customer decides the pilot is over. Two principals, two audit trails, and a questionnaire answer that does not begin with "well, during the first week…".

Two principals, two paths. The service reads four views and writes only to the pilot's own tables; you read what it wrote. The one arrow leaving the box carries a redacted prompt and nothing else.

Least privilege is a list, not a principle

"Least privilege" on a slide is a principle. In a deployment it is a one-page document the customer keeps — attached to the security review, in their ticketing system, owned by a named person on their side. For the worked pilot:

Principal: pilot-triage-svc, workload identity in the customer's tenant; no stored secret.
Reads: SELECT on claims.fnol_v, policy.terms_v, docs.wording_v and payments.invoices_v (claim number, policy number, amount and paid date only); row filter on the claims view line_of_business IN ('motor', 'property', 'commercial') AND reported_at >= '2026-09-01'. No structured personal columns are in the views; the free-text loss description is, and the service redacts it before it reaches a prompt.
Writes: INSERT on pilot.triage_output, pilot.prompt_log and pilot.token_map, the redaction's mapping. Nothing else.
Outbound: the hosted model endpoint, one project-scoped API key in the tenant's secret manager, readable by the service identity only. What crosses: the redacted loss description and the policy wording. Nothing else leaves.
Retention: prompt log 30 days, in the tenant, under the customer's encryption at rest.
Revocation: disable the principal. Tested on the first live day: the poll failed within 60 seconds, the queue stopped, the log line is attached.
Owner at the customer: the IAM lead, by name. Review: at handover, then every 90 days.

The DBA, who is helpful and busy, will offer the existing reporting account instead, because it exists today: SELECT on 80 tables, including the base claims tables with names and bank details. Decline it for the daily feed, with the reason the questionnaire will ask: a leaked key exposes 80 tables, and the answer to "which personal data does the service read" becomes "all of it". If the schedule cannot wait two weeks for the scoped role, one supervised backfill run under reporting, with the DBA present and the grant removed the same day, is defensible — and it goes on the list, dated.

In an interview

What is being tested is whether you can name the three mechanisms and pick between them by where the service runs and what sits in front of the data; whether you separate your own access from the service's without being prompted; and whether you can write the grant list because you have written one. Say it out loud: four views, SELECT only, a row filter, three tables written, one endpoint out, one switch to turn it off.

The mistake that loses points is answering "least privilege" as a principle — unable to name the tables, the operation and the row filter — because the interviewer is checking whether you have ever written the list. Behind it: running the pilot under your own SSO because it was convenient, which fails at 02:00 and reads as a person exfiltrating claims.

Check yourself

1. The service runs in the customer's cloud tenant and the claims database is that tenant's managed relational service. Which mechanism, and what changes if the database is on-premises with no identity provider in front of it?

Workload identity mapped to a database role: no secret to store, nothing to rotate, revoked by disabling one identity. On-premises with nothing in front of the database, it becomes a service account — a read-only role, the key in the customer's secret manager, rotated every 90 days and once at handover — and the list gains a rotation date and a named rotator.

2. The DBA can give you the reporting account on Friday or a scoped role in two weeks. The backfill and the eval labelling are waiting on the data. What do you do?

Ask for the scoped role today and take one supervised backfill run under reporting with the DBA, revoked the same day and recorded on the list. The daily feed waits for the role: the credential that runs every day is the one the questionnaire describes, and an 80-table grant is not an answer you want to defend the week before renewal.

3. A bearer token leaks from a log line at 10:00 on a peak morning. Estimate what the holder can do, and compare it with a leaked service-account key.

For the rest of its hour, at most: SELECT on everything the four views hold, which is every claim reported since the pilot start — about 6,000 for each week the pilot has run, not the 240 arriving in that hour — without the structured personal columns but with each loss description unredacted, since redaction runs in the service; and INSERT on the pilot's three tables. Disabling the client stops new tokens; the leaked one dies at its next request only if the API checks revocation, and otherwise at expiry, under an hour. A leaked service-account key runs until someone rotates it — up to 90 days — on whatever role it holds, which argues for the scoped role and the short token in the same breath.