From Architecture to Accountability: How AI Helps Policy Become Practice

Phil Windley // Thu Jan 22 10:09:00 2026 // identity authz authorization llm ai governance

Over the last several posts, I've been focused on how AI fits into policy practice as a tool for understanding, shaping, and inspecting authorization behavior. The common thread across all of them is a simple but demanding idea: authorization only works if it can be understood, defended, and enforced over time. Architecture matters, but architecture alone is not enough.

I started by arguing that AI is not—and should not be—your policy engine. Authorization must remain deterministic, explicit, and external to language models. From there, I showed how AI useful in practice: helping humans author policies, analyze their effects, and explaining what policies actually allow. Most recently, I made that separation concrete by showing how authorization can shape the retrieval of data in RAG systems, filtering what data a model is allowed to see before a prompt ever exists.

What all of these threads point to is governance. Not governance as paperwork or process, but governance as the discipline that connects intent to impact. Authoring, analysis, review, and enforcement are all necessary, but without governance, they remain isolated activities. Governance is what turns them into a coherent practice with memory, accountability, and consequence.

This post focuses on that layer. It's about how teams ensure that authorization decisions remain intentional as systems evolve, policies change, and new uses emerge. It's where policy stops being something you write and becomes something you can stand behind. In that sense, governance isn't an add-on to authorization. It's what makes authorization real.

Governance Connects Intent to Impact

Governance starts with a simple reality: intent lives with people, but execution happens in systems.

In access coontrol systems, intent comes from many places. Product teams decide what customers should be able to do. Security teams decide where risk is acceptable. Legal and compliance teams decide which access patterns require justification or oversight. All of that intent must eventually be translated into policy. But simply writing policies is not enough to ensure intent remains visible, enforceable, and defensible as systems evolve.

Impact is what happens when those policies are evaluated at runtime. It shows up as effective access: who can see which data, perform which actions, and under what conditions. That impact is what users experience, what auditors inspect, and what regulators care about. Governance exists to ensure that the impact of authorization decisions continues to reflect the intent that motivated them.

This is where architecture alone falls short. You can have a clean policy model, a well-designed PDP and PEP, and a formally correct implementation—and still lose alignment over time. Policies accrete exceptions. Data models evolve. New use cases appear. What once reflected clear intent slowly drifts into something no one can fully explain or confidently defend.

Governance is the discipline that prevents that drift. It connects intent to impact not just at design time, but continuously. It answers questions like: Is this access still what we meant to allow? Can we explain why it exists? Would we accept the consequences if it were challenged? Without governance, authorization becomes a historical artifact. With it, authorization remains a living commitment.

Effective Access Is How Impact Is Measured

Proper governance ensures that impact continues to follow intent. To do that, impact must be measurable.

In access control systems, that measurement is effective access. Policies express intent, but effective access shows what actually happens: who can perform which actions on which resources, under real conditions. This is the concrete, observable outcome that governance can inspect, question, and defend.

Access control policies are often discussed in terms of rules, conditions, and relationships. Governance does not reason about those elements in isolation. It reasons about whether the resulting access aligns with what was intended. The central question is not “What does this policy say?” but “Who can actually do what, right now, and does that match our intent?”

Effective access captures the measurable expression of impact. It includes inherited permissions, delegated authority, environmental constraints, and relationship-based access. This is where the consequences of policy decisions become concrete, and where misalignment between intent and reality is most likely to surface.

A condition granting managers visibility into documents owned by their direct reports may seem reasonable when viewed in isolation. Enumerated across all documents and all reports, it becomes a broad access pattern with real organizational consequences. A forbid policy enforcing device posture may significantly narrow employee access while leaving customer access unconstrained. None of these effects come from hidden logic or undocumented behavior. They emerge from the combined evaluation of otherwise straightforward policy rules.

Governance depends on the ability to surface effective access deliberately and repeatedly. If you cannot enumerate who can view a document, share it, or act on it under specific conditions, you cannot assess whether impact follows intent. And if you cannot assess that alignment, you cannot credibly claim that your access control system reflects intent.

This is why policy analysis, audit, and enforcement ultimately converge on effective access. It is the measurement that governance relies on. Everything else, schemas, policies, prompts, and architecture, exists to make that measurement visible, explainable, and defensible over time. Much of what I described in the previous post on AI-assisted review and audit applies here. That post focused on how AI can help enumerate effective access, explain why it exists, and surface access patterns that are broader than expected. Those activities are audit. They make impact visible. Governance is what happens next. Governance uses the results of audit to decide whether that impact is intentional, acceptable, and properly documented, and to ensure that alignment between intent and impact is maintained over time.

AI as a Governance Support Tool

Governance depends on having a durable way to state intent and then check whether reality still matches it.

Architectural Decision Records (ADRs) provide that anchor. An ADR captures an explicit decision about access. It records what was intended, why it was intended, and which trade-offs were accepted. In governance terms, ADRs are not just documentation. They are the reference point against which impact is evaluated.

This changes how inspection fits into governance. Audit does not exist to discover intent after the fact. It exists to test whether effective access still aligns with intent that was already recorded. Inspection becomes a comparison exercise. What does the system allow today, and does that match what we said we were willing to allow?

AI can support this workflow in several ways. It can help draft ADRs at the moment decisions are made, using standard templates to capture intent in clear, reviewable language. Later, it can assist with inspection by enumerating effective access and summarizing how that access aligns with, or deviates from, the intent described in the ADR. The result is not just a list of permissions, but a structured comparison between intent and impact.

This also strengthens governance over time. As policies evolve, AI can help surface cases where current effective access no longer matches previously recorded decisions. An ADR that once justified an access pattern may no longer apply as data models change, new principals are introduced, or additional policies are layered on. Detecting that drift is a governance responsibility, and AI lowers the cost of doing it continuously.

Used this way, AI is not a policy author, an auditor, or a decision-maker. It is a governance assistant. It helps organizations state intent clearly, inspect reality consistently, and recognize when alignment has been lost. Governance still belongs to humans. AI simply makes it easier to discover any gaps between what was intended and what actually happens.

Governance Is About Legitimacy

Governance exists to answer a different question than audit. Audit asks what the system does. Governance asks whether what the system does is legitimate.

