Find Out What a Policy Change Breaks Before Your Agents Do

Least privilege is easy to agree with and hard to apply. You open an agent’s policy, see a table you are fairly sure nothing uses, and untick it. Then a support bot that queried that table twice a day starts failing, and you hear about it from a customer.

After that happens once, people stop tightening. Policies only ever grow, because removing access feels like a gamble and adding it does not.

Answer it from the audit log

The gateway already records every agent request: which tool, which table, which columns were asked for, which filters, how many rows came back. That is enough to answer “what would have happened under a different policy?” without touching the database at all.

Preview impact replays up to the latest 50,000 recorded requests from the last 24 hours, 7 days or 30 days against the policy you are editing — before you save it. For each agent token it reports what would have come out differently:

• Blocked — the request would be refused: a removed table, a now-denied column the agent asked for by name, a filter on a column it may no longer filter.
• Narrowed — the request still succeeds, with fewer columns.
• Masked or exposed — a column would come back masked, or come back in the clear where it used to be masked.
• Truncated — a lower row cap would cut the result.
• Rate-limited — replayed per token per clock minute, the same window the live limiter uses.
• Newly allowed — requests that were refused and would now succeed.

Each finding comes with example requests, next to a plain summary of the change itself. Nothing is saved and the database is never queried.

Tables removed: tickets

helpdesk-bot    blocked     reads of tickets would be refused
billing-agent   narrowed    card_last4 no longer returned

“Exposed” is there on purpose. Loosening is the change people preview least, and a policy edit that unmasks a column for every agent deserves the same scrutiny as one that blocks them.

The same rules, not a copy of them

A simulator that re-implements the policy engine is a second policy engine, and the two drift apart. This one calls the same pure functions the live request path uses, fed from the stored schema snapshot and the PII map instead of a live connection. When enforcement changes, the preview changes with it.

What it cannot tell you, and says so

• Row filters and minimum group sizes change which rows come back, and that is only knowable by running the query. Those requests are reported as “results may change”, never as a row count we made up.
• Usage budgets and the exposure cap depend on running counters rather than on one request, so they are not simulated.
• Requests logged before the gateway recorded which columns were asked for are marked approximate and treated as “all columns” — the generous reading, so the preview never overstates breakage.
• If the window holds more than 50,000 requests, only the newest are replayed, and the preview says it was cut short.

A preview that overstated breakage would push people back to never tightening. One that understated it would be worse. An honest “cannot know this” beats a confident wrong number.

The loop it enables

Untick what you think is unused, then preview a week of traffic. If nothing breaks, save. If something does, the examples name the agent and the request, and you decide with that in front of you. Least privilege stops being a leap of faith.

Preview impact sits next to Save on the policy tab of the DBShifts AI Agent Gateway.