Designing Trustworthy Internal AI Agents: A Least-Privilege Playbook

Internal AI agents become useful when they can read work context and take actions. That also makes them security-sensitive: an agent connected to mail, documents, calendars, or source code is a software identity operating in business systems.

The practical control is AI agent least privilege. Give each agent a narrowly defined identity, only the resources needed for one job, limited write paths, approval gates for consequential actions, and audit evidence that supports review. Do not model an agent as a fully trusted employee.

This guide provides an implementation approach for teams connecting agents to Microsoft 365, Google Workspace, or GitHub.

Define the job before choosing permissions

“Connect the agent to our workspace” is not a usable permission requirement. Start with one bounded job and describe it in operational terms.

For example, an agent that summarizes support handoff notes from one shared folder has a defined input and output. It does not inherently require access to every document, mailbox, calendar, or repository. An agent that prepares dependency-update pull requests for selected repositories may need repository access and a proposal path, but it does not need authority to merge to a protected branch.

Document these questions before provisioning credentials:

• What event starts the work?
• Which systems and named resources may the agent read?
• What output may it create or modify?
• Which actions require a human approval?
• What records must be retained for review?

Permissions should implement this job boundary. They should not reflect a general level of trust in a model, vendor, or prompt.

Use a layered permission model

An OAuth scope list alone is not enough. Combine identity, resource scope, action boundaries, workflow controls, and evidence.

Use a dedicated identity

Create an application identity, service account, or GitHub App for an individual agent role. Do not reuse a human account, administrator account, or one shared identity for unrelated automations. A dedicated identity makes permission review and revocation specific to that agent.

Microsoft recommends requesting only the Microsoft Graph permissions an application needs. Its guidance also favors delegated or resource-specific approaches where feasible because broad application permissions can access data without a signed-in user. Microsoft Graph permission guidance is a useful starting point when assessing whether tenant-wide application access is necessary.

For Google Workspace, direct sharing of particular files with a service account creates a narrower resource boundary than domain-wide delegation. Google documents domain-wide delegation as an approach requiring administrator authorization of OAuth scopes for access to user data. Google Workspace credential guidance describes the distinction.

GitHub Apps begin with no permissions and can be installed on selected repositories. GitHub recommends granting only the permissions an app needs. GitHub’s permission guidance provides the relevant configuration model.

Constrain both API scope and resource scope

A narrow-sounding permission can still reach a broad data set. Access to files, for example, may apply to one shared folder, many shared drives, or an entire domain depending on the configuration.

Use explicit resource boundaries in addition to API scopes: selected repositories, approved folders, named calendars, and other defined destinations. Keep those bindings in configuration that can be reviewed with the agent’s purpose. Treat an addition to the allowlist as an access change, not as a prompt change.

Google Workspace administrators can control third-party app access by OAuth client and scope, including controls for high-risk Workspace scopes. Google Workspace app access controls provide a governance point for allowing, restricting, or blocking integrations. Microsoft Entra administrators can restrict or disable user consent, including policies that allow consent only for verified publishers. Microsoft Entra user-consent controls can establish an approval point before an application receives organizational access.

Separate reading from writing

Read access and write access should be separate capabilities. A research agent can collect and summarize information. A proposal agent can create a draft, issue, comment, or pull request. Sending, publishing, deleting, merging, changing permissions, or making purchases should follow a more restrictive path.

This structure limits the effect of an incorrect or unwanted action. It also creates a reviewable boundary between an agent’s recommendation and a consequential system change.

Put approvals at consequence boundaries

Approval should happen immediately before the action with real impact, not only when an integration is installed. A one-time consent decision does not establish that every future message, calendar event, or code change is appropriate.

Have the agent create a reviewable action packet that states the intended action, affected resources, proposed payload, reason, and expiration time. The reviewer should be able to approve, reject, or edit the proposed action. A rejection should stop the action rather than silently retry it with different wording.

For source-code workflows, protected branches provide an enforcement point outside the agent. GitHub branch rules can require pull-request reviews, status checks, signed commits, deployment success, and restrictions on who can push or bypass protections. GitHub’s protected-branch documentation describes these controls. Allow an agent to propose a change through a branch and pull request while preserving the protected-branch process for merging.

Make activity reconstructable