Legitimacy in access control does not come from good intentions or clean architecture. It comes from evidence that access decisions reflect declared intent and continue to do so as the organizatino and its systems evolve. An authorization model is governable only when its outcomes can be explained, justified, and shown to align with the reasons those rules exist in the first place.

This is where governance extends beyond inspection. Knowing that a manager can view all documents owned by direct reports is an audit finding. Being able to show why that access exists, who approved it, what risks were considered, and how exceptions are handled is governance.

Evidence Is What Makes Access Legitimate

In a governed system, every meaningful access pattern should be traceable back to intent and supported by artifacts that explain it. Those artifacts take many forms:

• policies that encode rules explicitly,
• architectural decision records that capture why those rules exist,
• tests that demonstrate expected and prohibited behavior,
• audit results that enumerate effective access,
• review history showing how trade-offs were evaluated and approved.

None of these artifacts is sufficient on its own. Legitimacy emerges when they form a coherent picture of intent and access.

AI does not create this evidence, but it makes coherence achievable at scale. It helps teams connect effective access to stated intent, relate policy behavior to supporting documentation, and surface gaps where access exists without clear justification. By bringing these artifacts together, AI helps answer the core governance question: does the system present a coherent picture of what was intended, what is enforced, and what actually happens?

From Audit Findings to Governed Outcomes

This is where governance distinguishes itself from perpetual audit. An audit may surface broad or surprising access. Governance ensures that those findings lead to durable outcomes.

When AI-assisted inspection identifies an access path, governance determines what happens next:

• Is the access intentional and accepted?
• Is it documented and approved?
• Is it constrained, monitored, or logged appropriately?
• Is it revisited when assumptions change?

AI can assist at each step. It can draft architectural decision records from structured prompts. It can help reconcile policy behavior with documented intent. It can summarize how effective access has changed over time. Most importantly, it can make mismatches between intent and behavior visible before they become incidents.

Governance as a Continuous Practice

Authorization systems rarely diverge from intent all at once. They evolve incrementally as teams change, requirements shift, and policies accumulate. Governance is how organizations notice that drift and correct it without losing trust.

Used well, AI becomes a force multiplier for that practice. It helps teams maintain a shared understanding of why access exists, what it allows, and how it aligns with organizational values. It makes legitimacy something that can be demonstrated continuously, not reconstructed after the fact.

Governance, in the end, is about ensuring that access reflects intent and remains legitimate as systems evolve.

From Architecture to Accountability

Across this series, my argument has been consistent even as the focus shifted. Language models are powerful, but they are not authorities. Authorization cannot live in prompts or models; it must remain deterministic, external, and enforced. At the same time, AI can play a meaningful role in policy practice, helping people author, analyze, review, and understand access control systems at a scale that would otherwise be impractical.

This final step is governance. Governance is where authorization becomes accountable over time. It is where intent is recorded, access is examined, and outcomes are justified with evidence. Architecture makes systems possible, and policies make decisions enforceable, but governance is what makes those decisions legitimate as organizations evolve.

AI does not replace human responsibility in this process. It cannot decide what access should exist or which trade-offs are acceptable. What it can do is close the gap between intent and impact. It can surface effective access, connect behavior to documented intent, and expose problems that would otherwise remain hidden.

When used this way, AI strengthens authorization rather than undermining it. It helps ensure that access is not only correct in the moment, but understandable, explainable, and justified over time. That is the difference between access control that merely functions and authorization that can be trusted.

Photo Credit: AI Assisted Policy Governance from DALL-E (public domain)

Authorization Before Retrieval: Making RAG Safe by Construction

Phil Windley // Wed Jan 7 11:52:00 2026 // authz authorization rag llm ai

In the last three posts, I've been working toward a specific architectural claim. First, I argued that AI is not—and should not be—your policy engine, and that authorization must remain deterministic and external to language models. I then showed how AI can still play a valuable role in policy authoring, analysis, and review, so long as humans remain responsible for intent and accountability. Most recently, I explored how AI can help us understand what our authorization systems actually do, surfacing access paths and assumptions that are otherwise hard to see. This post completes that arc. It takes the conceptual architecture from the first post and makes it concrete, showing how authorization can shape retrieval itself in a RAG system, ensuring that language models never see data they are not allowed to use.

Retrieval-augmented generation (RAG) has quickly become the default pattern for building useful, domain-specific AI systems. Instead of asking a language model to rely solely on its training data, an application retrieves relevant documents from a vector database and supplies them as additional context in the prompt. Done well, RAG allows you to build systems that answer questions about your own data—financial reports, customer records, engineering documents—without the expense of creating a customized model.

But RAG introduces a hard problem that is easy to gloss over: who is allowed to see what.

If you are building a specialized AI for finance, for example, you may want the model to reason over budgets, forecasts, contracts, and internal reports. That does not mean every person who can ask the system a question should implicitly gain access to every financial document you've vectorized for the RAG database. RAG makes it easy to retrieve relevant information, but does not, by itself, ensure that retrieved information is authorized.

This post explains how to do that properly by treating authorization as a first-class concern in RAG, not as a prompt-level afterthought.

A Quick Review of How RAG Works

In a basic RAG architecture:

1. Documents from the new, specialized domain are broken into chunks and vectorized.
2. Those vectors are stored in a vector database along with any relevant metadata.
3. When a user submits a query, the system first embeds it, converting the text into a numerical vector that represents its semantic meaning. It then:
   • retrieves the most relevant chunks,
   • inserts those chunks into the prompt,
   • and asks the language model to generate a response.

This pattern is widely documented and well understood (see OpenAI, AWS, and LangChain documentation for canonical descriptions). The key point is that RAG adds system-selected context to the prompt, not user-provided context. The application decides what additional information the model sees.

That is exactly where authorization must live.

The Problem: Relevance Is Not Authorization

Vector databases are excellent at answering the question "Which chunks are most similar to this query?" They are not designed to answer "Which chunks is this person allowed to see?"

A common but flawed approach is to retrieve broadly and then rely on the prompt to constrain the model, saying, essentially:

"Answer the question, but do not reveal confidential information."

This does not work. Prompts describe intent; they do not enforce authority. If sensitive data is included in the prompt, it is already too late. The model has seen it.

If you are building a finance-focused AI, this becomes dangerous quickly. A junior analyst asking an innocuous question could trigger retrieval of executive compensation data, merger documents, or board-level financials simply because they are semantically relevant. Without authorization-aware retrieval, relevance collapses access control.

