Chapter 17: AI in policy practice

Introduction

The introduction explains why AI can help people work with authorization policies but should not make the final access decision.

• AI and authorization boundaries: Explain why AI should not be the authorization decision-maker, even when an AI system handles sensitive data or acts on someone’s behalf.
  Why it matters: Keeping AI out of the final access decision preserves the properties authorization is meant to provide.
• AI assistance with policy work: Describe the policy work AI can assist with and the difficulties at ACME that made such assistance useful, without treating AI’s output as authoritative.
  Why it matters: AI can make challenging policy work easier to examine while people and the authorization system retain responsibility for decisions.

Key terms: authorization, access determination, determinism, explainability, auditability, predictable failure modes, policy-based authorization, policy engines, policy changes, hypothetical access situations

17.1 AI is not your policy engine

This section explains why AI must not make authorization decisions and how ACME keeps policy evaluation in charge while using AI within authorized boundaries.

• Limits of prompt-based authorization: Explain why placing access rules in an AI prompt does not make the AI a trustworthy enforcement mechanism.
  Why it matters: A convincing answer from an AI system is not a reliable access-control decision.
• Authoritative decisions and explanations: Distinguish the policy engine’s authoritative evaluation and explanation from an AI system’s interpretation of policy.
  Why it matters: Reviews and audits need the rules that actually produced a decision, not an interpretation that merely sounds correct.
• Authorization before AI access: Describe ACME’s boundary between authorization and AI, including what information the AI may receive and what assistance it may provide.
  Why it matters: AI can be useful with protected information without becoming the authority that grants access to it.

Key terms: nondeterministic outcomes, deterministic evaluation, enforcement, policy engine, policy evaluation trace, authoritative explanations, policies as code and data, authorization decision loop, authorized context, principal

17.2 Policy authoring and analysis with AI

This section explains why AI can help ACME author and analyze policies while leaving authorization decisions to the policy engine.

• AI’s design-time role: Describe how ACME uses AI to assist policy authoring and analysis without giving it authority over access decisions. Give examples of the help it can provide.
  Why it matters: This distinction lets teams use AI’s assistance without relying on it to make access decisions.
• Difficulty of precise policies: Explain why translating organizational intent into executable authorization policy can be difficult, particularly as policies grow and interact.
  Why it matters: These difficulties explain why authoring and analysis are valuable places for AI assistance.

Key terms: design-time tasks, enforcement path, policy engine, candidate policies, organizational intent, executable policy, policy sets

17.2.1 Explaining existing behavior

The section shows how AI can explain a specific authorization outcome while emphasizing that engineers must verify its explanation against the actual policy evaluation trace.

• AI explanations of access outcomes: Explain how AI can account for a specific authorization outcome using the Cedar schema, relevant policies, and entity relationships. Describe how that explanation helps people check whether the outcome matches the intended design.
  Why it matters: A concrete explanation gives engineers and policy owners a way to investigate whether an access decision reflects their intent.
• Verification of AI explanations: Describe why engineers did not treat AI explanations as authoritative and what they did when an explanation was vague or surprising.
  Why it matters: Checking the trace keeps a plausible AI explanation from replacing evidence of what the policy actually did.

Key terms: Cedar schema, permit policy, entity relationships, reader relationship, policy evaluation trace, authoritative, poorly expressed policies

17.2.2 Exploring alternative expressions of intent

This section shows how AI can surface different policy changes for the same requested outcome while leaving the design choice to a human.

• Alternative policy expressions: Describe the three policy changes AI might suggest to deny Kate access to one document without affecting other customers, and explain how their design tradeoffs differ.
  Why it matters: Getting the immediate access decision right does not make every policy expression equally easy to maintain.
• Human choice among suggestions: Explain what AI contributes to exploring a policy change and why an engineer must still choose among its suggestions.
  Why it matters: AI can broaden the engineer's options without taking responsibility for the policy design decision.

Key terms: forbid policy, permit policy, unless clause, authorization intent, human judgment, clarity, maintainability, intent, style

17.2.3 Using concrete requests to ground analysis

This subsection shows how specific authorization requests make AI-assisted policy analysis easier to check against the actual system.

• Concrete requests for policy analysis: Explain why ACME grounds AI-assisted policy analysis in specific requests and expected results, and how reviewers can spot an answer that strays from the actual model.
  Why it matters: A concrete request gives you a way to check an AI explanation against the system you actually have.

Key terms: AI-assisted policy analysis, specific requests, expected results, schema

17.2.4 Human judgment remains central

This section explains how ACME uses AI to improve policy work and log analysis while leaving policy acceptance and authoritative access findings to humans and deterministic systems.

• Human authority over policy: Explain why ACME treats AI suggestions as advisory and leaves policy acceptance to a human author. Describe why AI stays in the design-time workflow rather than the enforcement path.
  Why it matters: AI can help engineers work faster without taking responsibility for access decisions away from people and the authorization system.
