Security & Governance
Access control, PII handling in LLM-backed systems, audit trails, and the approval workflows automated gates can't replace
Security & Governance
TL;DR
Access control decides who can deploy, query, and promote; PII handling decides what personal data reaches a model (especially a third-party LLM provider) and how it's protected; audit trails make both answerable after the fact. Some changes need a human sign-off beyond what an automated CI/CD gate checks — designing that approval step deliberately, before deadline pressure forces a shortcut, is what governance actually means in practice.
| Property | Value |
|---|---|
| Level | Intermediate |
| Reading time | ~17 minutes |
| Prerequisites | Feature Stores & Data Pipelines |
| You will understand | How to control who can do what, protect personal data, and know what happened after the fact |
Access Control, Concretely
Three distinct access questions
Who can promote a model to Production?
RecommendedTied to the registry's stage-transition permissions — promotion should require a specific role, not just "anyone with registry write access," since a Production promotion is the action that actually changes what real traffic sees.
Who can query which data?
Data access should be scoped to what a role actually needs — a monitoring dashboard needs aggregate metrics, not raw customer records; a debugging session needs a specific incident's data, not open query access to the whole warehouse.
How do services authenticate to each other?
Internal ML APIs (a feature store, a model-serving endpoint, a gateway) need service-to-service auth — a static shared secret is a common starting point but doesn't scale past a handful of services; short-lived tokens or mTLS are the standard answer at real scale.
"Anyone on the team can deploy" is a convenience that becomes a liability the moment something goes wrong and nobody can say who changed what. This isn't about distrust — it's that access control and audit trails are what make an incident answerable at all, rather than a guessing game.
PII in LLM-Backed Systems Specifically
Traditional feature-based ML mostly contains PII to structured fields — a customer_email column is easy to identify, mask, or exclude. LLM-backed systems are messier: personal information can appear anywhere in free text — a support ticket, a chat message, a document being summarized — and it flows directly into a prompt, often sent to a third-party provider.
# What actually needs scrubbing before this reaches a third-party model call:
prompt = f"Summarize this support ticket: {ticket.raw_text}"
# ticket.raw_text might contain a name, an email, a card number fragment,
# an address — none of it in a predictable field, all of it now leaving your systemA structured-data PII policy doesn't automatically cover free text sent to an LLM. "We don't send PII to third parties" needs to mean scanning and redacting prompt content, not just excluding known-sensitive database columns — the two are different problems with different tooling (regex/NER-based redaction for free text vs. column-level access control for structured data).
| Strategy | What it does |
|---|---|
| Redaction before the call | Detect and replace PII patterns (emails, phone numbers, names via NER) before the prompt leaves your system |
| Provider selection | Route requests containing sensitive content to a provider with a contractual data-handling agreement, or to a self-hosted model, rather than a general-purpose API |
| Retention policy | Confirm and configure whether the provider retains prompts/responses, and for how long — this varies by provider and by plan |
Audit Trails
An audit trail answers, after the fact: who did what, when, and what did it replace or affect.
2026-09-10 14:32 alice promoted my-classifier v12 → Production (replaced v11)
2026-09-10 14:35 bob queried customer_features table (incident #4821 debugging)
2026-09-11 09:10 carol updated routing-rule: gpt-tier → claude-tier for task=summarizationThe registry's stage-transition history (covered in Model Registry & Versioning) is part of a full audit trail, not the whole thing. A complete trail also covers data access and configuration changes — like a routing rule update — that don't touch the model registry at all but still materially affect production behavior.
Governance: What Automated Gates Don't Cover
CI/CD validation gates check whether a model clears a quality bar. They don't — and shouldn't be expected to — capture every reason a change might warrant extra scrutiny.
A concrete governance scenario
A model used to score loan applications or screen resumes passes every automated validation gate — accuracy is up, no regression on the held-out set. Should it auto-deploy?
No — not on quality metrics alone. A model affecting a regulated or high-stakes decision needs human sign-off that checks things an automated gate structurally can't: fairness across protected groups, compliance with sector-specific regulation, and whether the training data itself introduced a bias the accuracy number wouldn't reveal. Passing the automated gate is necessary, not sufficient.
A governance-aware promotion workflow
Automated validation gate
Accuracy, regression checks — same as any deploy
Governance flag check
Does this model/change fall into a category requiring sign-off? (new model family, regulated use case, PII-handling change)
Human review, if flagged
A designated reviewer checks what the automated gate can't — fairness, compliance, business risk
Promotion
Only after both the automated gate and, where required, human sign-off
Concept Checks
Check yourself
Why doesn't a structured-data PII policy (excluding known-sensitive database columns) automatically protect an LLM-backed system?
Because LLM-backed systems send free text — support tickets, chat messages, documents — directly into prompts, and personal information in free text isn't confined to a predictable field the way a customer_email column is. A policy built around excluding known columns misses PII embedded anywhere in unstructured text, which needs separate detection and redaction tooling.
Why isn't passing every automated CI/CD validation gate sufficient justification to auto-deploy a model used in a regulated context like lending or hiring?
Because automated gates check quality metrics like accuracy and regression against a held-out set, which can't capture fairness across protected groups, regulatory compliance, or bias introduced by the training data itself. A model can clear every automated check while still carrying risks that only a human reviewer, checking for things the gate wasn't built to measure, would catch.
Why does a full audit trail need to cover more than just the model registry's stage-transition history?
Because production behavior can change through actions that never touch the model registry at all — like a routing rule update or a data access query — and those changes need to be just as answerable after the fact as a model promotion. Limiting the audit trail to registry events would leave a real gap in what "who did what, when" actually covers.
Key Concepts Recap
| Concept | One-line summary |
|---|---|
| Access control, concretely | Who promotes models, who queries which data, how services authenticate to each other |
| PII in free text | LLM prompts carry personal data outside predictable structured fields — needs its own redaction strategy |
| Provider data handling | Confirm retention policy and choose providers/self-hosting based on sensitivity |
| Audit trail | Covers data access and config changes too, not just model registry events |
| Automated gates check quality | Not fairness, compliance, or business risk — those need human sign-off |
| Governance workflow | Flag high-stakes changes for review, beyond the automated validation gate |
Next
With access, data protection, and approval workflows covered, the next page catalogs what goes wrong across the whole MLOps stack and how to trace it back: Failure Modes & Debugging.
Feature Stores & Data Pipelines
Training-serving skew explained in full, and the online/offline feature store architecture that exists specifically to prevent it
Failure Modes & Debugging
The MLOps-stack bugs that show up again and again — shallow health checks, silent drift, skew, loose gates — and the fix for each