A company sets up an agent carefully. It gets its own identity, a narrow profile, access to the two modules it needs and read-only on a third. Someone reviews the list, signs it off, and the agent goes to work. Six months later the same agent can read a field that holds salary bands, update a module that did not exist at launch and call a tool that was connected after the review.
Nobody changed the agent. Nobody granted anything. The permissions drifted, because they are defined against an estate, and the estate moved.
Most of what is written about agent permissions describes the first grant. This is about the second year, which is where the exposure builds.
There are four ordinary ways, and each one is somebody doing their job.
New fields arrive visible. In most business suites a field added to a module is visible to every profile that can see the module, unless someone sets it otherwise. The administrator who adds a "bonus tier" field to the employee record is thinking about the HR workflow, not about the agent that reads that module for onboarding. The agent now reads the field, and there is no event to tell anyone.
New modules and new connections arrive with defaults. A module added for a new process, an integration connected to a new tool, a new automation that shares a record across teams: each has its own permission defaults, and each interacts with the agent's profile in a way nobody tested, because the profile was reviewed before they existed.
Roles are reorganised. A team is split, a role renamed, a manager's access widened for a project. If the agent's profile was built by copying a person's, it inherits those changes. If it was built on its own, it may now be misaligned with the team it serves.
The person behind it leaves. An agent often runs under an identity created by one administrator, with a token that person holds. When they move on, the token lives on, the grant stays, and the question of who now owns this agent's reach has no answer. We covered the case for a separate service identity in AI agent security in a business suite; a separate identity helps, but an identity nobody owns drifts as well.
The cost is not usually a breach. It is that the answer to the governance question, "what can this agent reach?", stops being the answer anyone wrote down. The last review said one thing; the system now says another. When an auditor, a customer's security questionnaire or an incident asks, the honest answer is "we believe it was the list from March".
The second cost is that drift makes agents harder to trust and therefore harder to extend. A company that cannot say what its first agent can reach will not give a second agent more to do. The reach becomes a reason to hold back, which is the opposite of what the agent was bought for.
The fix is as unglamorous as an access review for staff, and it works the same way. A quarterly review, one page per agent, run by a named person.
The page is a table with a row per agent and a few columns: the agent's purpose in one sentence; the modules it can read; the modules it can write; the actions it can take without approval; the tools it can call; the owner; the date of the last review. That is all. The value is in the comparison, not the format.
Five questions go with it, asked of every agent, every quarter.
1. Is the purpose sentence still true? If the agent now does something the sentence does not say, either the sentence changes with the owner's agreement, or the agent's reach narrows.
2. What changed in the estate since the last review? New fields, modules, integrations and role changes, from the administrators' change log. For each, does the agent now reach it, and should it?
3. Which of the agent's permissions were used? The audit trail shows what it actually touched. A permission unused for a quarter is a candidate for removal.
4. What can it do without a person? The list of actions that need no approval should only get shorter or stay the same, unless the owner decided otherwise in writing.
5. Who owns it, and are they still here? The owner must be a current employee, in a role that can decide about the agent's purpose.
Grants expire. Every grant carries a review date, and an agent whose review is overdue loses its write access until it is done. Read access can stay. The effect is that the review stops being optional, because skipping it stops the agent from doing its job, which is a pressure someone in the business will apply on your behalf.
The estate's change log feeds the review. The second question depends on knowing what changed. If administrators already keep a change log, the review reads it. If they do not, starting one is the first useful result of the first review.
The first review takes an afternoon and finds something. It is nearly always a field the agent can read that nobody intended, or a tool it can call that was connected after launch. The goal is not to be alarmed but to see the gap between the list you wrote and the system you have, and to close it by changing a profile rather than by writing a policy.
The second review is quicker. The agent table exists, the change log exists, and the five questions have owners. By the third, the review is the thing that lets the company widen an agent's job with confidence, because the current reach is known and the next step can be measured against it. That is the connection to the permission mode choices we described for an MCP server that opens an estate to outside agents: the mode is a setting, and the review is how you know the setting is still right.
Suppose the agent handles customer follow-ups and reads the account and contact modules. Between reviews, three things happened: finance added a "credit hold" field to the account, the support team connected a ticket tool, and a new "partner" module was created for referral deals. Asked of that agent, question two gives three entries from the change log. The credit hold field is now readable, and a follow-up agent has no need to see it, so the profile hides it. The ticket tool is a tool the agent can now call, and the purpose sentence does not mention tickets, so the connection is removed until the owner decides. The partner module is outside the agent's purpose, and the profile already excludes it. Three entries, two changes, ten minutes.
We run this review as part of the managed agent layer for companies of 5 to 1,000 users: the table, the five questions, the expiry rule and the change log. Discovery is no-risk: we map what your first agent can reach today against what you intended, and you pay only if you go ahead. The setup carries a guaranteed estimate, so if we estimate low, we absorb the difference.
An agent's permissions are not a decision made once. They are a condition kept, and the review is how it is kept.
In a no-risk discovery we look at your CRM, finance and operations systems and who owns each part, and show what a connected system would do differently. You pay only if you proceed. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