Operate agents with both platform audit events and application-level records. Platform logs show what an identity did. Agent records should capture the task identifier, policy decision, resources considered, approvals received, tools invoked, and outcome.

Microsoft Graph activity logs provide an audit trail of tenant HTTP requests and can be routed to Log Analytics, Storage, or Event Hubs for retention and monitoring. Microsoft also notes coverage for requests from AI clients using its enterprise MCP server. Microsoft Graph activity-log documentation explains the available destinations.

GitHub organization audit logs record who performed an action, what happened, when it happened, and relevant repository context. GitHub also provides audit-log APIs and webhooks that support external retention and event-driven monitoring. GitHub audit-log guidance describes those review paths.

Keep application logs proportionate. Avoid copying entire prompts, documents, or mail bodies into a separate log store by default. Log identifiers, policy decisions, and the minimum evidence needed for review, then apply the organization’s retention requirements.

Test in constrained destinations

Before an agent can affect production resources, give it non-production destinations for external actions. Examples include a test mailbox, isolated calendar, approved folder, non-production repository, or disposable branch namespace.

Use the sandbox to verify that the agent respects allowlists, produces the required review packet, records activity, and stops when policy denies an action. Test normal tasks as well as untrusted or ambiguous content, such as a document that requests unrelated data access or a repository issue that asks for permission changes. Retrieved content should be treated as data to analyze, not as authority to alter the permission contract.

Review and revoke access routinely

Access can become inappropriate as projects, repositories, folders, and ownership change. Maintain an inventory of agent identities and installations, their owners, resource bindings, last activity, and next review date. Remove dormant access rather than retaining it without a current purpose.

When an agent’s job expands, perform a new permission review instead of silently adding scopes. For GitHub Apps, installation scope can be limited to selected repositories, and permissions can be revisited when requirements change. GitHub documents selected-repository installation and permission approval behavior.

Implementation checklist

• Define one bounded job and assign a business owner.
• Create a dedicated agent identity.
• Grant the smallest necessary API scopes and named resource bindings.
• Separate read, draft, and consequential write capabilities.
• Use branches and pull requests for code proposals rather than direct protected-branch changes.
• Require approval for sending, publishing, merging, deleting, spending, or permission changes.
• Record task IDs, policy decisions, tool calls, approvals, and outcomes with minimal sensitive content.
• Use applicable Microsoft 365 and GitHub audit records in the organization’s monitoring process.
• Test the workflow in constrained destinations with normal and adversarial inputs.
• Document revocation steps and schedule access reviews.

FAQ

Should an internal agent use delegated or application access?

Choose the model that fits the job. Delegated access can fit an agent acting within a signed-in user’s authority. Application access can fit unattended work, but it requires careful scoping because it can operate without a signed-in user. Microsoft recommends minimum permissions and favors delegated or resource-specific approaches where practical. Source: Microsoft Graph permission best practices.

Can a GitHub agent have write access?

It can, but limit that access to defined actions in selected repositories, such as creating branches, commits, pull requests, comments, or issues. Keep protected-branch controls and review requirements in place for merging. Source: GitHub protected branches.

Is an approval dialog sufficient for sensitive actions?

No. Approval is one control. Pair it with a scoped identity, restricted resources, bounded write destinations, audit evidence, and a documented revocation path.

What is the first control to implement?

Create a dedicated identity with read-only access to a small, explicitly approved resource set. Require draft output before enabling external write capability.

Sources

• Microsoft: Best practices for using Microsoft Graph permissions
• Microsoft: Access Microsoft Graph activity logs for tenant monitoring
• Microsoft: Configure how users consent to applications
• Google Workspace: Create access credentials
• Google Workspace: Control which apps access Google Workspace data
• GitHub: Choosing permissions for a GitHub App
• GitHub: About protected branches
• GitHub: Reviewing the audit log for your organization

Editorial note: AI assisted with research and drafting. Sources were selected for verification; a human editor should review this draft before publication.

Mohamed CHAMI

Full-Stack Developer & Solutions Architect · Casablanca, Morocco

7+ years building Java/Spring Boot/Angular enterprise solutions. Former Senior Software Engineer at NTT Data and Satec. Authorized Google Workspace and Microsoft 365 Partner for Morocco.

LinkedIn · GitHub · Contact