Authorized RAG: Authorization Before Retrieval

The correct approach is to ensure that authorization constrains retrieval itself, not just response generation.

The diagram above shows how this works in an authorized RAG architecture. At a high level:

• The application evaluates authorization for the principal (who is asking) and the action (for example, "ask a question").
• Cedar's type-aware partial evaluation (TPE) evaluates the authorization policy with an abstract resource and produces a policy residual.
• That policy residual is a constraint over resources providing a logical expression that describes which resources may be accessed.
• The application compiles that residual into a database-native query filter.
• The vector database applies that filter during retrieval.
• Only authorized additional context is returned and included in the prompt.

The language model never decides what it is allowed to see. It only operates on context that has already been filtered by policy. This is the critical shift: authorization shapes the world the prompt is allowed to explore.

Cedar TPE and Policy Residuals

Cedar's type-aware partial evaluation is what makes this architecture practical. Instead of fully evaluating policies against a specific resource, TPE evaluates them with an abstract resource and produces a policy residual representing the remaining conditions that must be true for access to be permitted. Importantly, that residual is type-aware: it references concrete resource attributes and relationships defined in the schema.

The Cedar team has written about this capability in detail, including how residuals can be translated into database queries. While TPE is still an experimental feature, it is already sufficient to demonstrate and build this pattern.

From an authorization perspective, the residual is not a decision. It is not permit or deny. It is a constraint over resources that the application can enforce however it chooses.

Vectorization, Metadata, and Filtering

For this to work, vectorized data must carry the right metadata. Each embedded chunk should include:

• tenant or organizational identifiers,
• sensitivity or classification labels,
• relationship-based attributes (teams, owners, projects),
• anything the authorization policy may reference.

Once Cedar TPE produces a policy residual, that residual can be compiled into a filter expression over this metadata. In Amazon OpenSearch, for example, this becomes a structured filter applied alongside vector similarity search. Relevance scoring still happens but only within the authorized subset of data.

This is not heuristic filtering. It is deterministic enforcement, just expressed in database terms.

A Concrete Example (and a Working Repo)

To make this tangible, I've published a working example in this GitHub repository. The repo includes:

• a Cedar schema and policy set,
• example entities and documents,
• vector metadata aligned with policy attributes,
• and a Jupyter notebook that walks through:
• partial evaluation,
• residual inspection,
• and residual-to-query compilation.

The notebook is deliberately hands-on. You can see the policy residual produced by Cedar, inspect how it constrains resources, and observe how it becomes a vector database filter. Nothing is hidden behind abstractions. This is not production code, but it is runnable and concrete. The repository provides a working demonstration of how authorization can be used to filter enhanced context in RAG.

Why This Matters

RAG systems are powerful precisely because they blur the boundary between static models and dynamic data. That same power makes them dangerous if authorization is treated as an afterthought.

Authorized RAG restores a clear separation of responsibility by design:

• Authorization systems decide what is allowed.
• Databases enforce which data may be retrieved.
• Prompts express intent, not policy.
• Language models generate responses within boundaries they did not define.

RAG becomes defensible only when authorization reaches all the way into retrieval, translating policy into constraints that databases can enforce directly. In a well-designed RAG system, authorization doesn't shape the prompt; it shapes the world the prompt is allowed to explore.

Photo Credit: Happy computer ingesting filtered data from DALL-E (public domain)

What AI Can Tell You About Your Authorization Policies

Phil Windley // Mon Dec 29 11:59:00 2025 // ai authorization authz identity llm

In the previous post, I showed how AI can help with policy authoring and analysis by accelerating the back-and-forth between intent and implementation. That workflow is exploratory by nature. You ask why something happens, how it could change, and which formulation best expresses intent.

Review and audit are different.

In review and audit, the intent is assumed to already exist. The policies are fixed. The question is no longer how authority should be expressed, but how it is already expressed and whether that expression can be understood, defended, and justified.

This difference matters because it changes how AI should be used. In authoring, AI is invited to explore alternatives. In audit, that permission must be taken away. The AI's role shifts from collaborator to examiner: explaining behavior, enumerating scope, and surfacing consequences without proposing changes. The goal of a policy audit is not to optimize policies or propose fixes, but to understand what the current policy set allows, how broad that access is, and whether it can be defended as intentional.

Same Repository, Different Posture

What has changed is how they are treated. In authoring mode, the repository is a workspace for exploration. In audit mode, it is treated as read-only evidence. The AI is not asked how to refactor policies or how to tighten access. It is asked to explain what the current policy set actually allows, and how broad those allowances are in practice. This distinction is subtle but important. Using the same artifacts makes it clear that review and audit do not require new tools or new models, only a different posture. The difference shows up not only in the questions that are asked but also in the constraints placed on the AI through the starter prompt.

In the authoring workflow, the prompt gives the AI permission to explore. It can propose alternatives, suggest refactors, and reason about hypothetical changes. That freedom is what makes authoring productive. That same freedom would be inappropriate, even dangerous, in an audit context.

The audit prompt constrains the AI. Instead of granting capabilities, it removes them. The audit prompt explicitly instructs the AI to treat the schema, policies, and entities as authoritative and fixed. It forbids proposing policy changes, refactors, or improvements. It prohibits inventing new entities, actions, or attributes. And it reframes the AI's role as explanatory rather than creative.

What the AI is allowed to do is deliberately narrow:

• explain why specific requests are permitted or denied
• enumerate which principals can perform which actions on which resources
• identify broad or surprising access paths
• summarize access in plain language, suitable for review or audit

The prompt does not determine access or scope data. Instead, it enforces role discipline. It ensures the AI behaves like a reviewer, not a designer. That distinction is critical. In audit mode, the most valuable thing an AI can do is not suggest how to improve the system, but help humans understand what the system already does and what that implies.

With the posture and constraints established, the next step is to see what an audit actually looks like in practice. What follows is an example policy audit conducted using the same repository and a constrained audit prompt, focusing entirely on explanation, enumeration, and risk assessment.

A Concrete Policy Audit Walkthrough

With the audit posture and constraints in place, I started by asking simple, concrete questions and then gradually pushed on scope, risk, and defensibility. At no point was the AI asked to suggest changes, only to explain what the current policy set actually allows.

