dvaddi

Agreed, and this is the real gap in Part 2. The suite proves the policies over the entities in tests.json; mutation testing proves each policy earns its keep. Neither says anything about the grants production actually loads. And because Agent carries no tenant, adding billing to support-assistant’s write_groups is one edit with a blast radius of every tenant whose users and tenant already hold billing. Your diff is the right shape. Three refinements from trying it: You don’t have to enumerate users. Effective permission is agent ∩ user ∩ tenant, so the ceiling across all users of a tenant is agent ∩ tenant. Enumerate (agent, tenant, tool, action) with a synthetic user holding exactly the tenant’s groups. User-grant changes get their own, per-tenant diff. Set delegated_read_groups / delegated_write_groups to the full set so the run computes the ceiling rather than one task type’s scope. destroy is never allowed without an approval, so either supply a synthetic valid approval (same tenant, holds the grant, fresh, matching hash) or diff on write and treat destroy as write plus approval. Then: stage the new entity store, compute the ALLOW set, diff against the promoted one, and any new ALLOW on write/destroy blocks promotion until reviewed. It’s the data equivalent of the policy mutation test. Cedar’s symbolic analyser compares policies, not entity data, so this is a loop over cedar authorize (or the library Authorizer), not a solver job. The underlying choice is whether Agent should stay tenant-global. A per-tenant enablement attribute would shrink the blast radius, at the cost of one more thing each tenant administers. Either way the grant diff is worth having.

Not today, and you’re right that it should be its own line. The event we emit carries the decision and the determining policy IDs; whether the tool was on the menu we sent that session isn’t a field. Cedar can’t supply it either: it sees entities, not what the client was shown. The fix is gateway-side. When it answers tools/list for an on-behalf-of token it records the filtered set (and bumps a version on list_changed). At call time it compares the tool name against that set and adds advertised: false to the event. That becomes an alert distinct from any forbid ID. It also catches something the named-forbid alert misses. In the Bob replay in Part 2 (same tenant, no write grant) the deny comes back with “no policies applied”, so there’s no ID to alert on. An unadvertised-tool flag still fires there. The one caveat: a name the agent was never shown can also come from a stale name or a hallucination, so it’s a strong injection signal, not proof. Thanks, this goes into the production write-up.

Thanks — Part 2 is largely about this. The gateway doesn’t tag content; it makes content irrelevant to scope. Every call carries the scope this hop holds (delegated_read_groups / delegated_write_groups in the context), the depth-0 scope is minted from the entrypoint or task type — a summarize request mints read-only — never from anything the model read, and a request-scope forbid runs on every call. So a poisoned ticket can’t widen scope on a later call; the “close every Acme ticket” variant is denied by that forbid even though no tenant line is crossed. Part 3 narrows the scope per hop as agents hand off. What’s left is the honest limit: the gateway bounds authority, not influence. Injected text can still steer the model toward a call that’s already in scope — read a different ticket Alice may read — so marking retrieved content untrusted at the model layer is complementary, and I’d run both. On logging: agreed. Cedar returns the determining policy IDs with every decision; the post’s replays show tenant-isolation and request-scope by name, and a deny with a named forbid is exactly the line to alert on. Default denies have no name, which is why anything you care about is a forbid.