AI agent entitlement mapping: the gap between what an agent can touch and what it uses

Two lists and a subtraction. The first list is what an identity is permitted to do: the objects it can read, the fields it can write, the endpoints it can call, the channels it can post to. The second list is what it has done over some window, read from the audit record rather than from anyone's memory. Entitlement mapping is the comparison, and the output is the set of permissions that were granted and never exercised. Those are the ones to remove, because an unexercised permission is pure blast radius. It cannot help you, since nothing uses it, and it can hurt you, because a mistake or a prompt injection will happily use whatever is available. The review is not a one-off. Permissions get added during incidents, during migrations, and during the week somebody is debugging a failing write at 11pm, and almost none of those additions get removed afterwards.

A human login is a shared surface for unrelated work. The same account files expenses, reads the CRM, approves a purchase order and administers a tool, so when the review says a permission went unused for ninety days, the honest answer is often that the person did not happen to do that thing this quarter and will next quarter. Removing it generates a ticket, and after enough tickets the review stops being run. An agent scoped to one job does not have that problem. If an agent exists to turn call commitments into CRM updates and tickets, and the record shows it has never written to the opportunity amount field, it does not need write access to the opportunity amount field. There is no quarter in which it suddenly will, because its job did not change. That is only true if each agent has its own identity rather than a shared service credential, which is the precondition for everything here and is covered in scoped agent identity. With a shared credential the two lists are meaningless, because the usage column aggregates several jobs and the permission column is the union of all of them.

Three things, and they are the same three that make any agent governance real. One identity per agent, so usage is attributable to a job rather than to a pool. Write permission expressed at the level of named fields and objects, not object types, because "can write Opportunity" is not a reviewable statement while "can write Opportunity.StageName and Opportunity.NextStep" is. And an audit record that captures what was proposed as well as what landed, because a permission exercised only by proposals that were always rejected is a permission the agent does not need either. The fields worth keeping are in the AI agent audit trail. If you have none of these, entitlement mapping is not the first job. The first job is scoping the identity.

Pick a window long enough to cover the work's natural cycle. For post-call execution that is usually a quarter, because renewal and QBR work does not appear in a fortnight. Pull the permission set from what the system enforces, not from documentation, since documentation is a record of intent and drifts within weeks. Pull usage from the audit record. Produce three buckets. Granted and used, which stays. Granted and never used, which goes, and the removal is the whole point of the exercise. Used but not granted, which should be empty, and if it is not then something is executing outside the permission model and that is an incident rather than a review finding. The third bucket is the one people forget to look for, and it is the only one that tells you your enforcement is not actually enforcing.

Remove the unused permissions, then watch for failures. Something will break, because every permission set contains a few grants that are exercised rarely rather than never, and a quarter-long window will miss the annual job. Expect that, and make the restoration path short, because a review whose consequence is a week of broken writes will not be run again. The second thing to do with the result is to treat the shape of it as a signal. An agent whose permission set is mostly unused was scoped by copying another agent's, or by granting an object type because it was quicker. An agent whose set is almost entirely used was scoped deliberately. Over a few reviews the ratio tells you something about how your integrations are built that no architecture diagram will.

Entitlement mapping is hygiene, not security. It shrinks blast radius; it does not stop a correctly-permissioned agent doing a wrong thing inside its permissions, which is what an approval gate is for and why the gate sits on anything irreversible or customer-facing rather than on anything important. See approval-gated vs automatic actions. It also does nothing about the failure mode where a write is permitted, is attempted, returns success, and never lands, because a validation rule or a required field swallowed it silently. That is a verification problem rather than a permissions one. And it is worth saying that none of this is novel: it is ordinary least-privilege practice, applied to a new kind of principal. The novelty is only that agents, unlike people, let you actually do it.