How to Require Human Approval for AI Agent Permission Changes on Client Folders

Start with the operations that change who can see a folder

An agent with delegated access to Google Drive or SharePoint can usually read, create, edit and share. Only a subset of those calls changes exposure, and that subset is where approval belongs. Build the inventory from the tools the agent can actually invoke, not from the platform's full API surface. For each tool, ask whether it writes to sharing state.

In both platforms the permission-changing operations fall into four categories: adding a named user or group to a folder, creating a link that grants access to anyone holding it, creating a link scoped to the whole organization, and changing the role of an existing grantee, for example from viewer to editor. A fifth category is easy to miss: widening inherited access, where a change on a parent folder alters who can reach every child. Each platform exposes these through different calls and different terminology, so record the mapping per platform and keep it current as the agent's toolset changes.

Reads, such as listing files or reading a folder's current permissions, do not change exposure. Treat them as a separate, lower-risk class. Scoping oversight to context and risk is consistent with NIST AI RMF guidance that not every AI system needs the same level of human oversight.

Policy conditions that decide allow, block or escalate

NIST describes attribute-based access control as evaluating rules against subject attributes and object attributes. The same model fits approval routing. Write conditions over the requested action, the target folder and the context of the call, then map each combination to an outcome. The attribute names below are examples; define your own against your folder labelling and identity data.

Human review works best as a complement to automated policy filtering, so the automated layer should resolve everything it can and send only the ambiguous or high-impact calls to a person.

• Read-only call, any folder: Allow. No change to sharing state.
• Internal user added as viewer, non-client folder: Allow, with the decision recorded.
• External recipient added to a client folder: Escalate for human approval.
• Anonymous or organization-wide link on a client folder: Escalate, or block outright if policy forbids it for that classification.
• Role elevation to editor or owner on a client folder: Escalate. Consider dual authorization.
• Change on a parent that widens inherited access to client folders: Escalate, evaluating the scope of the children affected.

Design requirements for the approval step

Show the approver what will happen, not what the agent says it intends. The held request should present the concrete parameters: which folder, which recipient, which role, which link type. How an agent conveys the intent of its actions is still an open question in NIST's agent identity work, so do not rely on the agent's own narrative as the basis for a decision. Release only the call that was approved. If the agent alters parameters after approval, treat it as a new request.

Record the identities separately. The agent, the user it acts for, and the approving human are three different things, and NIST's agent identity work raises binding agent identity to human identity as a key problem for human-in-the-loop authorization. Require that the approver is not the identity that initiated the request. NIST describes dual authorization as approval by two authorized individuals; reserve it for the highest-risk changes, such as role elevation on the most sensitive client folders, and document any exception you adopt. Approval authorities are an organization-defined assignment, so name them explicitly, per client or folder class.

Decide in advance what denial and timeout mean. A sound default is that no decision within the window results in denial, and the agent is told so. Silence should never release a call.

Finally, prevent bypass. The approval step only means something if the agent has no other path to the sharing APIs. Route all sharing-capable tools through the enforcement point and avoid giving the agent credentials that can change permissions directly. Least privilege on the agent's delegated access matters as much as the approval prompt.

Runtime enforcement versus after-the-fact review

A review of activity records after the fact tells you that a client folder was shared with an external address. It does not stop the exposure, and the data may already have been accessed. Approval at the tool call changes the order of events: the decision comes first, and the action follows only if it is permitted. That is the difference between enforcement and detection, and for permission changes on client data, the cost of getting the order wrong is borne by the client.

This pattern is also narrower than it may sound. It governs individual tool calls. It does not by itself establish accountability across a multi-step task, so keep the policy conditions tied to the specific call in front of the approver.

Trussed enforces policy in the execution path across agents, tools and MCP servers, with outcomes of allow, redact, block, rate limit and escalate for human approval. Enforcement is at runtime, not reviewed after the fact, and each decision generates audit-ready evidence. Trussed can be self-managed in the customer cloud, with configurable retention and data residency. The design above is useful with any enforcement point that can hold a call and record the result.