Growth is a permission event
As the bank grew, reorganizations and new lines of business kept changing who needed access to what. A permission that made sense in one role could be wrong after a transfer. I came to treat access recertification as part of running the platform, with attention to what should be removed as well as what should be granted. An AI connection needs the same ongoing attention.
Enterprise AI inherits that reality. An access model can look perfect when a Claude pilot launches and drift as people move. Transfers, temporary coverage, reorganizations and departures are ordinary events, so a permission review has to test them instead of relying on a static list of approved users.
Test the organization as it changes
Choose representative scenarios with your identity and business owners. A regional manager moves to another region. An analyst gets temporary access for a project. A service owner leaves. For each, define which access should change, when the change takes effect and who verifies it.
Keep business responsibility distinct from directory group membership. A group can implement an access decision, but someone still needs a rule for who belongs in it and why. The review should trace the authority behind membership, not just confirm the group exists.
Include a role transfer in user acceptance testing. The business reviewer should confirm both the newly permitted scope and the scope that should have disappeared. That paired check catches the common additive change that grants the new role while quietly keeping the old one.
Follow access through the whole AI workflow
Trace the path from the person using the assistant, through the connected service, to the underlying records. Find where access decisions are made and whether a shared service credential widens the effective scope. A correct sign-in at the front door proves nothing about downstream restriction. This is why I insist that identity, permissions and data boundaries are settled before the first user logs in, and why I favor designs that respect existing row-level security rather than rebuilding it inside the AI layer.
Evaluate summaries and aggregates, not just raw rows. Restricted information can leak through a count, a comparison or a narrative. In healthcare, a small count can identify a patient. In banking, a comparison can reveal a restricted client relationship. Test the outputs the assistant actually produces.
Consider cached and previously generated material. A user who loses source access should not retain an unrestricted route through a saved response or secondary store. The right behavior depends on product and policy, but the review must name the issue and an owner.
Make temporary access genuinely temporary
Record the purpose, approver and expiry for every temporary grant. A pilot exception should not become permanent because nobody remembered to remove it.
Test revocation with an approved test identity. Confirm the denial at each relevant layer and check that the user-facing message does not reveal restricted context. Record any delay between the identity change and effective source access so the owner can decide whether it is acceptable.
Resist broadening access to make a confusing support ticket go away. An empty response may be a correct denial, an identity mismatch or unavailable data. Granting administrator access makes the symptom disappear while dismantling the boundary the pilot was meant to prove.
Review evidence and responsibility together
A periodic review should show current users, approved purpose, source scope and open exceptions. The business owner confirms need and the technical owner verifies enforcement. Either view alone is incomplete. A justified entitlement can be implemented wrong, and a correctly implemented one can outlive its purpose.
Use the existing access review cycle, and add checks when roles or source responsibilities change. The cadence should reflect how quickly an incorrect entitlement could cause harm and how reliably revocation propagates. Give unresolved exceptions an owner and a due date. A review that lists the same exceptions quarter after quarter needs a resolution decision, not another signature.
Then use the next real role transfer as a live test, and add a regression case every time an issue surfaces. Repeating that check through ordinary change keeps permissions tied to current responsibilities rather than to the original rollout.