Establishing an Access Baseline

To get started, I asked the following question:

What can Kate actually do?

The AI began by grounding its answer in the schema and entity data. Kate is a customer, not an employee, and that immediately limits her action set. Based on the current policies, she can view the q3-plan document because she is a member of the document's customer_readers_team (acme-entities encodes that). That relationship is explicitly referenced in the customer view policy.

Just as importantly, the AI was clear about what Kate cannot do. She cannot edit or share documents, because those actions are restricted to employee principals by the schema. This initial response wasn't surprising, but that's the point. Audit starts by establishing a factual baseline before moving on to harder questions.

Expanding the View: Who Can See This Document?

Next, I widened the lens from a single principal to a single resource:

Who can view q3-plan?

This time, the AI enumerated every principal who has view access to the document and explained why each one is permitted. The list was broader than just customers. The document owner can view it. Employees on the document's employee readers team can view it. The owner's manager can view it. Customers on the customer readers team can view it as well.

The response also surfaced an important distinction. Employee access is constrained by a managed-device requirement, enforced by a forbid policy. Customer access is not. By the end of this step, there was a complete and explainable exposure map for the document without hypotheticals or changes. Just a clear picture of who can see the document and under what conditions.

Surfacing Broader-Than-Expected Access Paths

With the basic exposure established, I asked a more probing question:

Are there any ways this access could be broader than expected?

Here, the AI shifted from listing individual cases to identifying patterns. Several broad access paths emerged. Managers can view all documents owned by their direct reports, regardless of document type or sensitivity. Any employee in a readers team can share a document marked as delegatable, even if they are not the owner. Team membership grants access across all documents that reference that team. Customers are not subject to device restrictions.

None of these behaviors are accidental. They follow directly from the policies as written. But seeing them described together makes their implications much clearer. This is a nice finding to surface in an audit: access that feels reasonable in isolation can look much broader when viewed as a system.

Stress-Testing Assumptions with a Realistic Scenario

To make those implications concrete, I posed a deliberately uncomfortable scenario:

If Alice put a letter to HR citing inappropriate action by her manager in the system, would Carol be able to read it? And even edit it?

The AI answered carefully and precisely. Under the current policies, Carol—Alice's manager—can view the document because managers are allowed to view all documents owned by their direct reports. However, Carol cannot edit or share it. Those actions are restricted to document owners or, in some cases, delegated team members. This distinction matters. The policy does not give managers full control, but it does give them visibility. That may be intentional, but it has consequences.

I followed up with an even sharper question:

Is there any way with the current policy set for Alice to avoid this?

The answer was unambiguous: no. Manager access is unconditional. Alice cannot opt out of it through document attributes or team membership. This is not a bug or an edge case. but rather exactly how authority is expressed in the policy.

From Behavior to Defensibility

At this point, the conversation shifted from behavior to intent:

What evidence would an auditor need to justify this behavior as intentional?

The AI's response no longer focused on policy logic alone. Instead, it described the kinds of artifacts an auditor would expect to see: policy comments explaining the rationale, test cases explicitly validating manager access, design documentation, stakeholder approval, and security review notes.

Crucially, it then observed that none of those artifacts exist in the repository. The finding isn't that the policy is wrong, but that its intent is undocumented. Without evidence that this access pattern was deliberately designed, an auditor would likely flag it as potentially unintended broad access rather than a conscious trade-off.

Evaluating a Common Defense

A common response to scenarios like this is to narrow the scope of the system itself, so I asked:

How would you respond to the claim that this platform isn't designed to house HR or other documents that should be kept confidential from an employee's manager?

The AI evaluated that defense against the implementation. While the platform description emphasizes collaboration, the schema defines a generic document model with no type restrictions. A classification attribute exists, but policies do not use it. There are no validations or documented exclusions preventing sensitive documents from being stored.

The conclusion was measured but pointed. The defense is plausible, but it is not substantiated by the implementation. As the AI summarized, the absence of enforcement or documentation makes this look less like an intentional design constraint and more like a retroactive justification.

What this Example Shows

Taken together, this walkthrough illustrates what audit mode looks like in practice. The AI never proposes a policy change. It never suggests a refactor. Instead, it helps surface scope, risk, and undocumented assumptions by explaining what the system already allows. In review and audit, that kind of clarity is far more valuable than creativity.

Audit Is About Clarity, not Creativity

Policy audits are not design exercises. They are about understanding what authority has already been encoded, how broad that authority really is, and whether it can be defended as intentional.

Used correctly, AI is well suited to this work. When constrained to only explain and enumerate, it becomes a powerful lens for surfacing access paths, stress-testing assumptions, and exposing gaps between implementation and documentation. What it does not do is redesign policy on the fly.

The same model that accelerates authoring becomes valuable in audit only when its freedom is reduced. That constraint is not a limitation; it is what makes the AI a trustworthy reviewer. By separating exploration from verification, and creativity from accountability, teams can use AI to gain confidence in their authorization systems without surrendering control.

In audit mode, AI doesn’t decide what should change. It helps you see, clearly and sometimes uncomfortably, what the system actually allows.

Photo Credit: Inspecting with the help of AI from DALL-E (public-domain)

Policy Authoring and Analysis with AI

Phil Windley // Mon Dec 22 07:59:00 2025 // ai llm authz authorization identity

In my last post, I argued that policy does not belong in an LLM prompt. Authorization is about authority and scope, not about persuading a language model to behave. Prompts express intent; policies define what is allowed. Mixing the two creates systems that are brittle at best and dangerous at worst.

That raises the obvious follow-up question: So where can AI actually help?

The answer, in practice, is policy authoring and policy analysis. This doesn’t show up in architectural diagrams, but in the day-to-day work of writing, reviewing, and changing policies. What surprised me while working through this material is how tightly those two activities are coupled in practice.

Where AI Can Help

In real systems, policy authoring rarely starts with code. Instead, it often starts with questions:

• Why is this request allowed?
• What would cause it to be denied?
• How narrow is this rule, really?
• What happens if I change just this one thing?

Those are analysis questions, but they arise before and during authoring, not after. As soon as you start writing or modifying policies, you're already analyzing them. AI tools are well-suited to this part of the work. They can:

• Explain existing policy behavior in plain language
• Say why access will be allowed or denied in specific scenarios
• Propose alternative formulations
• Surface edge cases and trade-offs you might miss

