Giving an agent access to Drive, email, and GitHub creates a different problem than simply connecting three tools. The question becomes: what action can this agent perform, on what resource, on whose behalf, for how long and under what conditions?
The most useful answer is not to remove so many permissions that the automation stops working. It's creating a layered authorization boundary. The connector sets the maximum ceiling; an execution policy reduces this ceiling for each task; higher impact operations may require approval; and all relevant decisions are auditable.
This separation is in line with recent NIST direction. In February 2026, the NCCoE published a specific concept paper on identity and authorization of AI and software agents and addressed identification, authorization, auditing, and non-repudiation as issues in their own right. The document is a conceptual draft, not a final standard, but it makes it clear that giving tools to an agent does not, in itself, resolve the trust boundary.
The May 2026 NIST report on responses to the agent security consultation also records broad agreement among participants that traditional cybersecurity principles remain relevant but need to be adapted to agentive systems.
To understand the previous layer of this discussion, it is worth connecting this drawing to what the Agent Plugins format standardizes. A format can describe or integrate a tool; authorization still has to answer who can use it, on what and with what consequences.
Least privilege isn't just about choosing a small scope
OAuth scopes, application permissions, and tokens are important controls, but they do not necessarily represent the full intent of a task.
Imagine an agent in charge of analyzing a ticket received via email, consulting a technical document in Drive and preparing a fix in a repository. The task does not automatically imply that he must read the entire mailbox, open all files in the organization, write to any repository or send a final message without confirmation.
Authorization must work on at least two levels.
The first is the structural ceiling: what capabilities the integration can receive from Google or GitHub. This is where OAuth scopes, GitHub App permissions, and repository selection come in.
The second is task authorization: within that ceiling, which resources and actions are released for this specific execution. It is this layer that prevents a technically valid credential from becoming unrestricted authorization for the model.
The principle of least privilege already appears in the NIST catalog of controls as AC-6. The same family of controls also separates event logging, log content, and audit generation in AU-2, AU-3, and AU-12. This division is useful for agents: granting access and being able to later reconstruct how it was used are related but distinct problems.
Draw the authorization boundary in seven steps
1. Give the agent its own identity
Don’t treat the agent as just “the user who authorized OAuth”. Register a workload or application identity that allows you to distinguish the human who delegated the task from the software that performed the action.
Recording an operation should allow responding, for example: user A requested the task, agent B executed it, policy C authorized it and credential D was used.
This separation reduces a dangerous ambiguity: a call made “on behalf of the user” does not mean that anything permitted to the user is automatically authorized to the agent.
2. Set the lowest possible ceiling on the connector
In Google Drive, the documentation recommends choosing the narrowest scope possible. When the flow allows the user to select or share specific files with the application, drive.file provides access on a per-file basis rather than granting general Drive access. Drive and drive.readonly reach all files compatible with the respective access level.
In Gmail, choose the capacity you need. gmail.send is for sending; gmail.readonly allows reading; gmail.compose allows you to manage drafts and send messages; and gmail.modify brings together reading, writing and sending. The mail.google.com scope is even broader and includes permanent deletion.
On GitHub, GitHub Apps start without explicit permissions and the documentation itself recommends selecting only the minimum permissions required. Permissions can be separated by repository, organization, company, or account capabilities.
3. Reduce again by task
Here is the layer that is often missing.
Even if an integration is authorized to access ten repositories, the current task may only need one. Even if the agent has gmail.readonly, it may only receive messages previously selected by a search or rule. Even with permission to write to Drive, the current execution may only need to read two documents.
A task policy can be described as a small authorization envelope containing:
- identity of the user who delegated;
- agent identity;
- allowed tool;
- allowed resources, such as file IDs, messages, or repositories;
- allowed operations, such as read, create draft or open a change;
- expiry date;
- volume or quantity limits;
- condition of approval, when applicable;
- task identifier for audit.
This envelope is an architectural recommendation, not a format required by NIST or providers. The goal is to turn “the agent has access to Gmail” into something operationally verifiable, like “this task can read these messages during this execution.”
4. Don't deliver long-lasting credentials to the template context
Refresh tokens, private keys, and other long-lived secrets should remain in a credentials layer or broker, not in the prompt, in the agent's textual memory, or in arguments that it can replay.
Google's documentation recommends secure storage for tokens and incremental authorization, requesting new scopes when functionality actually needs them, rather than requesting everything at initial authentication.
Incremental authorization improves consent and avoids requesting capabilities in advance, but it does not replace per-task control. Once broader authorization exists, the application still needs to decide what operations the agent can perform at that time.
On GitHub there is an additional useful mechanism: a GitHub App's installation token can be issued for specific repositories and with a subset of the permissions granted to the app. These installation tokens expire after one hour.
5. Separate reading, preparation and external effect
Not all operations deserve the same autonomy.
Reading a selected document is different from changing its content. Creating a draft is different from sending a message. Preparing a code change is different from committing it to a protected branch or pushing it into production.
A practical policy can automatically release low-impact operations and increase demand as the effect becomes more difficult to reverse.
This avoids two extremes: an agent with permanent power for any operation or an agent that asks for human confirmation after each reading and, therefore, loses much of its usefulness.
6. Put approval on the risky action, not the entire conversation
Human approval works best when it is tied to the concrete call that produces the effect.
If policy requires confirmation before sending an external email, the agent can research context and prepare the draft without interruption. Approval appears only before the send operation.
The same reasoning can be applied to deletions, sharing changes, publishing, merging or other actions defined by the organization as sensitive.
This detail is especially important in Gmail. The gmail.compose scope, for example, covers both draft management and sending. Therefore, if the organization's policy wants to “allow draft, prohibit automatic sending”, the scope alone does not represent this boundary: the application needs to prevent the send call in its own authorization layer.
7. Record the decision, not just the end result
Saving only the agent's textual response is insufficient to investigate an action.
The registry needs to allow reconstructing the authorization path: which identity performed, which user delegated, which tool was called, which resource was affected, which operation was requested, which policy decided, whether approval was given, and what the result was.
NIST audit controls distinguish event logging, record content, and generation of those records; The 2026 Agents Concept Paper also highlights auditing among the specific issues to be addressed for software agents and AI.
The log must not store the secret used in the call. What matters is a secure reference to the credential or session, sufficient to track the event without turning the audit system into another credential repository.
Drive, email and GitHub require different controls
| Integration | Least useful privilege | Where native control helps | Where an additional policy makes a difference |
|---|---|---|---|
| Google Drive | Prefer specific files when flow allows | drive.file can limit access to files used or shared with the application | Restrict IDs, folders, write, share, and delete operations by task |
| Gmail | Choose scope depending on reading, sending or composing | There are different scopes for sending, reading, composing, modifying and metadata | Limit which messages go into the task and block effect endpoints like sending when necessary |
| GitHub | GitHub App with minimal permissions and only required repositories | Installs and tokens can be restricted by repository and permissions | Limit branch, operation, number of changes, workflow and actions that require approval |
In Drive, the gain is being able to bring consent closer to the resource itself. Google's documentation recommends drive.file for many cases where broad access is not necessary and highlights that the user can choose the files shared with the application.
On GitHub, the GitHub App framework allows you to combine minimum permissions with repository selection and, when issuing the installation token, reduce repositories and permissions again.
In Gmail, the border tends to require more control from the application. The documented scopes differentiate capabilities, but do not generally offer “only these three messages from this execution” OAuth authorization. This conclusion arises from the level of granularity of the published scopes; therefore, when the task needs a selection smaller than the scope, this selection must be applied by the broker or agent policy layer.
An example of a boundary that keeps the agent useful
Consider the task: “Read the customer ticket, consult the specification, prepare a correction, and leave a response ready.”
A working configuration does not need to grant everything.
The broker can allow reading only messages that belong to the ticket, make the Drive file selected for that product available to the agent and issue a GitHub credential valid only for the corresponding repository. The agent queries the context, prepares its change, and creates the response.
If the organization considers external shipping or code integration to be higher-impact actions, these operations fall outside the initial envelope. The agent presents the result for approval and receives additional authorization only for the confirmed step.
The difference is small for those who use the system, but big for security. The agent remains able to complete almost all work. The most sensitive perk appears only at the edge of the effect.
What tends to break the least privilege model
- A broad token reused for all tasks. Convenience eliminates the separation between what the integration can do and what the current execution should do.
- Credential available directly to the model. An unexpected instruction or malicious content begins to compete for control over a real credential, instead of requesting actions from an intermediary that applies policy.
- Writing permission granted because “it might be useful.” Permission must arise from the actual task, not from future possibilities.
- Trust the prompt as a security mechanism. “Do not send”, “do not delete” or “only access this folder” are behavioral instructions; the authorization boundary needs to be applied outside the model.
- Approval for everything. When every innocent step depends on confirmation, users tend to look for shortcuts or grant permanent privileges to reduce friction.
- Log only the conversation. Without recording calls, resources, policy decisions, and approvals, the audit cannot reconstruct the real effect of the agent.
The most secure architecture places an intermediary between model and credential
Instead of allowing the model to directly call Drive, Gmail, or GitHub with persistent credentials, the architecture can use a tool broker or policy enforcement point.
The agent requests a structured operation. The broker identifies the task and the agent, checks whether the resource and action are authorized, retrieves or obtains the necessary credential, executes the call and returns only the appropriate result.
If the operation exceeds the task policy, the broker does not “trust” the agent to restrain itself. It denies the call or starts the approval flow.
This approach also makes the role of the integration format clearer. Knowing what the Agent Plugins format standardizes helps with the interoperability of tools; Knowing how to limit permissions decides how far a connected tool can really go.
The design rule is simple: grant the agent the smallest authorization that still allows it to complete a useful end-to-end task, and make the elevation happen only at the step that actually requires the most privilege. This preserves autonomy without turning a convenient integration into a universal credential.
