2938 Members
Join Permit's SlackAgentic systems make authorization feel deceptively easy to automate. Give a large language model a few examples, a schema, and a natural-language requirement, and it can generate policy code that looks coherent in seconds. The engineering tension is that "coherent" is not the same as "correct": authorization failures are often semantic, not syntactic, and a policy can be internally consistent while still granting the wrong principal access to the wrong resource under realistic runtime conditions.
That tension gets sharper in AI-heavy stacks because policy authoring is now coupled to planning, tool use, and delegation. An AI agent may act on behalf of a human, chain calls across MCP servers, and transform inputs before touching sensitive data. A plausible policy generated from prose can miss the hidden boundary that matters most, such as whether delegation is allowed for a specific intent, whether a tool argument crosses tenancy lines, or whether trust level should downgrade permissions in ambiguous contexts.
This is why the question "can LLMs write access control policies safely?" should be answered as a systems question, not a model question. Safety emerges when intent is explicitly modeled, boundaries are reviewed by humans, synthesis is constrained by a verifier, and runtime decisions are made with live context rather than static assumptions. AI-generated authorization policy is useful, but only inside a pipeline that treats policy correctness as an engineering discipline.
Authorization is hard because many incorrect policies are still plausible to both humans and models. A generated rule might read like policy-as-code best practice and still encode the wrong relationship between actor and resource, or omit a critical deny condition that only appears when delegation and cross-tenant data are combined. In agent systems, this is common because the principal is no longer just "user X," but a tuple of agent identity, delegating human, session trust, and requested intent.
This is where intent-based authorization becomes essential. If intent is implicit, synthesis tools optimize for linguistic similarity and code shape; if intent is explicit, they can optimize for semantic fidelity. The practical takeaway is that policy generation should begin from declared intent and constraints, not from free-form prompts that ask a model to "write a Cedar policy for file access."
A strong pattern is to decompose high-level requirements into intent atoms: small, testable statements such as "support agent may read ticket metadata for tickets owned by their org" or "billing agent may initiate refund only when a human manager delegates intent=refund and amount under threshold." These atoms make ambiguity visible early and let teams review authorization boundaries before any synthesis step starts.
Schema and boundary validation then act as guardrails. The schema defines valid entity types, relations, attributes, and action signatures; boundary review defines what must never happen, even if a generated policy appears functionally useful. In practice, this is how you separate acceptable ABAC for agent context (trust score, tool args, environment flags) from relationship constraints that belong to ReBAC for agents (who can act for whom, on which resource graph, under which delegation edges).
Verifier-guided policy synthesis means generation is not a single-shot LLM output but a loop. The model proposes policy candidates, a verifier checks them against intent atoms and formal constraints, failures are fed back, and synthesis iterates until properties are satisfied or unresolved conflicts are escalated. This is the core idea behind AutoCedar, documented in the AutoCedar arXiv submission, with implementation artifacts available in the cedar-synthesis-engine repository.
The important artifact is not just "final policy text," but a reviewable evidence package: intent atoms, schema snapshot, verifier results, counterexamples, and decision traces that explain why specific statements exist. Reviewability is what makes AI-generated authorization policy governable in real teams. It allows security, platform, and product owners to approve semantics, not just formatting.
Cedar is excellent for expressing and verifying authorization logic, but synthesis-time correctness and runtime correctness are different layers. Synthesis answers "is this policy aligned with declared intent and constraints?" Runtime PDP enforcement answers "given this live request, should access be allowed now?" Agent and MCP workflows require both because request context mutates continuously across tools, sessions, and delegated actions.
A practical architecture uses Cedar policy authoring and verification upstream, then enforces decisions at request time with a PDP that evaluates current context. That runtime context must include at least agent identity, delegating human identity, resource identity, declared intent, trust level, and tool arguments. Without these inputs, even a formally verified policy can produce unsafe outcomes because the decision surface in production is richer than the static synthesis inputs.
After policy synthesis and review, you still need a durable runtime enforcement plane, and this is where Permit can be introduced as the operational PDP layer. In this model, Cedar-oriented synthesis and verification produce policy artifacts, while Permit handles real-time authorization checks, policy distribution, and integration with application and agent control paths. This separation keeps generation concerns from leaking into enforcement concerns.
For agentic systems, that split is especially useful because runtime authorization must evaluate volatile state across API gateways, MCP connectors, and tool calls. Permit-style runtime enforcement can consume contextual ABAC inputs and relationship data while honoring reviewed policy semantics. The synthesis stack defines what should be true; the runtime PDP decides what is true for this request.
One concrete ecosystem signal is that builders are exploring this design space across databases and infrastructure layers, including PostgreSQL-native Zanzibar-style approaches shared in this community thread. Community posts are not primary evidence of correctness, but they do show policy-model ideas moving into broader AI and data infrastructure conversations.
Generated policies should move through the same rigor as critical code: unit tests against intent atoms, scenario tests across tenancy and delegation boundaries, and regression suites for previously fixed authorization bugs. Deployment should be staged with canary decision logging and explicit rollback semantics, because authorization regressions are often low-frequency but high-impact. Policy updates should be versioned with change diffs that map back to intent and verifier deltas, not just raw text edits.
Auditability depends on connecting authoring and runtime records. You want to answer who changed policy intent, what verifier outcomes changed, when enforcement switched versions, and why a specific request was allowed or denied. When that chain is complete, teams can safely use AI assistance for policy authoring while maintaining compliance-grade accountability.
LLMs can generate useful policy drafts, but not safely on their own in high-stakes environments. Safety requires intent decomposition, verifier-guided synthesis, and runtime enforcement with live context. The right framing is "LLM-assisted policy engineering," not autonomous policy writing.
It is an iterative loop where candidate policies are generated, formally checked against intent atoms and constraints, then refined based on verifier failures. The verifier provides counterexamples that expose semantic mistakes early. This process yields stronger policy correctness than prompt-only generation.
Cedar provides a precise language for defining who can do what under which conditions, making it suitable for agent authorization logic. In agent systems, Cedar policies should encode both delegation relationships and context-aware constraints. They are most effective when paired with runtime PDP checks that evaluate live request data.
If intent is not reviewed first, ambiguity gets compiled into policy and looks legitimate after generation. Intent review forces teams to agree on boundaries, prohibited actions, and delegation semantics before synthesis begins. That reduces the risk of polished but semantically wrong rules entering production.
Test them first against intent atoms and adversarial scenarios, then stage deployment with canary decision traces and rollback paths. Treat policy bundles like release artifacts, with versioning and compatibility checks across services and agents. Production rollout should be gradual because authorization defects can be subtle and severe.
Updates should be tied to explicit intent changes, schema evolution, or incident learnings, with verifier output captured each time. Audit logs need to link policy version, reviewer approvals, runtime decision records, and actor context. This creates a defensible evidence trail for both security operations and compliance.
Verification proves alignment with modeled intent, not omniscience about live requests. Runtime decisions still depend on dynamic facts such as agent identity, delegating human, resource state, intent declaration, trust level, and tool arguments. Without that context, a correct policy model can still yield incorrect real-world authorization decisions.
Full-Stack Software Technical Leader | Security, JavaScript, DevRel, OPA | Writer and Public Speaker