They are not deciding access. Rather, they're helping you reason about policies that remain deterministic and externally enforced.

A Concrete Place to Start

To help make this clearer, I put together a small GitHub repository that you can use to work through this yourself. The repository reuses the ACME Cedar schema and policies I used for examples in Appendix A of my book, Dynamic Authorization. This repo adds just enough structure to support hands-on, AI-assisted work. Take a minute and review these three files:

• ai/cursor/README.md explains how the repo is meant to be used and, just as importantly, what it is not for.
• ai/cursor/authoring-guidelines.md lays out the human-in-the-loop constraints. These aren't optional suggestions; they're the safety rails.
• ai/cursor/starter-prompt.md defines how the AI is expected to behave.

That starter prompt matters more than it might seem. It's not there for convenience. It shapes how the AI interprets context, authority, and its own role. Rather than expressing authorization rules, the starter prompt limits the AI's scope of participation: it can propose, explain, and compare policy options, but it cannot invent model elements or make decisions.

Take a minute to look around the rest of the repo. You'll find a schema file, a file with defined entities, and a number of policies. You'll also see a same request and an expected response. A real analysis might have many of those. I asked Cursor to incorporate all of these in it's context and then gave it the starter prompt. That set me up for using Cursor to author and analyze the policy set in the repo.

Authoring and Analyzing are Complementary Activities

When working with real authorization policies, authoring and analysis are best understood as complementary activities rather than separate phases. You do not finish writing a policy and then analyze it later. Instead, analysis continuously shapes how policies are authored, refined, and understood.

That interplay becomes clear as soon as you start with a concrete request, such as:

{
  "principal": "User::\"kate\"",
  "action": "Action::\"view\"",
  "resource": "Document::\"q3-plan\""
}

The first step is analytical. Before changing anything, you need to establish the current behavior. Asking why this request is permitted forces the existing policy logic into the open. A useful explanation should reference a specific policy and identify the relationship or condition on the resource that makes the request valid. This establishes the current behavior before attempting to change it.

Once that behavior is understood, authoring questions follow naturally:

• What would need to change for this request to be denied?
• How could that change be made while leaving other customer access unchanged?
• Where should that change live so that intent remains clear and the policy set remains maintainable?

These questions blur any clean separation between authoring and analysis. Understanding current behavior is analysis. Exploring how a specific outcome could change is authoring. In practice, the two alternate rapidly, each shaping the other.

AI assistance fits naturally into this loop. It can explain existing decisions, propose multiple ways to achieve a different outcome, and help compare the implications of those alternatives. For a narrowly scoped change like this one, those alternatives might include introducing a new forbid policy, narrowing an existing permit policy, or expressing the exception explicitly using an unless clause.

What matters is not that the AI can generate these options, rather it's that a human evaluates them. Although the alternatives may be functionally equivalent, they differ in clarity, scope, and long-term maintainability. Choosing between them is a design decision, not a mechanical one.

AI accelerates the conversation between authoring and analysis, making both activities more explicit and more efficient, while leaving responsibility for authorization behavior firmly with the human author.

The Human in the Loop

When using AI to assist with policy work, the most important discipline is how you engage with it. The value comes not from asking for answers, but from asking the right sequence of questions, and reviewing the results critically at each step.

Begin by asking the AI to explain the system's current behavior. With the schema, policies, entities, and a concrete request included as context, ask a question such as:

"Which policy or policies permit this request, and what relationship on the resource makes that true?"

Review the response carefully. A good answer should reference a specific policy and point to a concrete condition. In the case of the example in the repo, you might get an answer that references membership in a reader relationship on the document. If the response is vague, or if it invents attributes or relationships that do not exist in the model, stop and correct the context before proceeding. That failure is a signal that the AI is reasoning without sufficient grounding.

Next, ask the AI to restate the authorization logic in plain language. For example:

"Explain this authorization decision as if you were describing it to a product manager."

This step is critical. It tests whether the policy logic aligns with human intent. If the explanation is surprising or difficult to defend, that is not a problem with the explanation, it is a signal that the policy itself deserves closer scrutiny.

Once you understand the current behavior, introduce a small hypothetical change. Without modifying anything yet, ask a question like:

"What change would be required to deny this request while leaving other customer access unchanged?"

The AI may respond in several ways. One common suggestion is to add a new forbid policy that explicitly denies the request. That can be a valid approach in some situations, but it is rarely the only option, and it is often worth exploring alternatives before expanding the policy set.

You can then refine the discussion with a follow-up question:

"What if instead of adding a new policy, we wanted to modify one of the existing policies to do this?"

In response, the AI may suggest modifying an existing permit policy by adding an additional condition to its when clause, typically an extra conjunction in the context section of the policy that explicitly excludes this principal and resource. This narrows the circumstances under which the permit applies without introducing a new rule.

You can refine the design further by asking:

"What if I wanted to do this by adding an unless clause instead of putting a conjunction in the when clause?"

The AI may then refactor the proposal to use an unless clause that expresses the exception more directly. In many cases, this reads more clearly, especially when the intent is to describe a general rule with a specific carve-out.

At this point, it is tempting to treat these alternatives as interchangeable. They may be syntactically valid and semantically equivalent for a specific request, but they are not equivalent from a design perspective. Choosing between a new forbid policy, a narrower when clause, or a more readable unless clause is a human judgment about clarity, intent, and long-term maintainability. These are decisions about how authority should be expressed, not questions a language model can answer on its own.

This sequence illustrates the core of a human-in-the-loop workflow. The AI can generate options, surface trade-offs, and refactor logic, but it does not decide which policy best reflects organizational intent. The final responsibility for authorization behavior remains with the human reviewer, who must understand and accept the consequences of each change before it is applied.

Guardrails that Make AI Assistance Safe

When AI is embedded directly into the policy authoring and analysis loop, guardrails are not optional. They are what keep the speed and convenience of AI from turning into silent expansion of authority.

In practice, many of these guardrails are enforced through the starter prompt itself. The prompt establishes how the AI is expected to behave, what it may assume, and what it must not invent. The remaining guardrails are enforced through human review.

Treat the Schema as the Source of Truth