• Authoritative log analysis boundaries: Distinguish the deterministic evidence used to establish what happened in an access event from AI’s role in helping analysts examine it. Use the support-engineer example to illustrate the division.
  Why it matters: Analysts can benefit from AI summaries without making an unreliable summary the evidence for an access finding.

Key terms: advisory, human author, organizational intent, design-time workflow, enforcement path, PDP decision log, policy version, policy replay tool, deterministic rule, triage

17.3 What AI can tell you about your authorization policies

This section contrasts policy intent with runtime authorization outcomes and explains how AI can help compare them.

• Policy intent and runtime reality: Explain why a written authorization policy may not reveal its actual effects, and describe how AI’s role differs between drafting a policy and analyzing its runtime outcomes.
  Why it matters: Comparing intended rules with real decisions can reveal effects that were not apparent when the policies were written.

Key terms: design-time intent, runtime reality, decision logs, AI-assisted analysis

17.3.1 Seeing what policies really do

This section shows how AI-assisted analysis of decision logs reveals what deployed authorization policies actually do, which may differ from their owners’ intent.

• Observed Policy Behavior: Explain how teams use AI to summarize and analyze decision logs instead of relying only on what policy owners intended. Describe how this can reveal unexpectedly broad or blocked access.
  Why it matters: Checking observed decisions can expose access problems that a policy’s stated intent does not reveal.

Key terms: decision logs, observed decisions, inferred intent, overlapping policies

17.3.2 Identifying gaps and edge cases

This section shows how AI-assisted analysis can surface surprising authorization decisions and help teams use runtime behavior to revisit policy intent.

• Surprising authorization edge cases: Explain how AI-assisted analysis can reveal rare permits or unexpected denials, including decisions that are technically correct but operationally surprising.
  Why it matters: A valid policy decision can still expose an access rule worth reconsidering.
• Runtime findings shape policy design: Describe how ACME used edge cases found in runtime decisions to revisit policies, documentation, and tests.
  Why it matters: Checking real decisions against intended access keeps policy design grounded in actual behavior.

Key terms: AI-assisted analysis, edge cases, outliers, rare permits, unexpected denials, runtime analysis, design-time decisions, intent, behavior

17.3.3 Asking better questions

This section shows how teams can use AI and runtime data to ask broader questions about what their authorization policies do in practice.

• Broader policy behavior questions: Explain how teams move beyond checking whether one request is permitted to asking broader questions about policy behavior, and why answering those questions calls for runtime data and AI-assisted analysis.
  Why it matters: Looking at decisions in aggregate can reveal patterns that individual access checks or policy text may not show.

Key terms: policy behavior, runtime data, effective audience, exceptions

17.3.4 From observation to accountability

This section shows how ACME uses evidence of runtime authorization decisions and AI-assisted explanation to make those decisions accountable without letting AI make them.

• Evidence for challenged decisions: Describe the evidence ACME could present when an access decision was challenged: the policies in effect, the data used in evaluation, and the decision made. Explain how AI-assisted analysis helped make that evidence understandable, including to non-technical stakeholders.
  Why it matters: A challenged access decision can be defended with evidence rather than a general claim about what a policy was meant to do.
• Policy engine and AI roles: Distinguish the policy engine’s role in making authorization decisions from AI’s role in analyzing and explaining them afterward. Explain why that separation preserved determinism and auditability while helping ACME compare design-time intent with runtime reality.
  Why it matters: Separating decisions from AI-assisted explanation lets ACME improve understanding without giving up auditable authorization.

Key terms: runtime behavior, policies in effect, data used during evaluation, AI-assisted analysis, accountability, policy engine, policy and data, determinism, auditability, design-time intent

17.4 Authorization before retrieval: Making RAG safe by construction

This section explains why a RAG system must authorize data before retrieval so unauthorized information never enters the language model’s context.

• Retrieval as the exposure point: Explain how RAG uses retrieved enterprise data to ground a language model’s response and why unconstrained retrieval can expose unauthorized data to the model.
  Why it matters: The point where data enters the model is also the point where exposure must be prevented.
• Authorization before RAG retrieval: Justify why the policy engine must determine what a RAG system may retrieve before any data reaches the language model, rather than relying on the model or its prompt to make that decision.
  Why it matters: Keeping unauthorized data out of the model’s context is more reliable than asking the model not to use it.

Key terms: RAG, retrieval, model’s context, policy engine, authorization before retrieval, safe by construction

17.4.1 A quick review of how RAG works

Reviews how RAG retrieves and adds domain-specific material to a language model’s prompt, then identifies retrieval as the point where authorization must be enforced.

• RAG retrieval and response flow: Trace how RAG turns content and a user query into retrieved context for a language model’s response.
  Why it matters: The retrieval flow shows how outside information reaches the model’s response.
• Authorization at RAG retrieval: Explain why authorization must be enforced when the RAG application selects information to retrieve and present to the AI.
  Why it matters: Checking what the application retrieves controls which material can become context for an answer.

Key terms: RAG, chunks, vector embedding, vector database, query embedding, prompt, system-selected context, user-provided context, authorization, retrieval

