Skip to content
bitscrafter

An Entitlement AI Assistant: the LLM Proposes, the AI Agent Orchestrates, the Policy Engine Decides

  • Lab
  • Cloudflare
  • Authorization
  • AI Agents

A customer writes to a SaaS provider’s support: a colleague cannot create API tokens, and could the company have advanced analytics for a month? The representative who takes the case needs answers that cross five domains — authentication, authorization, entitlements, policy and subscriptions — and a change that only a person may make. The Entitlement Assistant is a chat assistant for that representative, built and deployed on Cloudflare: it finds the account, explains why a person can or cannot do something, and prepares the change.

The model in it only proposes. It picks tools and their arguments; every tool that reaches data runs a use case that asks one decision point before it reads or changes anything; a change is only prepared, and a person confirms it — a supervisor too, where a policy says so. This series explains how, from the principle to the tables, and lets you try it.

The demo needs an account: write to us for one. Try it, the series’ second part, walks through every step with a screenshot, no account needed.

In five minutes

The assistant is one Cloudflare Worker: a case chat for the representative, an approvals panel for the supervisor, an agent a case, a workflow an approval, and PostgreSQL behind Hyperdrive as the system of record.

  • The principle — the LLM proposes, the AI agent orchestrates, the policy engine decides: a prompt injection can change what the model says, never what the system allows.

  • The decision point — five stages, principal & subject account, principal access, contact access, entitlement and policy (the code’s first two are account and access), the most restrictive outcome winning: Deny over Conditional over Allow.

  • A change — a grant is prepared as a change request with its diff; a click confirms it; over 14 days, a supervisor approves it, and a workflow applies it after deciding again.

  • The record — every change, and nearly every decision on customer data, joins a hash chain in the same transaction.

  • What is not built — changing a subscription, and the production concerns the project lists in its own document.

The problem

A representative answering “why can’t Carol create API tokens?” crosses the customer’s identity, the representative’s own access, the account’s entitlements, the policies and the subscription in one question. A chat model alone is unsafe there: it reads text a customer wrote, so whatever it decides, a customer can steer.

The principle

The project names it CM-5: the LLM proposes; the policy engine decides. The model only selects tools and arguments. The principal comes from the verified session, every tool call is authorized by the decision point, and every state change needs the representative’s confirmation in the UI. Figure 1 adds the third role this series’ title names: the AI agent that orchestrates between them.

The three roles: the LLM proposes, the AI agent orchestrates, the policy engine decides; a prompt injection reaches the model only hidden in the customer's words the representative passes on; a person's click between a proposal and any effect

Figure 1 — The three roles, and the person's click

Every effect on a customer traces back to a person’s click: the representative’s confirmation, and a supervisor’s approval where a policy requires one. Audit records, prepared change requests and the stored conversation change nothing a customer has.

The series

Each part stands on its own, and each but the Index opens on a map of its sections; read the one you need.

The series: its seven parts around it, in reading order

Try it

The walkthrough of the live demo, a screenshot a step — readable without an account. It reads in about 11 minutes. The details.

Architecture

The principles, the context, the hexagonal rings and their directories, every component, the overall flow, concurrency, the deployment, the network and its operation. It reads in about 10 minutes. The details.

Data

The tables a subsystem at a time, every column, and the state machines. It reads in about 11 minutes. The details.

Use cases

A chat turn, explaining access, a grant applied at once, a grant through approval, the sweep, a case from open to close — each a sequence. It reads in about 10 minutes. The details.

Authorization and security

The decision point, the eleven policies, the principles followed, the audit chain and the test that the model never authorizes. It reads in about 11 minutes. The details.

Built and measured

How well the model does, measured; how the project was built; what is not built. It reads in about 10 minutes. The details.

Index

Every tool, policy, table, subsystem, component and state, A to Z, each linked to where it is explained. It reads in about 4 minutes. The details.

References

1 / 7