Why an AI agent changes the security boundary

A Copilot agent does more than generate text. With generative orchestration and a Model Context Protocol server, it can read resources, select a tool and trigger an action. The trust boundary now includes the user, agent, model, knowledge sources, MCP client, MCP server, downstream APIs and the identities used at every step.

In Copilot Studio, tools and resources published by an MCP server become available to the agent, and server-side changes are reflected dynamically. This flexibility is valuable, but it turns a description, schema or authorization change on the MCP server into a production change. Agent instructions alone are therefore not a security control.

Start with a risk and decision matrix

Classify every tool before connecting it. Read-only document search does not carry the same impact as a tool that creates accounts, sends email, changes a firewall or deletes a backup. Controls should match actual impact, not the reassuring name given to an agent.

Risk	Example	Primary control
Prompt injection	A document tries to trigger a tool	Separate data from instructions, limit tools, validate arguments
Excessive privilege	Token can access every file	Minimal scopes and progressive elevation
Destructive action	Delete or send without review	Human confirmation and dual control
Secret leakage	API key appears in prompt or logs	Secret vault, redaction and rotation
Server drift	A new MCP tool is exposed automatically	Versioning, approval and regression testing
SSRF	Controlled URL targets an internal service	Allowlist, egress proxy and private-range blocking

1 — Give every agent and user a distinct identity

Avoid a shared service account that makes every action indistinguishable. For an action performed on a person’s behalf, use user authentication and preserve that identity through the target system. For autonomous work, use a distinct workload or agent identity with its own permissions and lifecycle.

Microsoft Entra Agent ID extends identity and governance mechanisms to agents. Conditional Access can evaluate user and agent access requests before a token is issued. Features, licensing and availability can evolve, so validate them in your tenant before creating a production dependency.

One business owner and one technical owner per agent.
Separate identities for development, test and production.
No Global Administrator account or permanently privileged role.
Certificate, managed identity or vault-stored secret; never place credentials in instructions or public variables.
Disable identities when the agent, owner or use case is retired.

2 — Prefer OAuth and per-user authorization over shared keys

Copilot Studio supports no authentication, API keys and OAuth 2.0 for an MCP server. A shared key can suit a tightly limited lab, but it does not represent the user and makes revocation, attribution and least privilege difficult. Prefer OAuth with precise scopes for enterprise data and actions.

The MCP 2025-11-25 authorization specification requires OAuth 2.1 for authorization servers, protected-resource metadata discovery, PKCE for clients and the resource parameter to bind a token to its intended MCP server. The server should validate issuer, audience, expiry, scopes and, depending on the design, the user or agent identity.

Minimal protected-resource metadata example

{
  "resource": "https://mcp.example.ca/mcp",
  "authorization_servers": [
    "https://login.microsoftonline.com/<tenant-id>/v2.0"
  ],
  "scopes_supported": [
    "mcp.tools.read",
    "mcp.tools.execute-approved"
  ]
}

3 — Forbid token passthrough and minimize scopes

Token passthrough means accepting a token intended for another resource and forwarding it unchanged to a downstream API. MCP security guidance calls it an anti-pattern and the authorization specification forbids it. An MCP server must accept only a token issued for its own audience. If it calls another API, it should obtain a separate token for that API.

Begin with a low-risk read scope. Request targeted elevation only when a user attempts a privileged operation. Avoid broad scopes such as full-access, admin:* or wildcards that give a stolen token a disproportionate blast radius.

Operation	Suggested scope	Confirmation
List or search	mcp.tools.read	No, when data is already authorized
Create a draft	mcp.tools.draft	Based on classification
Send or publish	mcp.tools.publish	Yes
Change configuration	mcp.tools.change	Yes, with impact summary
Delete or revoke	mcp.tools.destructive	Yes, ideally dual approval

4 — Design narrow, deterministic and server-validated tools

A secure tool performs one precise task with a strict input schema. Prefer create_ticket over execute_api_request, or get_device_status over run_powershell. The more generic a tool is, the more room the model has to assemble an unexpected action or bypass business intent.

Validate every argument on the server even when Copilot Studio already has a schema. Allowlist domains, commands, recipients, object types and value ranges. Reject unknown fields, enforce size limits, normalize paths and authorize every call again.

Separate read and write tools.
Make repeated operations idempotent with a request key.
Limit pagination, result size and execution time.
Return structured errors without stacks, secrets or internal data.
Version tool names, descriptions, schemas and scopes.

5 — Require human confirmation for high-impact actions

Copilot Studio tools have an Ask the end user before running option, and it is off by default. Enable it for sending, publishing, configuration changes, transactions and deletion. Confirmation should show the final action, target, transmitted data and expected impact; a generic Continue button offers limited protection.