17.4.2 Retrieval is the enforcement boundary

This subsection explains why a RAG system must authorize access before retrieval rather than rely on the model or its final response to protect data.

• Retrieval as enforcement boundary: Explain why authorization must happen before a RAG system retrieves documents: retrieved material enters the model’s working context and can influence what it says or infers.
  Why it matters: Keeping unauthorized documents out of retrieval prevents the model from using them at all.
• Limits of model-based enforcement: Describe why prompt instructions and edits to generated responses cannot reliably enforce access control when unauthorized documents have already been retrieved.
  Why it matters: A response that looks safe does not prove the model was unaffected by unauthorized material.

Key terms: retrieval, working context, access control, authorization before retrieval, prompt, response, context window, policy, accountability

17.4.3 From architectural principle to concrete flow

This section shows two ways to authorize RAG retrieval before protected content is fetched, so the LLM receives only policy-approved context.

• Policy residual retrieval flow: Trace how ACME turns a structured authorization request into a retrieval filter. Explain that Cedar’s typed partial evaluation leaves some inputs unspecified and returns a policy residual describing the conditions under which access would be allowed, rather than a binary decision.
  Why it matters: Policy constraints can shape what retrieval returns, instead of relying on the LLM to reject unauthorized material.
• Candidate-first batch authorization: Describe the alternative two-stage design: search for a bounded set of candidate identifiers and relevance scores, authorize those candidates in a batch, then retrieve content only for permitted resources. Explain why the initial search must not return protected document content.
  Why it matters: The alternative preserves the authorization boundary even when policy cannot conveniently become a database filter.
• Authorized context for generation: Explain how permitted retrieval results become additional context in the prompt sent to the LLM, and why applying the same policy logic to retrieval keeps unauthorized data out of the model’s context window.
  Why it matters: The model can work with sensitive enterprise data without being made responsible for enforcing access control.

Key terms: typed partial evaluation, policy residual, query filter, chunk metadata, candidate resource identifiers, relevance scores, batch request, two-stage design, authorized additional context, prompt constructor

17.4.4 Safe by construction, not safe by instruction

The section explains why enforcing authorization before retrieval makes ACME’s RAG systems safer and more accountable than relying on prompts to control access.

• Structural access boundaries: Explain why ACME enforces access boundaries in the retrieval path rather than relying on prompts or model behavior.
  Why it matters: The access boundary holds before the model has data to work with, rather than depending on how the model follows instructions.
• Policy-based accountability: Explain how authorization before retrieval made ACME’s AI access easier to govern and account for.
  Why it matters: A policy-defined scope gives people a clear basis for reviewing what the AI was permitted to access.

Key terms: authorization before retrieval, retrieval path, safe by construction, prompts, policy, authorized scope, governance

17.5 From architecture to accountability

The section shows how decision logs, AI-assisted analysis, and human governance turn authorization outcomes into evidence that can improve policies over time.

• Decision logs as evidence: Explain what decision logs reveal about authorization outcomes and how AI helps people examine that evidence without judging whether the outcomes are acceptable.
  Why it matters: Evidence from actual decisions makes complex policy behavior easier to inspect than policies alone.
• Traceable policy responsibility: Trace how an authorization decision can be connected to a policy, its owner, and the business intent recorded during review.
  Why it matters: Tracing an outcome to its owner tells governance teams whom and what to review.
• Runtime governance feedback loop: Trace how observed authorization outcomes lead through human governance judgment to a revised policy that is tested, deployed, and observed again.
  Why it matters: The loop turns observed problems into reviewed policy changes rather than leaving them as unexplained log entries.
• Boundaries for reliable accountability: Justify why AI's assistive role, authorization before retrieval, and consistent policy-decision logging are necessary for a reliable evidence trail.
  Why it matters: Governance can improve policies only when policy decisions genuinely control access and leave a trustworthy record.

Key terms: decision logs, authorization behavior, AI support, policy-based authorization, policy owner, business intent, accountability, runtime evidence, governance, design-time cycle

17.6 Policy as practice

This section presents policy as an ongoing authorization practice in which AI helps people interpret evidence and improve policies without taking over enforcement or governance.

• Policy as ongoing practice: Describe how policy expresses intent, is evaluated at runtime, is observed through decision logs, and is questioned and revised rather than treated as a static artifact.
  Why it matters: A policy remains useful when its real-world behavior can be observed and improved.
• AI assistance and enforcement boundary: Distinguish AI's assistance with policy work from the authority to make authorization decisions, and state where authorization stands relative to retrieval.
  Why it matters: AI can be helpful without becoming the source of access decisions or seeing unauthorized material.
• Evidence and accountable change: Explain how decision logs, AI, and human governance play different parts in improving policy at ACME.
  Why it matters: Understanding evidence is useful only if accountable people decide what should change.

Key terms: policy, decision logs, governance, operational discipline, AI, policy engine, deterministic evaluation, data, context, evidence

17.7 Summary