Secure Use of Coding Agents

Microsoft has published security guidance for coding agents like GitHub Copilot CLI, recommending layered controls including sandboxing, least privilege, and separation of duties. The guidance emphasizes that no single approval prompt is sufficient and outlines best practices for balancing developer velocity with containment and supervision.

General best practices for balancing developer velocity with containment, supervision, and least privilege. Note Product capabilities and preview status reflect publicly available guidance as of August 24, 2026. Note Scope This guidance uses GitHub Copilot CLI as its primary implementation surface. GitHub Copilot cloud agent is covered separately because its hosted execution model provides different controls. VS Code and other clients may use different settings and terminology; they are referenced only where the underlying security principles align. Desktop agents embedded in business applications and Microsoft Foundry-hosted agent architecture are outside the core scope. Executive Summary executive-summary Risk Model risk-model 1. Start with Sandboxing 1-start-with-sandboxing 2. Use Tool Permissions While Reducing Approval Fatigue 2-use-tool-permissions-while-reducing-approval-fatigue 3. Enforce Separation of Duties and Minimize Authority 3-enforce-separation-of-duties-and-minimize-authority 4. Use JIT/PIM and Conditional Access for Privileged Operations 4-use-jitpim-and-conditional-access-for-privileged-operations 5. Recommended Operating Patterns 5-recommended-operating-patterns 6. Governance, Audit, and Recovery 6-governance-audit-and-recovery 7. Baseline Checklist 7-baseline-checklist References references Coding agents like GitHub Copilot can read files, run commands, call tools, modify code, and interact with external systems. Their effective authority is determined by the environment, credentials, tools, and network access exposed to them. No single approval prompt or safety classifier is sufficient. Organizations should layer controls in this order: Enforce separation of duties. Standard developer accounts should not have elevated access to production systems. Development, deployment, and privileged administration should use separate identities and authorization paths. Contain the execution environment. Use a local or cloud sandbox to restrict filesystem, network, credential, and subprocess access. Minimize downstream authority. Expose only scoped, short-lived credentials and identities appropriate to the task. Apply deterministic tool policy. Remove unnecessary tools, deny dangerous operations, and pre-approve narrowly defined benign operations. Use contextual and human approvals. Allow low-risk work to proceed with minimal friction while escalating consequential actions for review. Design for audit and recovery. Record what acted, with which permissions, and how resulting changes can be reverted. The practical goal is to make agents powerful inside a narrow, recoverable environment rather than powerful because they inherit a developer's full access. Separation of duties limits the authority and potential consequence of an agent action; sandboxing provides the primary runtime containment boundary for the work itself. Important Separation of Duties The strongest protection for production is that the developer identity used by the agent has no production authority to begin with. If a user must be eligible for elevated access, keep that privilege inactive by default and require a separate JIT/PIM activation protected by Conditional Access, approval, and automatic expiration. Treat a coding agent as automation operating with whatever access is exposed to it. Depending on its configuration, an agent may be able to: - Read or modify files available to the current user. - Run shell commands and developer tools. - Reuse cached CLI, browser, Git, SSH, or cloud credentials. - Reach internal services available from the developer's network. - Call Model Context Protocol MCP servers and other external tools. - Push code, create pull requests, deploy software, or modify external systems. Three independent control planes address different parts of this risk: | Control plane | Question answered | |---|---| | Sandbox | What can the agent technically reach? | | Tool permissions | What actions may the agent attempt? | | Identity and access controls | What will downstream systems authorize? | Each control plane addresses a different failure mode. A sandbox can still contain powerful credentials. A tool allowlist can still authorize a broadly privileged tool. Strong downstream RBAC does not prevent an agent from damaging local files. | Control source | Examples in this guidance | Applicability | |---|---|---| | GitHub Copilot CLI | Local and cloud sandboxing, tool permissions, managed settings, optional hooks | GitHub-native; command names and settings are CLI-specific | | GitHub Copilot cloud agent | Ephemeral GitHub Actions environment, repository and branch scope, pull-request controls, firewall, session logs | GitHub-native hosted controls | | GitHub Actions | OIDC federation, protected environments, workflow approvals | GitHub-native CI/CD controls | | Identity and resource platforms | RBAC, JIT/PIM, Conditional Access, OAuth delegation | Product-specific implementations of portable identity principles | | Organization-wide architecture | Separation of duties, short-lived credentials, audit, recovery, gateway policy | Vendor-neutral; applies across cloud and on-premises systems | Sandboxing should be the primary safety boundary. Tool approvals and safety classification are defense-in-depth controls applied inside that boundary. GitHub Copilot local sandboxing https://docs.github.com/en/copilot/concepts/about-cloud-and-local-sandboxes local-sandboxing uses Microsoft eXecution Container MXC to restrict commands and tools running on a developer's machine. Local sandbox policy can control: - Read-only, read/write, or denied filesystem paths. - Internet and local-network access independently. - Availability of Git and GitHub CLI credentials. - Whether local MCP and language servers run inside the sandbox. - Keychain access on macOS. - Per-command exceptions for work that must run outside the sandbox. Without local sandboxing, shell commands run with the access of the signed-in user. They can generally read, modify, or delete anything the user can, reach the same networks, and reuse available credentials. Local sandboxing is lighter-weight operating-system containment rather than a separate virtual machine or container. Built-in Copilot CLI file tools run in the CLI process and enforce the configured policy themselves on a best-effort basis. Remote MCP servers are not contained by the local sandbox; their own authorization and policy remain separate concerns. Enterprises can require sandboxing and enforce its configuration through managed settings. See Configuring local sandbox settings https://docs.github.com/en/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings . GitHub Copilot cloud sandboxing https://docs.github.com/en/copilot/concepts/about-cloud-and-local-sandboxes cloud-sandboxing runs a Copilot CLI session in an isolated, GitHub-hosted Linux environment built on Azure Container Apps Sandboxes. Cloud sandboxes provide stronger separation from the developer workstation and its ambient credentials. They are well suited to: - Autonomous or long-running work. - Untrusted repositories or dependencies. - Parallel development tasks. - Compute-intensive workflows. - Work that does not require local-only systems or credentials. Cloud sessions are isolated from the local machine and from other sessions. A session can be stopped and later resumed from a snapshot, or deleted with its saved state. Sandboxing does not automatically make downstream access safe. Any credentials introduced into the sandbox must still be scoped, short-lived, and appropriate to the task. GitHub Copilot cloud agent https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent is distinct from a Copilot CLI cloud sandbox. It performs delegated repository work in an ephemeral development environment powered by GitHub Actions and returns changes on a branch for review. GitHub provides several native controls around this workflow: - Copilot can modify only the repository specified for the task and works on one branch at a time. For a new task, it normally writes to a generated copilot/ branch and remains subject to branch protections and required checks. Broader read access can be introduced through MCP and must be governed separately. - Draft pull requests require human review. Copilot cannot mark its pull request ready, approve it, or merge it, and the user who requested the pull request cannot approve it. - By default, GitHub Actions workflows do not run on Copilot-authored changes until a user with write access selects Approve and run workflows . - Internet access is restricted by a configurable firewall with a recommended allowlist. - Agent work is attributed through signed commits, the initiating user is recorded as co-author, and session logs expose the agent's work. - Cloud agent uses dedicated Agents secrets and variables rather than inheriting Actions, Codespaces, or Dependabot secrets. Secrets prefixed with COPILOT MCP can be limited to configured MCP servers. Cloud agent is a strong choice when the intended output can be reviewed as a branch and pull request. Introduced credentials and external tools still require independent controls. The cloud-agent firewall https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-the-firewall applies only to processes started through the agent's Bash tool inside the GitHub Actions appliance; it does not contain MCP servers or processes started in setup steps and is not a complete exfiltration boundary. See Risks and mitigations for GitHub Copilot cloud agent https://docs.github.com/en/copilot/concepts/agents/cloud-agent/risks-and-mitigations and Configure secrets and variables for Copilot cloud agent https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/configure-secrets-and-variables . | Situation | Recommended environment | |---|---| | Interactive work requiring local resources | Local sandbox with explicit path, network, and credential policy | | Autonomous or higher-risk work | Cloud sandbox | | Untrusted dependencies or generated commands | Cloud sandbox or stronger container/VM isolation | | Access to sensitive internal systems | Local sandbox with separate authentication context and minimal network reach | | Production administration | Human-controlled privileged environment rather than a general coding-agent session | GitHub currently documents cloud and local sandboxes as preview capabilities, with portions of the Copilot CLI experience still marked experimental. Organizations should validate platform support and isolation behavior against their requirements. Approval fatigue is itself a security risk. If developers must repeatedly approve benign operations such as file listing and repository searches, they are more likely to approve consequential actions without meaningful review. The goal should be: Do not make developers approve grep ; make them approve crossing a trust boundary. GitHub Copilot CLI tool controls https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools provide two distinct policy layers: | Layer | Purpose | |---|---| --available-tools and --excluded-tools | Control which tools the model can see and select | --allow-tool and --deny-tool | Control which selected tools can execute without prompting | Deny rules take precedence over allow rules and previously saved approvals. Permissions can target broad tool types, exact tools, or command patterns. Saved approvals for shell, file, MCP, and memory operations can be scoped to a repository or working directory. Organizations should prefer narrow allowlists and explicit denies over blanket approval. If the model cannot see an unnecessary tool, it cannot attempt to use it. GitHub calls the unrestricted tool permission setting Approve all . In Copilot CLI, --allow-all and its alias --yolo combine three separate bypasses: all tools are approved, all paths are allowed, and URL verification is disabled. In the GitHub Copilot app, /allow-all-tools turns on tool auto-approval and /yolo is an alias for the same command. Approve all should not be permitted in routine developer or enterprise-managed sessions. It removes the user prompt for every tool invocation, including commands with external, destructive, or privileged side effects. If an exceptional workflow genuinely requires pre-approved tools, define a narrow allowlist and run it inside a disposable sandbox with no unnecessary credentials or network access rather than enabling Approve all. Enterprise administrators can enforce this with the permissions.disableBypassPermissionsMode https://docs.github.com/en/copilot/reference/enterprise-administrators/enterprise-managed-settings managed setting: { "permissions": { "disableBypassPermissionsMode": "disable" } } This disables bypass or YOLO-style allow-all behavior in Copilot CLI, VS Code, JetBrains IDEs, and the GitHub Copilot app. It does not apply to Copilot cloud agent. Enterprise managed settings can be distributed through server-managed configuration, MDM, or a protected machine-level file; see Configuring enterprise-managed settings https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/configure-enterprise-managed-settings . Common read-only discovery operations can usually proceed without prompting when they are constrained to an approved workspace: - List files inside the repository. - Search repository content with built-in search tools, grep , or rg . - Read files inside approved paths. - Inspect Git status, history, and diffs. - Query local metadata that does not expose credentials or sensitive external data. The same command may carry different risk in a different context. Reading the current repository may be benign; reading a home directory, credential store, mounted share, or unrelated source tree is not. Tests and build commands should not automatically be classified as read-only. Package scripts, build hooks, and test fixtures can execute arbitrary code, access networks, and modify state. They become safer when executed inside a constrained sandbox without sensitive credentials. Human approval should remain the default for: - Access outside approved filesystem paths. - Network access to a new domain or internal system. - Writes outside the repository. - Protected-branch changes. - Package installation or execution of untrusted scripts. - MCP tools or CLI commands that mutate external systems. - Sending email, messages, or other external communications. - Deployments and infrastructure changes. - Access to secrets, credentials, or privileged sessions. - Destructive, irreversible, or difficult-to-recover operations. Some operations should be denied entirely in general coding-agent sessions, even if a human could approve them. Examples include broad production administration, exporting credentials, bypassing security controls, and mass destructive actions. GitHub Copilot hooks https://docs.github.com/en/copilot/reference/hooks-reference can add deterministic decisions or telemetry beyond the built-in sandbox and permission controls. Start with sandboxing, built-in tool permissions, and downstream least privilege, then consider hooks where those controls leave a specific gap. A preToolUse hook can inspect the tool name and arguments, then allow, deny, modify, or return permissionDecision: "ask" to explicitly require user approval. For Copilot CLI, administrators can install machine-wide policy hooks that load before user and repository hooks and cannot be disabled by the user. Hooks are useful for controls such as: - Requiring approval before deployment, external writes, or network access. - Denying commands that target protected production environments. - Restricting tools to approved filesystem paths or argument patterns. - Recording tool requests and policy decisions in an external audit system. Hooks introduce policy code that must be owned, versioned, tested, deployed, and monitored. They also add processing to tool calls and can introduce latency or reliability dependencies, so keep them narrow and fast and use them where the additional control justifies the operational cost. Hooks operate alongside sandboxing and downstream authorization. Command-hook failures deny a preToolUse request, but hook timeouts fall through to the normal permission flow. In Copilot cloud agent, an "ask" decision is treated as "deny" because no interactive user is available. Some GitHub Copilot clients expose an experimental Assisted permission mode between Always ask and Approve all : | Mode | Behavior | |---|---| | Always ask | Prompt before running tools that require approval | | Assisted | Automatically approve requests an LLM safety check considers safe; prompt otherwise | | Approve all | Run tools without prompting | In Assisted mode, a separate LLM judge assesses permission requests. Requests judged safe may execute automatically. Requests involving side effects or unresolved risk prompt the user and can include the judge's reason. Availability, naming, and exact behavior vary by client and should not be assumed to match Copilot CLI conventions. AI security in VS Code https://code.visualstudio.com/docs/agents/run/security documents one Assisted-permissions implementation and explicitly notes that model-based risk assessments can make mistakes. Treat this as corroborating security guidance rather than as the source of Copilot CLI configuration. Use Assisted approval to reduce routine prompts, not to authorize risk. Its LLM safety judgment can be incomplete or incorrect. Deterministic deny rules, sandbox policy, and downstream least privilege must continue to enforce the actual security boundary. | Action category | Default treatment | |---|---| | Repository-local, deterministic read | Pre-approve | | Context-dependent but recoverable operation | Prompt by default; use client-specific Assisted assessment only as defense in depth | | External side effect or persistent mutation | Explicit human approval | | Privileged, destructive, or policy-bypassing action | Deny or move to a separate controlled workflow | Sandbox and tool policy limit what an agent can attempt. Downstream identity and authorization determine what succeeds. Regular developer accounts should not have standing elevated permissions to production systems. This is good practice independently of coding agents, but it becomes more important when an agent can reuse the developer's terminal, browser, CLI, or cached credentials. Separate identities and authorization paths should be used for: - Day-to-day development. - Pull-request validation and build automation. - Non-production deployment. - Production deployment. - Privileged production administration. An agent operating as a normal developer should be structurally unable to administer production. Tool approvals then protect lower-risk boundaries instead of acting as the last defense against a production incident. If production access cannot be removed from the developer population entirely, grant eligibility rather than standing access. Require a separate privileged account or authentication context, JIT/PIM activation, Conditional Access, explicit approval, a short activation window, and automatic expiration. Do not activate production privilege in the same agent-controlled terminal or browser context. | Scenario | Preferred identity model | |---|---| | Interactive work that genuinely requires user context | Delegated user identity with least privilege and a constrained session | | CI/CD or deterministic automation | Dedicated workload identity using federation | | Hosted or managed agent | Dedicated agent identity with explicit RBAC | | Privileged human operation | Separate privileged context using just-in-time activation | User delegation, workload identity, and agent identity solve different problems. They should not be collapsed into one broadly privileged service account or user token. When an interactive tool genuinely needs to act in the user's context, prefer delegated OAuth with narrow scopes and resource-bound access tokens. For HTTP-based MCP servers, the MCP authorization specification https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization treats the MCP server as an OAuth resource server and requires the client to request a token for that specific resource. If the MCP server or another middle tier must call a downstream API, it should obtain a separate token for that resource through an on-behalf-of or standards-based token-exchange flow when the identity platform supports it. Do not replay a token issued for the MCP server to a different API. Do not pass raw user tokens through the tool chain or expose them to model context. The downstream API must still apply the user's delegated permissions and its own authorization policy. Microsoft Entra's OAuth on-behalf-of flow https://learn.microsoft.com/entra/identity-platform/v2-oauth2-on-behalf-of-flow is one implementation of this pattern. For app-only automation, use a workload or agent identity instead; OBO is intended to preserve a user principal's delegated context, not to convert application authority into user authority. Directly invoked CLI tools and locally launched stdio MCP servers sit outside the HTTP OAuth flow described above. They commonly discover credentials through environment variables, configuration files, keychains, credential helpers, local agents, or cached login sessions. A shell invocation of tools such as gh , az , aws , kubectl , or terraform can therefore modify an external system with the user's authority even though no MCP tool is involved. Govern these tools through Copilot CLI tool availability and approval policy, sandbox restrictions on files, credentials, and network access, and authorization at the target system. Prefer narrowly scoped, short-lived credentials or workload federation over ambient login state, and keep privileged CLI sessions outside the agent-controlled environment. For CI/CD and hosted automation, prefer workload identity federation over long-lived secrets, personal access tokens, or user credentials. An effective pattern maps trust boundaries to separate identities: - Pull-request validation uses a read-only identity. - Merge or release workflows use a different identity with narrowly scoped write access. - Non-production and production environments use separate identities and RBAC assignments. - Production federation is restricted to approved repositories, branches, tags, environments, or workflow claims. GitHub Actions supports OpenID Connect https://docs.github.com/en/actions/concepts/security/openid-connect so workflows can exchange a job-specific OIDC token for a short-lived cloud access token without storing cloud credentials as GitHub secrets. Cloud trust policy must constrain which repository, workflow, branch, tag, or protected environment may receive access. See Configuring OpenID Connect in cloud providers https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-cloud-providers . Azure DevOps supports workload identity federation for Azure service connections https://learn.microsoft.com/en-us/azure/devops/pipelines/library/connect-to-azure?view=azure-devops . Comparable federation patterns can be used across clouds, including federating Azure DevOps into AWS https://aws.amazon.com/blogs/modernizing-with-aws/how-to-federate-into-aws-from-azure-devops-using-openid-connect/ . Federation removes stored secrets. The federated identity must still have only the permissions required for its workflow and environment. Managed agent platforms can assign an identity to the agent rather than requiring it to operate entirely as its requesting user. Microsoft Foundry agent identities https://learn.microsoft.com/azure/foundry/agents/concepts/agent-identity provide an identity framework for authenticating and authorizing agents with Microsoft Entra ID. Agent identity makes activity easier to govern and attribute, but each tool and downstream resource must still enforce appropriate RBAC. See Least privilege for AI agents https://learn.microsoft.com/security/zero-trust/sfi/least-privilege-for-ai-agents . Just-in-time access and Conditional Access are complementary controls. They should not be treated as interchangeable. Just-in-time JIT access is the principle that privileged permissions should be activated only when needed and removed automatically after a limited period. Microsoft Entra Privileged Identity Management https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-configure implements this model for supported Microsoft Entra, Azure, group, and Microsoft service roles. PIM distinguishes between: Eligible access: The identity may request or activate a role. Active access: The role is currently usable. Standing access: The role remains permanently active. Activation can require justification, approval, MFA, ticket information, notifications, and a maximum duration. The objective is to reduce the number of identities with continuously active privilege and to create an auditable activation event. Microsoft Entra Conditional Access https://learn.microsoft.com/entra/identity/conditional-access/overview is the Zero Trust policy engine that determines whether access is allowed and which conditions must be satisfied. Conditional Access can evaluate signals such as: - User or workload identity. - Target application or resource. - Device state and compliance. - Network or location. - Sign-in and user risk. - Authentication method or strength. Policies can require MFA, stronger authentication, compliant devices, approved locations, or block access entirely. Microsoft also supports Conditional Access for workload identities https://learn.microsoft.com/entra/identity/conditional-access/workload-identity . | Control | Question answered | |---|---| | JIT/PIM | When and for how long may this identity become privileged? | | Conditional Access | What conditions must be satisfied to authenticate or activate access? | | Tool approval | Has this specific agent action been approved? | | Sandbox | Can the agent reach the target or credential at all? | A common privileged-access flow is: - The user has no standing administrative access. - The user requests JIT activation. - Activation requires justification, approval, and Conditional Access checks such as MFA or an approved device. - Privilege is granted for a limited period. - Elevated access expires automatically and the activity is audited. For agent-assisted work, elevation should ideally occur in a separate, human-controlled context. Activating a privileged role inside the same terminal, browser profile, or environment controlled by the agent may expose the elevated token to the agent. Conditional Access is generally evaluated during authentication, token acquisition, or resource access rather than before every individual command. Once a valid token is available in an agent-accessible environment, repeated MFA prompts should not be assumed to protect each operation. - Enable local sandboxing. - Limit filesystem access to the repository and required tooling. - Block local-network and broad internet access unless needed. - Ensure the standard developer identity has no elevated production permissions. - Keep privileged credentials and keychain access outside the sandbox. - Pre-approve repository-local read and search operations. - Require approval for writes outside the repository and external side effects. - Use branches and pull requests rather than direct protected-branch changes. - Prefer a cloud sandbox or stronger isolated environment. - Do not inject broad developer credentials. - Limit repositories, tools, network access, and secrets to the task. - Use short-lived credentials where external access is required. - Make generated changes reviewable and easy to discard. - For Copilot cloud agent, retain the default pull-request and workflow approval controls and keep its firewall enabled. - Use a dedicated federated workload identity. - Separate identities by environment and capability. - Restrict federation claims to approved repositories, branches, tags, or environments. - Require deployment approvals and protected environments. - Avoid long-lived secrets and personal credentials. - Log the workflow, identity, authorization scope, and resulting changes. - Keep privileged access outside routine developer accounts and agent sessions. - Use JIT/PIM instead of standing roles. - Apply Conditional Access and strong authentication. - Require explicit human approval before destructive operations. - Use short activation windows and automatic expiration. - Maintain a tested rollback path. Organizations should maintain an inventory of: - Approved coding agents and execution environments. - Available built-in tools, CLI tools, and MCP servers. - Identities and credentials exposed to each environment. - Repositories, networks, and downstream systems each agent can reach. - Persisted tool approvals and policy exceptions. A complete inventory usually combines platform records with configuration-as-code, endpoint management, identity governance, and observability data. This is necessary to cover local coding agents, custom agent definitions, MCP servers, hosted agents, and downstream identities. GitHub provides several complementary views: - Enterprise AI controls currently show active and recent agent sessions, with a searchable view covering sessions from the previous 24 hours. - The enterprise audit log records agent activity on GitHub. Filtering with actor:Copilot returns agentic events with actor is agent: true , an agent session id , and the initiating user. - Copilot cloud agent session logs show the tools used, changes made, and validation performed. Copilot-authored commits link back to the originating session log. - GitHub audit logs also record changes to Copilot policies, licenses, coding-agent enablement, firewall rules, and MCP configuration. These records do not provide complete centralized auditing for local Copilot client activity. GitHub's enterprise audit log does not include locally submitted prompts or all local tool calls. User-delegated actions against GitHub or another service may also be attributed primarily to the authenticating user unless the service receives and records agent context. Where detailed local auditing is required, use policy hooks or OpenTelemetry to send selected session and tool events to an approved logging platform. Preserve session or trace identifiers in deployment and change metadata when possible. Review telemetry privacy carefully because prompts, tool arguments, file paths, and outputs may contain sensitive content. See Monitoring agentic activity in your enterprise https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/monitor-agentic-activity , Audit log events for agents https://docs.github.com/en/copilot/reference/enterprise-administrators/agentic-audit-log-events , and Managing agent sessions https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents/manage-and-track-agents . Some organizations also route supported model, agent, MCP, or tool API traffic through a customer-managed AI gateway. A gateway can provide a shared enforcement and telemetry point for authentication, model allowlists, rate limits, token quotas, content controls, prompt and completion logging, and per-consumer usage metrics. An AI gateway observes only traffic that passes through it. It cannot see local filesystem operations, shell commands, direct tool calls, or managed SaaS traffic that cannot be rerouted, so OpenTelemetry or hooks may still be needed. Organizations should document which traffic is covered, avoid duplicating sensitive content across telemetry systems, and apply redaction, access control, and retention policy to gateway logs. This is a vendor-neutral architectural pattern. Azure API Management AI gateway capabilities https://learn.microsoft.com/azure/api-management/genai-gateway-capabilities are one implementation example, covering model APIs, remote MCP servers, A2A agent APIs, authentication, policy, token metrics, and interaction logging. Microsoft's Cloud Adoption Framework also recommends using an AI gateway as a centralized agent-management control point https://learn.microsoft.com/azure/cloud-adoption-framework/ai-agents/integrate-manage-operate operate-ai-agents . Microsoft Foundry-hosted agent architecture is beyond the scope of this document. However, Foundry and Azure Monitor illustrate useful governance patterns for organizations operating a broader agent estate: Foundry Control Plane https://learn.microsoft.com/azure/foundry/control-plane/how-to-manage-agents provides a subscription-level inventory across Foundry agents, Azure SRE Agent, Logic Apps agent loops, and registered custom agents. The inventory can include source, project, version, status, identity, usage, health, and cost. Foundry tracing https://learn.microsoft.com/azure/foundry/observability/how-to/trace-agent-setup sends model calls, tool calls, ordered run steps, and conversations to Application Insights. Azure Monitor agent observability https://learn.microsoft.com/azure/azure-monitor/app/agents-view can analyze OpenTelemetry from Foundry, Copilot Studio, third-party agents, and supported coding agents. Coding-agent dashboards https://learn.microsoft.com/azure/managed-grafana/grafana-opentelemetry-app-insights provide a cross-agent pattern for monitoring sessions, models, tool use, cost, latency, errors, and selected approval activity. These capabilities are optional examples, not prerequisites for the baseline controls in this document. Some are in preview, and capturing prompts or tool details introduces data-governance and privacy obligations. Audit records should make it possible to answer: - Which human, workload, or agent identity performed the action? - Which agent, model, tool, and arguments were involved? - Which permissions were active at the time? - Which approval or policy decision allowed the action? - What changed, and how can it be reverted? Persisted approvals, non-human integrations, federation rules, and privileged-role eligibility should be reviewed periodically. Exceptions should have an owner, rationale, scope, and expiration. - Coding-agent commands run in an approved sandbox. - Filesystem and network access are limited to the task. - Copilot cloud agent retains branch, pull-request, workflow-approval, and firewall controls. - Standard developer accounts have no standing elevated production permissions. - Privileged and unrelated credentials are unavailable to the agent. - Unnecessary tools are excluded from the model's available tool set. - Approve all and YOLO-style bypass modes are prohibited through permissions.disableBypassPermissionsMode . - Benign repository-local operations are pre-approved. - External side effects require human approval. - Destructive and policy-bypassing tools are denied. - GitHub Actions and other CI/CD systems use federated workload identities instead of stored secrets. - Delegated tools use resource-bound tokens and token exchange rather than replaying user tokens across services. - Identities and RBAC are separated by environment and capability. - Privileged roles use JIT/PIM and automatic expiration. - Conditional Access protects sensitive authentication and activation flows. - Agent actions, approvals, identities, and resulting changes are auditable. - Recovery and rollback procedures are documented and tested. About cloud and local sandboxes for GitHub Copilot https://docs.github.com/en/copilot/concepts/about-cloud-and-local-sandboxes Configuring local sandbox settings https://docs.github.com/en/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings About GitHub Copilot cloud agent https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent Risks and mitigations for GitHub Copilot cloud agent https://docs.github.com/en/copilot/concepts/agents/cloud-agent/risks-and-mitigations Customizing or disabling the firewall for GitHub Copilot https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-the-firewall Configure secrets and variables for Copilot cloud agent https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-cloud-agent/configure-secrets-and-variables Allowing and denying tool use https://docs.github.com/en/copilot/how-tos/copilot-cli/use-copilot-cli/allowing-tools Configuring GitHub Copilot CLI https://docs.github.com/en/copilot/how-tos/copilot-cli/set-up-copilot-cli/configure-copilot-cli GitHub Copilot hooks reference https://docs.github.com/en/copilot/reference/hooks-reference Slash commands for the GitHub Copilot app https://docs.github.com/en/copilot/reference/github-copilot-app-reference/slash-commands Enterprise managed settings https://docs.github.com/en/copilot/reference/enterprise-administrators/enterprise-managed-settings Configuring enterprise-managed settings https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/configure-enterprise-managed-settings AI security in VS Code https://code.visualstudio.com/docs/agents/run/security secondary reference; client conventions differ Monitoring agentic activity in your enterprise https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/manage-agents/monitor-agentic-activity Audit log events for agents https://docs.github.com/en/copilot/reference/enterprise-administrators/agentic-audit-log-events Managing agent sessions https://docs.github.com/en/copilot/how-tos/copilot-on-github/use-copilot-agents/manage-and-track-agents OpenID Connect for GitHub Actions https://docs.github.com/en/actions/concepts/security/openid-connect Configuring OpenID Connect in cloud providers https://docs.github.com/en/actions/how-tos/secure-your-work/security-harden-deployments/oidc-in-cloud-providers Model Context Protocol authorization https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization Microsoft identity platform OAuth on-behalf-of flow https://learn.microsoft.com/entra/identity-platform/v2-oauth2-on-behalf-of-flow Use an Azure Resource Manager service connection https://learn.microsoft.com/en-us/azure/devops/pipelines/library/connect-to-azure?view=azure-devops Access Azure DevOps with Microsoft Entra workload identity https://learn.microsoft.com/azure/devops/pipelines/library/add-devops-entra-service-connection?view=azure-devops Federate Azure DevOps into AWS using OpenID Connect https://aws.amazon.com/blogs/modernizing-with-aws/how-to-federate-into-aws-from-azure-devops-using-openid-connect/ Microsoft Entra Privileged Identity Management https://learn.microsoft.com/entra/id-governance/privileged-identity-management/pim-configure Microsoft Entra Conditional Access https://learn.microsoft.com/entra/identity/conditional-access/overview Conditional Access for workload identities https://learn.microsoft.com/entra/identity/conditional-access/workload-identity Agent identity concepts in Microsoft Foundry https://learn.microsoft.com/azure/foundry/agents/concepts/agent-identity Least privilege for AI agents https://learn.microsoft.com/security/zero-trust/sfi/least-privilege-for-ai-agents