The starter prompt explicitly instructs the AI to treat the schema and existing policies as the source of truth. This is essential. The schema defines the universe of valid entities, actions, attributes, and relationships. Any suggestion that relies on something outside that schema is wrong by definition.

If an AI response introduces a new attribute, relationship, or entity that does not exist, stop immediately. That is not a creative proposal—it is a modeling error.

Require concrete requests and outcomes

The starter prompt requires the AI to reason about concrete requests and expected outcomes rather than abstract policy logic. This forces proposed changes to be evaluated in terms of actual behavior:

• Why is this request permitted?
• What change would cause it to be denied?
• What other requests would be affected?

Anchoring discussion in concrete requests makes unintended scope expansion easier to spot.

Bias Toward Least Privilege

The starter prompt biases the AI toward least-privilege outcomes and narrowly scoped changes. Without this bias, AI tools often propose solutions that technically satisfy the question but widen access more than intended.

Broad refactors and sweeping rules should be treated with skepticism unless they are clearly intentional and carefully reviewed.

Separate Exploration from Acceptance

The starter prompt makes it clear that AI output is advisory. The AI can propose, explain, and refactor policy logic, but it does not apply changes or decide which alternative is correct.

Every proposed change must be reviewed manually, line by line, and evaluated in the context of the full policy set. If a change cannot be explained clearly in plain language, it should not be accepted.

Preserve Human Accountability

Authorization policies express decisions about authority, and those decisions have real consequences. The starter prompt reinforces that responsibility for those decisions remains with the human author.

The policy engine evaluates access deterministically, but humans remain accountable for what that access allows or denies. If you would not be comfortable explaining a policy change to an auditor or stakeholder, that discomfort is a signal to revisit the design.

Where AI Belongs—and Where it Doesn't

Like I emphasized in my previous post, don't use AI to decide who is allowed to do what. Authorization is about authority, scope, and consequence, and those decisions must remain deterministic, reviewable, and enforceable outside of any language model.

But AI is a great tool for policy authoring and analysis. Used correctly, it helps surface intent, explain behavior, and explore design alternatives faster than humans can alone. It makes the reasoning around policy more explicit, not less.

But that benefit only materializes when boundaries are clear. Prompts must not encode access rules. Schemas must remain the source of truth. Concrete requests must anchor every discussion. And humans must remain accountable for every change that affects authority.

AI can accelerate policy work, but it cannot take responsibility for it. Treat it as a powerful assistant in design and analysis, and keep it far away from enforcement and decision-making. That separation is not a limitation—it's what makes AI useful without making it dangerous.

Photo Credit: Happy computer aiding in policy authoring and analysis from DALL-E (public domain)