For critical operations, add out-of-band approval or a second role. The agent can prepare the change, but an authorized person should approve it in ServiceNow, Power Automate Approvals or the business system before execution.

6 — Apply DLP policies and separate environments

In the Power Platform admin center, connectors can be classified as Business, Non-business or Blocked. Copilot Studio enforces these policies in real time. Administrators can require authentication and block selected knowledge sources, HTTP requests, connectors used as tools, publishing channels and autonomous triggers.

Microsoft notes that blocking Power Platform connectors also blocks tools from connected MCP servers because the connectivity relies on connectors. Use dedicated environments and appropriate policies: restrictive development, representative testing and production with approved connectors and endpoints only.

Block Chat without Microsoft Entra ID authentication for internal agents.
Use endpoint filtering for approved websites, SharePoint locations and HTTP calls.
Separate business connectors from personal or public connectors.
Restrict autonomous triggers until the scenario has passed controlled production testing.
Apply sensitivity labels and supported Purview policies to data.

7 — Isolate the MCP server and control network egress

Treat an MCP server as a privileged API. Put it behind a gateway or reverse proxy, enforce TLS, rate-limit requests and expose only the required path. The process should not run as root, write into its image or access the Docker socket.

MCP clients and servers that retrieve URLs need SSRF defenses. MCP guidance recommends blocking private, loopback, link-local and cloud-metadata ranges unless explicitly needed, validating every redirect and considering an egress proxy. String or DNS-name validation alone is not sufficient.

Example constraints in compose.yaml

services:
  mcp:
    image: registry.example.ca/agents/mcp-server:1.4.2
    read_only: true
    user: '10001:10001'
    cap_drop: [ALL]
    security_opt:
      - no-new-privileges:true
    pids_limit: 128
    mem_limit: 512m
    cpus: 1.0
    tmpfs:
      - /tmp:rw,noexec,nosuid,size=64m
    secrets:
      - mcp_client_secret

secrets:
  mcp_client_secret:
    file: /secure/path/mcp_client_secret

8 — Treat local MCP servers as executable code

A local server launched over stdio executes on the user’s workstation and can access files, environment variables and credentials. Do not install an MCP package merely because it appears in a repository or an agent recommends it. Verify the publisher, code, dependencies, image provenance and updates.

Pin versions and image digests, generate an SBOM, scan vulnerabilities and sign artifacts. For enterprise use, prefer a managed remote service or strongly isolated local execution over arbitrary commands added to every workstation configuration.

9 — Log decisions without copying secrets

Every tool call should be attributable to an agent, version, user or autonomous identity, and authorization decision. Preserve a correlation ID across Copilot, the MCP gateway and downstream API. Do not log tokens, API keys, passwords or full prompt content by default.

Microsoft Purview records Copilot Studio activities and makes them available in Audit; Microsoft 365 also provides logs for Copilot interactions and administrative activities. Configure transcript retention and access separately because transcripts can contain personal or operational information.

Useful fields for a tool-call audit event

{
  "timestamp": "2026-08-23T13:10:00Z",
  "correlation_id": "7f0d...",
  "agent_id": "helpdesk-prod",
  "agent_version": "2026.08.3",
  "principal_id_hash": "sha256:...",
  "tool": "create_service_request",
  "authorization_decision": "allowed",
  "scope": "mcp.tools.draft",
  "result": "success",
  "latency_ms": 284
}

10 — Govern the lifecycle through the admin centers

The Microsoft 365 admin center can enable, disable, assign, block or remove agents, while Agent Registry provides a central view. Use restricted groups for pilots, review permissions and data access, then expand only after validation.

Publication is not the end of control. Regularly review owners, users, tools, OAuth scopes, secrets, dependencies, DLP policies, logs and costs. Immediately remove a deprecated tool or a server whose provenance can no longer be verified.

Recommended four-phase deployment plan

Phase	Actions	Exit criterion
Design	Map data, identities, tools and impact	Owners and risk matrix approved
Lab	Read-only, synthetic data, injection and authorization tests	No critical bypass
Pilot	Small group, confirmations, DLP and logging	False positives and incidents controlled
Production	Targeted scopes, monitoring, rotation and quarterly review	SLA, incident response and retirement documented

Official references and related reading

As of August 2026, agent, Entra Agent ID and governance capabilities are evolving quickly. Verify prerequisites, licensing and preview status in your tenant before production deployment.

About the author

Marc-Antoine Lambert

Montréal-based senior IT consultant and Team Lead specializing in architecture, cybersecurity, Microsoft infrastructure, networking and business continuity.

Discuss your environment →