Chapter 12 — Access Control and Identity

Twelfth post of the chapter-by-chapter walkthrough of LLM Primer VII: AI Security. The chapter that answers the compositional question — who is allowed to invoke which capability of an LLM-integrated application, and how the enforcement is structured across the system's components.

Why this chapter exists

The traditional access-control disciplines all apply to LLM systems: authenticate the principal, authorise their requests against policy, isolate tenants, bound consumption per principal, expose enterprise governance overlays. The mechanisms are the ones the field has used for decades — OAuth 2.0, mTLS, RBAC, ABAC, token buckets, SAML, SCIM. What is new is that the model call itself can become a principal — an agent acting on behalf of a user carries its own identity and its own permissions — and that per-tenant configuration of model behaviour is a first-class product feature for multi-tenant LLM platforms.

One line: Access control in LLM systems is the traditional discipline plus one addition — the model, when it acts through tools, is itself a principal whose permissions must be scoped narrowly enough that a compromised prompt cannot cash them.

12.1 Authentication and authorisation transfer, with additions

Authentication verifies the credential. API keys are the simplest mechanism — a high-entropy string handed to the principal at provisioning, hashed in the credential database, presented in a header on every request. They are easy to implement and use, and easy to leak through logs, CI output, and committed repositories. OAuth 2.0 bearer tokens improve the situation with short-lived tokens and scope restriction; the OAuth 2.1 draft consolidates the security best practices of the past decade. mTLS adds mutual authentication for machine-to-machine calls, particularly useful for internal LLM services. Authorisation asks what the authenticated principal is allowed to do. RBAC — roles, permissions, assignments — works when the population divides into stable groups. ABAC — attribute-based access control — evaluates predicates over principal, resource, and context attributes and handles the cases RBAC does not: permissions that depend on the resource's owner, the request's time or location, or relationships in the system. The two are not mutually exclusive; production systems often layer them, with RBAC for coarse-grained access and ABAC for the specific conditions. Policy engines from Chapter 10 — OPA, Cedar — are how ABAC becomes maintainable at scale.

12.2 Multi-tenant isolation is a defence in depth question

A multi-tenant system serves multiple customers from a single deployment. The isolation requirement is that no tenant can see any other tenant's data, requests, or model interactions under any failure mode. Three architectural approaches sit on a spectrum. Database-level isolation — separate database per tenant — is the strongest but the most expensive to operate. Schema-level isolation — separate PostgreSQL schema or MySQL database per tenant on shared infrastructure — is a middle ground. Row-level isolation — shared schema, tenant ID on every row, database-enforced row-level security — is the cheapest but requires disciplined application code. For LLM systems the isolation extends to the retrieval corpus (per-tenant vector database namespaces), the prompt-construction logic (no cross-tenant concatenation), the log store (no cross-tenant reads), and the model itself when fine-tuned on tenant-specific data. Rate limits and quotas add the resource-consumption axis. Token bucket allows short bursts up to a defined capacity; sliding window enforces a more uniform rate at higher computational cost; leaky bucket smooths downstream rate. For LLM systems the rate limit dimension expands: requests per second, tokens per minute, cost per day, tool invocations per hour, embeddings per second. Each dimension has its own economic and security justification, and enterprise tiers typically discriminate along several.

12.3 Enterprise governance is the overlay that makes the system usable

Enterprise customers have governance requirements beyond authentication and rate limiting. They need to know which employees use the system, on what data, for what purposes. They need audit logs sufficient for internal compliance and external audit. They need controls over which models are allowed, which tools are available, which content categories are permitted. They need data-handling commitments — training use, encryption, residency, retention, deletion. The features that have become standard reflect these requirements. Single sign-on via SAML or OpenID Connect makes the enterprise identity provider the source of truth for who can use the system. SCIM provisioning propagates user changes automatically. Audit log export sends the LLM system's telemetry into the enterprise SIEM. Data residency commitments guarantee that a tenant's data does not leave a specified jurisdiction. Customer-managed encryption keys allow the enterprise to rotate or revoke independently of the provider. Private deployment options move the LLM service into the enterprise's own cloud account. Each of these features is a governance surface that has to be operated, not just implemented; the enterprise governance overlay is what turns a multi-tenant LLM platform into something a regulated industry can adopt.

Worth holding onto: Every tool the model can invoke should be authorised as if the user had invoked it directly — with the caller's identity, in the caller's tenant, subject to the caller's rate limits. Anything else grants the model authority beyond the principal it acts for, which is the failure mode most agent architectures accidentally build in.

What Chapter 12 sets up

Part IV has developed the system-level dimensions of LLM security: architectural boundaries (Chapter 10), observability and incident response (Chapter 11), and identity and access controls (Chapter 12). The treatment has been mechanism-first, and it gives a defensible technical posture. Chapter 13 opens Part V by moving outward from the technical core to the regulatory perimeter. The EU AI Act, in full effect from August 2026 for most high-risk categories, is the most consequential single instrument, but the US federal posture (evolving after the EO 14110 to EO 14179 transition), the state-level laws (Colorado, California, New York City, and others), the GDPR as it applies to AI, and the emerging frameworks in Singapore, Japan, Korea, India, and elsewhere collectively make the compliance surface plural rather than unified. The chapter examines what these regulations require in practical terms and how the controls from Chapters 3, 10, 11, and 12 map to those requirements.

Next — Chapter 13: Regulatory Landscape. The EU AI Act's phased applicability, GDPR against AI systems, auditability, model cards, and the risk-classification frameworks that structure the regulatory architecture.

Want the full picture? The book chapter includes worked OAuth and mTLS setups, the full RBAC-vs-ABAC decision matrix with production examples, tenant-isolation patterns across storage layers, and the In Plain English sidebars this article only summarises. View LLM Primer VII on Amazon →