AI Is Not Your Policy Engine (And That's a Good Thing)

Phil Windley // Thu Dec 18 09:56:00 2025 // llm ai authz authorization identity

When building a system that uses an large language models (LLMs) to work with sensitive data, you might be tempted to treat the LLM as a decision-maker. They can summarize documents, answer questions, and generate code, so why not let them decide who gets access to what? Because authorization is not a language problem—at least not a natural language problem.

Authorization is about authority: who is allowed to do what, with which data, and under which conditions. That authority must be evaluated deterministically and enforced consistently. Language models, no matter how capable, are not deterministic or consistent. Recognizing this boundary is what allows AI to be useful, rather than dangerous, in systems that handle sensitive data.

The Role of Authorization

Authorization systems exist to answer a narrow but critical question: is this request permitted, and if so, what does that permission allow? In modern systems, this responsibility is usually split across two closely related components.

The policy decision point (PDP) evaluates policies against a specific request and its context, producing a permit or deny decision based on explicit, deterministic policy logic. The policy enforcement point (PEP) enforces that decision by constraining access. It filters data, restricts actions, and exposes only authorized portions of a resource.

Authorization does not generate text, explanations, or instructions. It produces a decision and an enforced scope. Those outputs are constraints, not mere guidance, and they exist independently of any AI system involved downstream. Once they exist, everything that follows can safely assume that access has already been determined.

The Role of the Prompt

This is why access control does not belong in the prompt. You might think it's OK to encode authorization rules directly into a prompt by including instructions like "only summarize documents the user is allowed to see" or "do not reveal confidential information." While well intentioned, these instructions confuse guidance with enforcement.

Prompts describe what we want a model to do. They do not—and cannot—guarantee what the model is allowed to do. By the time a prompt is constructed, authorization should already be finished. If access rules appear in the prompt, it usually means enforcement has been pushed too far downstream.

How Authorization and Prompts Work Together

To understand how authorization and prompts fit together in an AI-enabled system, it helps to focus on what each part of the system produces. Authorization answers questions of authority and access, while prompts express intent and shape how a model responds. These concerns are related, but they operate at different points in the system and produce different kinds of outputs. Authorization produces decisions and enforces scope. Prompt construction assumes that scope and uses it to assemble context for the model.

The following diagram shows this relationship conceptually, emphasizing how outputs from one stage become inputs to the next.

A person begins by expressing intent through an application. The service evaluates that request using its authorization system. The PDP produces a decision, and the PEP enforces it by constraining access to data, producing an authorized scope. Only data within that scope is retrieved and assembled as context. The prompt is then constructed from two inputs: the user's intent and the authorized context. The LLM generates a response based solely on what it has been given.

At no point does the model decide what sensitive data it is allowed to use for a response. That question has already been answered and enforced before the prompt ever exists.

Respecting Boundaries

This division of responsibility is essential because of how language models work. Given authorized context, LLMs are extremely effective at summarizing, explaining, and reasoning over that information. What they are not good at—and should not be asked to do—is enforcing access control. They have no intrinsic understanding of obligation, revocation, or consequence. They generate plausible language, not deterministic, authoritative decisions.

Respecting authorization boundaries is a design constraint, not a limitation to work around. When those boundaries are enforced upstream, language models become safer and more useful. When they are blurred, no amount of careful prompting can compensate for the loss of control.

The takeaway is simple. Authorization systems evaluate access and enforce scope. Applications retrieve and assemble authorized context. Prompts express intent, not policy. Language models operate within boundaries they did not define.

Keeping these responsibilities separate is what allows AI to act as a powerful assistant instead of a risk multiplier, and why AI is should never be used as your policy engine.

Photo Credit: Confused Computer from Generated by DALL-E ((public domain))

The First Agentic Internet Workshop

Phil Windley // Thu Nov 6 10:00:00 2025 // ai agents identity

On October 24, 2025, the day after IIW 41 wrapped up, we held the first-ever Agentic Internet Workshop (AIW1) at the Computer History Museum. Hosting it right after IIW 41 made logistics easier and allowed us to build on the momentum—and the brainpower—already in the room.

Like IIW, AIW1 followed an Open Space unconference format, where participants proposed sessions and collaboratively shaped the agenda in the morning at opening circle. With more than 40 sessions across four time slots, the result was a fast-moving day of rich conversations around the tools, architectures, and governance needed for the agentic internet.

We welcomed attendees from 10 countries, with the U.S., Canada, Germany, Japan, and Switzerland most represented. The geographic spread (see map above) reflected growing international interest in agents, autonomy, and infrastructure. We expect that trend to accelerate as these ideas move from prototypes to deployed systems.

Topics and Themes

IIW 41 was about the state of identity. AIW1 asked: what happens when we give identity the power to act?

Discussions ranged from deeply technical to philosophically provocative. Participants tackled the infrastructure of agentic browsers, agent identity protocols, and governance models like MCP, KERI, and KYAPAY. We saw sessions on AI agent policy enforcement, private inference, and how to design trust markets and legal frameworks that support human-centric agency.

We also explored cultural and narrative lenses, from the metaphor of Murderbot to speculative design sessions on agentic AI glasses, human-in-the-loop messaging, and digital media provenance. Questions like "Do you want agents acting without your consent?" and "What is agenthood, really?" brought the conversation to the edge of ethics, autonomy, and technical realism.

Throughout the day, a recurring theme was trust, how it's built, signaled, enforced, and sometimes broken in a world of interoperating agents.

Looking Ahead

We're just getting started. AIW1 was both a proof of concept and a call to action. The conversations launched here are already shaping work in standards groups, startups, and community labs.

Watch for announcements about AIW2 in 2026. We'll be back—with more sessions, broader participation, and even sharper questions.

You can see all of Doc's fantastic photos of AIW I here.

Photo Credit: Photos of AIW I from Doc Searls (CC-BY-4.0)

Internet Identity Workshop XLI Report

Phil Windley // Wed Nov 5 12:00:00 2025 // agent ai identity iiw

Twice a year, the Internet Identity Workshop brings together one of the most engaged and forward-thinking communities in tech. In October 2025, we gathered for the 41st time at the Computer History Museum in Mountain View, California. As always, the Open Space unconference format let the agenda emerge from the people in the room. And once again, the room was full of energy, ideas, and deep dives into the problems and promise of digital identity.

This time, we also hosted a special Agentic Internet Workshop on October 24, immediately following IIW. It followed the same unconference format, focusing on how personal agents, identity, and infrastructure come together to support agency online. That event deserves its own write-up, so I'll cover it in a separate post.

Whether you're working on self-sovereign identity, verifiable credentials, digital wallets, or the broader architecture of the agentic internet, IIW remains the place where serious builders and thoughtful critics come to talk, sketch, debate, and collaborate. Here's a look at how it went.

Attendance

Internet Identity Workshop XLI (that's 41 for those who haven't picked up Roman numerals as a hobby) brought together 287 participants at the Computer History Museum in October 2025. That's a slight dip from the spring's IIW 40, which topped 300, but still a strong showing, especially in a field where the most impactful conversations often happen in smaller, focused groups.

The sustained numbers are a testament to the growing interest in decentralized identity, personal agency online, and the agentic internet. As always, the hallway track was just as rich as the sessions, and the energy was unmistakable.

Geographic Diversity

We continued to see excellent geographic representation at IIW 41, particularly from within the U.S., where California dominated as usual. Top contributing cities included San Jose (12 attendees), San Francisco (11), and Mountain View (10)—the heart of Silicon Valley is clearly still in it. We continue to see good participation from Japan (11) and had a good delegation from South Korea (4) as well. We saw fewer attendees from Europe and Canada and that's a shame. They're doing important work and their voices are needed in the global identity conversation.

Notably, this time we saw increased participation from Central and South America, a trend we hope continues. IIW benefits tremendously from global perspectives, especially as identity challenges and solutions are shaped by local contexts. That said, Africa remains unrepresented, a gap we'd love to see filled in future workshops. If you know identity thinkers, builders, or policy folks in African countries, point them our way, we'd love to extend the conversation. We'll be holding an IIW-Inspired^TM Regional event. DID:UNCONF Africa happening in February for the second time. We'll work on getting some of those folks over to participate in the global identity conversation next time.

Topics and Themes

As always, the agenda at IIW was built fresh each morning, reflecting the real-time priorities and curiosities of the people in the room. Over the course of three days, that emergent structure revealed a lot about where the digital identity community is—and where it's heading.

One of the most visible throughlines was SEDI (State-Endorsed Decentralized Identity). From foundational overviews to practical demos, governance conversations, and even speculative provocations ("Is Compromising a SEDI Treasonous?"), SEDI became a focal point for discussions about infrastructure, policy, and the nature of institutional trust.

OpenID4VC also had a major presence, with sessions spanning conformance testing, server-to-server issuance, metadata schemas, and questions of organizational adoption. This wasn't just theory—there were working demos, hackathon previews, and implementation notes throughout.

On the technical front, we saw renewed energy around:

• Agent-centric architectures, including agent-to-agent authorization, trust registries, and personal AI agents.
• Key management and recovery, especially via KERI, ACDC, and protocols like CoralKM.
• Post-quantum resilience, with deep dives into cryptographic agility and the readiness of various stacks.

Sessions also ventured into user experience and adoption: passkey wallets, native apps, biometric credentials, and real-world policy interactions. There were thoughtful explorations of friction: what gets in the way of people using these tools? And what happens when systems designed for power users collide with human realities?

Meanwhile, the social and ethical layers of identity weren't neglected. We heard about harms, digital fiduciaries, and the politics of age assurance and identity verification. Sessions like "The End of the Global Internet" and "Digital Identity Mad-Libs" reminded us that the stakes are not just technical, they're societal.

Importantly, global perspectives played a growing role. From the UN's refugee identity challenges to discussions of Germany's EUDI wallet and OpenID in Japan, it's clear the community is engaging with a wider set of implementation contexts and constraints.

All told, the IIW 41 agenda reflected a community in motion, technically ambitious, intellectually curious, and increasingly attuned to the human systems it hopes to serve. The book of proceedings should be out soon with more details.

This Community Still Matters

IIW 41 reminded us why this community matters. It's not just the sessions, though those were rich and varied, but the way ideas flow between people, across disciplines, and through time. Many of the themes from this workshop—agent-based identity, governance models, ethical frameworks—have been incubating here for years. Others, like quantum resilience or national-scale deployments, are just now stepping into the spotlight.

If there was a feeling that ran through the week, it was momentum. The stack is maturing. The specs are converging. The real-world stakes are clearer than ever.

Huge thanks to everyone who convened a session, asked a hard question, or scribbled a diagram on a whiteboard. You're why IIW works.

Mark your calendars now: IIW 42 is coming in the spring, April 28-30, 2026. Until then, keep building, keep questioning. And, maybe, even send in a few notes for that session you forgot to write up.

You can see all of Doc's terrific photos of IIW 41 here.

Photo Credit: IIW XLI The 41st IIW from Doc Searls (CC BY 4.0)

Visa Isn't Centralized—and Neither Is First Person Identity

Phil Windley // Wed Oct 1 10:47:00 2025 // identity first-person-identity fpi ssi trust+frameworks

Recently, I heard someone describe Visa as a "centralized" model. That's a common misconception. Visa doesn't operate a single, central database of all transactions. Instead, it provides a trust framework—a set of rules, standards, and infrastructure—that allows thousands of banks, processors, and merchants to interoperate. The actual accounts, balances, and customer relationships remain distributed across the network.

We already live with another example of a trust framework in the physical world: the driver's license. By law, states issue these credentials according to a well-defined process, and other parties—from bars to TSA agents to car dealerships—accept them as proof of age or identity. What's striking is that most of those parties have no formal contract with the issuing state. The framework itself, enshrined in statute and social practice, creates the trust. People rely on the attributes the license carries, not because they have negotiated agreements, but because the framework guarantees its validity.

This is a helpful way to think about first-person identity. Credentials, issued according to this model, make it possible to build trust frameworks for many different ecosystems, just as Visa did for payments or states have done with licenses. A trust framework defines how participants interoperate, but it doesn't centralize everyone's data or relationships.

Here's the key difference: payments is a relatively simple domain compared to identity. You can imagine one Visa handling payments worldwide. Identity, by contrast, has vastly more requirements, policies, and contexts. There won't be a single "identity Visa." Instead, there will be tens of thousands: ecosystem-specific trust frameworks for finance, healthcare, education, workforce, commerce, government services, and beyond. Each will be tailored to its own needs, but they will all be possible because of the same first-person identity foundation.

Fraud prevention, auditability, and traceability are absolutely essential. But those aren't functions of centralization. They come from well-designed credentials and trust frameworks. First-person identity doesn't reject the Visa model—it makes it possible to replicate it, many times over, in the far more complex world of identity.

Photo Credit: Young woman paying with Visa generated using ChatGPT (public domain)

From IIW to the Agentic Internet Workshop

Phil Windley // Thu Sep 18 08:31:00 2025 // identity ai agents events iiw

We're just a few weeks away from the next Internet Identity Workshop (IIW), happening October 21–23, 2025 at the Computer History Museum in Mountain View. I always look forward to those three days—it's the one place where the people building the protocols and systems that underpin digital identity come together, set the agenda themselves, and move the work forward in real time.

This year, we're trying something new. On Friday, October 24, right after IIW wraps up, we'll be hosting the first-ever Agentic Internet Workshop (AIW) at the same venue. Think of it as IIW's younger sibling: same open space format, same collaborative energy—but focused squarely on the agentic internet.

Why? Because we're at an inflection point. Together, we now face the shift toward an internet where agents—AI-powered and otherwise—interact, negotiate, and make decisions on our behalf. Just like IIW gave us space to define protocols like OAuth, OpenID Connect, and Decentralized Identifiers, AIW is meant to give us a neutral ground to figure out the next generation of protocols for an agentic world.

If you've got work in this space—or even just a deep curiosity about where it's headed—I hope you'll stay the extra day. We're capping attendance at 200 people to keep it intimate, and pricing starts at $150 for independents and startups.

👉 Learn more and register here

And one more thing: both IIW and AIW depend on sponsors to keep costs low and the community strong. If you or your organization would like to help support either event, please get in touch with me.

Early Access to Dynamic Authorization

Phil Windley // Tue Sep 9 15:47:00 2025 // authz authorization identity manning cedar

I’m excited to share that the first six chapters of my new book, Dynamic Authorization: Adaptive Access Control, are now available through Manning’s Early Access Program (MEAP). You can start reading today at Manning’s site. As part of the launch, Manning is offering 50% off.

I wrote this book because I noticed something curious in the identity world: while authentication has largely become a solved problem—at least technically—authorization remains widely misunderstood. Many organizations still rely on outdated models like static role-based access control, which don’t hold up in today’s distributed, collaborative, and zero-trust environments. But the landscape is changing. New tools, such as Cedar, give us the means to create authorization systems that provide better security while also making life easier for employees and customers.

The first chapters of the book lay out this problem space and begin introducing modern approaches. Chapter 1 frames the challenge of authorization in today’s systems. Chapters 2 introduces the broader topic of digital identity, while chapter 3 drills down on authentication. Chapter 4 introduces authorization with chapters 5 outlining old-school static authorization tecahniques and chapter 6 diving into dynamic models: relationship-based access control (ReBAC), attribute-based access control (ABAC), and policy-based access control (PBAC). To make these ideas concrete, I use practical examples drawn from a fictional company, ACME Corp., to motivate the material and show how it is used in life-like scenarios.

Looking ahead, later chapters will introduce Cedar, the open-source policy language from AWS, and compare it with other frameworks like OPA/Rego and XACML. I’ll also cover how to implement policies effectively, treat them as code, and test them for reliability. My goal is to help practitioners understand both the “why” and the “how” of dynamic authorization so they can design systems that adapt to real-world complexity.

If you’ve ever struggled with brittle role hierarchies, confusing permission schemes, or the tension between security and usability, this book is for you. And since it’s in MEAP, you can start reading now and follow along as new chapters are released. I'm open to your feedback and suggestions.