Auth, Data Residency and Audit

The customer likes the demo. The commercial conversation goes well. Then the security questionnaire arrives — a hundred and forty rows in a spreadsheet — and the deal slows down for six weeks. The three things that spreadsheet asks about first, and that your product will either answer in one sentence or not answer at all, are authentication, residency and audit.

These are not optional. They are the floor a serious enterprise sets before anything else is even considered, and an FDE who cannot talk about them fluently is an FDE the customer's security team does not want in the room.

What the three are, and why they come in this order

The order matters. A system without authentication cannot meaningfully claim residency, because there is no boundary around whose data it is. A system without audit cannot meaningfully claim either, because the only evidence that the first two were honoured is the log of what happened.

Authentication, honestly

Two acronyms, and the honest answer is which of them you actually implement.

SSO — Single Sign-On — is the request that a user arriving at your system has already been authenticated by the customer's identity provider, over SAML or OIDC, and that the IdP has told you who they are and which groups they belong to. The customer wants this because it means they manage access from one place. Your side of it is a trust relationship with their IdP, group claims mapped to your roles, and a way to pin a session to the user the IdP named.

SCIM is the other half. SSO tells you who the person is at login. SCIM tells you who exists in the first place: a user added to a group in Okta shows up in your system without anyone sending an invite, and a user off-boarded in Okta is disabled in yours within minutes. Without SCIM the gap between leaving a company and losing access to your product is however long it takes a human to remember to remove them, which is the specific hole a security review is written to close.

A third row that comes up quickly: role mapping. The customer's "Billing Admins" group in their IdP should map to your "Billing Admin" role, and the mapping should be configurable by them, not by you. Hand-mapping groups in support tickets is the way SSO implementations quietly become unmaintainable.

Residency as a deployment constraint

The sentence that trips teams up most often is "our data cannot leave the EU." It is almost always interpreted as a configuration change and almost always needs a deployment change.

To meet the requirement honestly, three things have to be true. The storage has to live in an EU region and never replicate out of it, which is a decision made at the database and object-store level. The endpoints the user talks to have to be served from the EU, which is a routing and domain decision at the edge. And the model call itself has to go to a provider endpoint that lives in the EU — a model that is only available in us-east-1 fails the requirement no matter which region your API gateway lived in, because the moment you forward the request you have shipped the data across the border.

Model availability by region is the piece FDEs most often miss, and the one that most often turns into a schedule slip. Not every frontier model is served from every region. A customer who insists on EU residency and a specific model may be asking for two things that cannot both be true today, and finding this out in month five of a rollout is a different conversation from finding it out in week one.

The second common variant is "our data cannot touch a US company's infrastructure," which is a different question with a different answer and is worth hearing precisely before you respond to it.

What an audit log is actually for

An audit log is written for a person reading it after something has gone wrong. Design it for that reader.

The lines that reader needs are not "a request was made." They are the prompt that was sent, the tools that were called with the arguments they were called with, the data returned by each tool, the model and the specific version that produced the response, and the final answer or action the agent took. With those five, the incident can be reproduced. Drop any one of them and you are guessing at 2am.

Two properties matter beyond the content:

Immutability. The log has to be write-once from the system that is being audited. If the service that answers requests can also edit the log of the request afterwards, the log is evidence of nothing. In practice this means appending to a store the service cannot delete from — a separate account, a log pipeline, an object lock.

Retention. The customer's regulator and legal team will tell you how long, and the honest answer is almost never "forever" and almost never "thirty days." Pick the number with them, document it, and enforce it automatically.

PII inside the log is the subtle failure. A log that captures the prompt in full will capture the user's name, the account number they pasted in, the customer's customer. Redact at the point of writing the log, not during a quarterly compliance review.

Three places PII gets redacted, not one

PII handling is where "we have a privacy policy" and "we have a privacy implementation" come apart. The implementation needs redaction in three places, not one:

1. At ingestion, when PII enters the system. The retrieval index does not need the customer's social security number, so do not put it there.
2. Before the prompt, when assembling the model input. The model does not need the PII to answer most questions, and a tool-call plan can usually be produced from a pseudonymised version.
3. Before the log, when writing the audit trail. The log needs to prove what happened. It does not need to be a second copy of the data.

The cheapest redaction is the earliest one. The one that catches the most mistakes is the latest one. A mature system does all three.

What to take away

Authentication is SSO plus SCIM, named apart because supporting one does not imply the other, with group claims mapped to roles the customer controls. Residency is a deployment shape — storage pinned, endpoints served, model calls landing in the right region — not a configuration flag, and model availability by region is the constraint most often missed. An audit log is written for an incident reviewer and has to carry the prompt, the tool calls, the data returned, the model version and the decision the agent took, written somewhere it cannot be edited and read after a retention window agreed with the customer. PII is redacted at ingestion, before the prompt, and before the log, because each one catches something the others don't.

Next: the three deployment shapes those constraints end up fitting into — hosted, VPC and on-prem — and the question an FDE should ask before promising any of them.