Skip to content

Control 2.17: Cross-Tenant Agent Federation (MCP and Entra Agent ID)

Control ID: 2.17 Pillar: Security & Protection Regulatory Reference: GLBA §501(b), SEC Reg S-P (248.30), FFIEC IT Handbook (Information Security Booklet), OCC Bulletin 2023-17 (Third-Party Relationships: Risk Management), FINRA Rule 3110 (supervisory systems and WSPs) Last Verified: 2026-06-05 Governance Levels: Baseline / Recommended / Regulated

Scope boundary: FSI-CopilotGov vs FSI-AgentGov

This control governs the Microsoft 365 Copilot surface only — tenant-level configuration, data-source posture, audit/eDiscovery, and admin-managed extensibility. Governance of the agents themselves (Copilot Studio agents, declarative agents, Agent Builder, custom pro-code agents) — including agent registration, risk tiering, environment zoning, model-card review, and lifecycle promotion — lives in the companion FSI-AgentGov framework. See Relationship to FSI-AgentGov for the full boundary map.

Objective

Establish governance over Microsoft Copilot agents that are invoked across organizational tenant boundaries — including cross-tenant Microsoft Entra Agent ID trust, Model Context Protocol (MCP) federated server attestation, and Copilot Studio multi-tenant publishing. This control supports compliance with GLBA §501(b) safeguard requirements, SEC Reg S-P (248.30) customer information protection obligations, FFIEC IT Handbook expectations for third-party access governance, OCC Bulletin 2023-17 third-party lifecycle risk management, and FINRA Rule 3110 supervisory systems and WSPs covering external technology relationships.

This control complements (and does not replace) Control 2.16 — Federated Connector and MCP Governance, which addresses single-tenant federated connector enablement, and Control 1.10 — Vendor Risk Management, which addresses internal authoring of Copilot Studio and declarative agents.

Why This Matters for FSI

  • GLBA §501(b) requires safeguards for customer information systems — when a Copilot agent in another tenant retrieves, processes, or returns customer non-public personal information (NPI), the safeguard boundary now extends to that external tenant's identity, attestation, and incident-handling controls
  • SEC Reg S-P (248.30) requires safeguarding customer records and information — cross-tenant agent invocations create a data flow where customer data may leave the firm's tenant boundary via an external agent endpoint that is not under the firm's direct administrative control
  • FFIEC IT Examination Handbook (Information Security Booklet) expects controls over external connections, third-party access, and identity federation — cross-tenant agent trust is a new identity-federation pattern that examiners are beginning to scope under existing third-party access expectations
  • OCC Bulletin 2023-17 (Third-Party Relationships: Risk Management) — which rescinded and replaced OCC Bulletin 2013-29 — requires risk management throughout the third-party lifecycle (planning, due diligence, contract negotiation, ongoing monitoring, termination); each external tenant whose agent is invoked is effectively a third-party data processor that should be evaluated under this lifecycle
  • FINRA Rule 3110 (supervisory systems and WSPs) requires written supervisory procedures covering technology used in regulated activities — cross-tenant agent invocations introduce supervisory gaps if the firm cannot attest to who authored the external agent, what data it accesses, and how its activity is logged
  • Interagency AI Guidance (2023) expects institutions to understand the data sources and provenance behind AI-generated outputs — an agent invoked from another tenant may use models, prompts, knowledge, and tools that are opaque to the consuming firm without explicit attestation

Control Description

Scope: Three Cross-Tenant Patterns

This control governs three distinct cross-tenant agent invocation patterns. All three involve trust crossing an organizational tenant boundary; each requires a different governance treatment.

# Pattern What Crosses the Boundary Primary Trust Anchor
1 Cross-tenant Entra Agent ID trust An agent identity (a Microsoft Entra directory object analogous to a service principal) registered in tenant A is invokable / verifiable from tenant B Microsoft Entra Agent ID object + Conditional Access for agent identities + signed attestation
2 MCP federated server trust attestation An MCP server hosted in (or operated by) another tenant is registered as a tool source for agents in the consuming tenant MCP server signed attestation + connector / endpoint registration
3 Copilot Studio multi-tenant publishing A Copilot Studio agent authored in tenant A is published to and consumed by users in tenant B (ISV, partner, or affiliate distribution); its identity source should be mapped to Microsoft Entra Agent ID where applicable Copilot Studio publishing target list + receiving-tenant admin approval

Distinction from Control 2.16

Control 2.16 governs federated connectors and MCP servers consumed within a single tenant — the trust relationship is internal (admin enables a Microsoft-curated MCP connector for the tenant's own users). Control 2.17 picks up where 2.16 ends: it governs the case where the agent identity, MCP server, or published agent originates in (or terminates in) a different tenant. The two controls are intended to be applied together.

Distinction from Control 1.10

Control 1.10 governs the authoring lifecycle (who may build an agent, what knowledge it may use, approval workflow). Control 2.17 governs what happens when a built agent crosses a tenant boundary at runtime.

Risk Profile for FSI

                Tenant A (External / Partner / ISV)
        ┌────────────────────────────────────────────────┐
        │  Copilot Studio agent  ──┐                     │
        │  Entra Agent ID        ──┼──► (Identity)       │
        │  MCP server            ──┘                     │
        └──────────────────┬─────────────────────────────┘
                           │   cross-tenant invocation
                           ▼
        ┌────────────────────────────────────────────────┐
        │  Tenant B (Firm)                               │
        │  - User / agent invokes external endpoint      │
        │  - Customer NPI may flow outbound in prompt    │
        │  - Response data injected into Copilot context │
        │  - Audit trail must capture remote identity    │
        └────────────────────────────────────────────────┘

Key FSI risks introduced by cross-tenant federation:

  1. Opaque provenance: The consuming firm may not know which model, prompts, or knowledge sources backed the response — recommended to require signed attestation at registration time
  2. Supervisory gap: FINRA Rule 3110 supervisory systems and WSPs assume the supervised technology is observable; a cross-tenant agent's internal behavior is not directly observable to the consuming firm's supervisors
  3. Third-party lifecycle gap: Without explicit registration, cross-tenant agents may be invoked without going through OCC Bulletin 2023-17 due diligence and ongoing monitoring
  4. Identity spoofing risk: Without cryptographic attestation of the remote Agent ID, a malicious or compromised tenant could present an agent identity that the consuming firm has no way to verify
  5. Data residency erosion: A cross-tenant agent may process customer data in regions outside the consuming firm's approved residency boundaries
  6. Termination risk: When the relationship with the external tenant ends, residual trust grants (Agent ID access exceptions, Conditional Access policy exclusions, MCP registrations, published agent installs) may persist if not formally decommissioned

Copilot Surface Coverage

M365 Application Cross-Tenant Agent Federation Exposure Notes
Microsoft 365 Copilot Chat Yes Primary surface for invoking externally-published Copilot Studio agents
Copilot Studio (authoring) Yes Multi-tenant publishing originates here
Microsoft 365 Copilot Agents (declarative) Yes Declarative agents may reference cross-tenant MCP endpoints
Teams (custom agents) Yes Custom agents installed from external tenants
Entra Agent ID directory Yes Agent identities and blueprints are viewed, sponsored, disabled, and audited here
Microsoft Purview (audit) Yes Cross-tenant invocations should appear in unified audit log
Word, Excel, PowerPoint, Outlook Indirect Surfaces inherit any cross-tenant agent the user has installed

Governance Levels

Baseline

Establish minimum visibility into cross-tenant agent relationships before any are formally permitted.

  • Maintain a cross-tenant agent inventory: every Entra Agent ID, MCP server, and Copilot Studio agent that crosses the firm's tenant boundary in either direction (inbound consumed, outbound published)
  • Maintain a trust relationship register that records: counterparty tenant ID, business owner, data classes in scope, registration date, and decommission criteria
  • Perform basic third-party due diligence for each counterparty tenant before enabling any cross-tenant invocation — at minimum, vendor identification, business justification, and a documented owner of record
  • Use Conditional Access policies for agent identities to block unapproved agent access to resources by default; only approved agent identities, blueprints, resources, and counterparty tenants in the trust relationship register should be allowed
  • Document the restriction rationale in governance records and review the register at least annually

This baseline is recommended to provide the minimum visibility examiners expect under FFIEC and FINRA Rule 3110 supervisory systems and WSPs.

Add attestation, approval workflow, and scoped enablement.

  • Require signed Entra Agent ID attestations for any inbound external Agent ID — the counterparty must publish a verifiable attestation of who authored the agent and what data it accesses
  • Implement an MCP server attestation policy: every cross-tenant MCP server registration requires a signed attestation document (publisher identity, data flows, retention, sub-processor list) reviewed by Information Security before registration
  • Implement a Copilot Studio publishing approval workflow for outbound publishing: any agent authored in the firm's tenant that is published to an external tenant requires Compliance, Privacy, and Information Security review, and the destination tenants must be explicitly named and recorded
  • Restrict cross-tenant agent invocation to approved Entra security groups and scoped Conditional Access policies for agent identities or their blueprints; block the broader user population and unapproved agent identities
  • Conduct semi-annual review of all active cross-tenant trust relationships, including usage telemetry and counterparty attestation freshness
  • Map each external counterparty into the firm's third-party risk management program at the appropriate inherent-risk tier

Regulated

Add cryptographic verification per invocation and independent third-party risk review.

  • Enforce cryptographic provenance verification on every cross-tenant invocation — signed Agent ID assertions, MCP server signed responses, and Copilot Studio publishing manifests must be validated at runtime; failed validation must block the invocation and generate a security event
  • Conduct a quarterly trust relationship attestation review: every counterparty re-attests publisher identity, data flows, residency, sub-processors, and incident-response posture; stale attestations trigger automatic suspension
  • Require an independent third-party risk review aligned with the OCC Bulletin 2023-17 lifecycle for every external tenant whose agents process customer NPI or material non-public information (MNPI)
  • Capture full cross-tenant invocation telemetry in the unified audit log and forward to the SIEM with a dedicated detection rule set (anomalous invocation volume, novel counterparty, off-hours invocation, residency mismatches)
  • Include cross-tenant agent inventory, attestations, and review records in examination evidence packages
  • Maintain a decommissioning runbook that revokes Agent ID and Conditional Access exceptions, removes any supplemental cross-tenant access entries, removes MCP registrations, withdraws published agents, and confirms residual data handling within a defined SLA when a counterparty relationship terminates

This level is designed for firms where cross-tenant agent invocation participates in regulated workflows (broker-dealer supervision, banking customer data handling, insurance claims) and where examiners expect formal third-party governance equivalent to vendor onboarding.

Setup & Configuration

Step 1: Build the Cross-Tenant Agent Inventory

Portals: Microsoft Entra admin center > Entra ID > Agents > Agent identities and Agent blueprints; Microsoft 365 admin center > Settings > Copilot; Copilot Studio > Manage > Publishing.

  1. Enumerate every Microsoft Entra Agent ID identity and blueprint registered in the tenant, including whether it authenticates on behalf of a user, with app-only access, or as an agent user account, and identify whether any external tenant can invoke it
  2. Enumerate every MCP server registered as a connector or tool source and identify whether the server is hosted by the firm or by a counterparty tenant
  3. Enumerate every Copilot Studio agent that has been published to one or more external tenants, and every external Copilot Studio agent installed by users in the firm's tenant
  4. Record each finding in the cross-tenant agent inventory with: agent / server identifier, counterparty tenant ID, direction (inbound / outbound), business owner, data classes in scope, and registration date
# Example: enumerate candidate Agent ID service principals (illustrative — verify beta properties in your tenant)
Get-MgServicePrincipal -All |
  Where-Object {
    $_.ServicePrincipalType -eq "Agent" -or
    $_.Tags -contains "AgentId" -or
    ($_.AdditionalProperties -and $_.AdditionalProperties["agentType"] -in @("agenticAppInstance", "agentIdentityBlueprintPrincipal"))
  } |
  Select-Object DisplayName, AppId, AppOwnerOrganizationId, SignInAudience |
  Export-Csv -Path .\cross-tenant-agent-inventory.csv -NoTypeInformation

Step 2: Configure Agent ID Access Controls and Cross-Tenant Allow-List

Portals: Microsoft Entra admin center > Entra ID > Agents > Agent identities; Microsoft Entra admin center > Protection > Conditional Access. Use External Identities > Cross-tenant access settings only for documented B2B / cross-tenant tenant-relationship controls.

  1. Review each agent identity and blueprint; disable identities not tied to an approved owner, sponsor, and trust-register entry

  2. Create Conditional Access policies scoped to All agent identities, selected agent identities, or agent identity blueprints. Start in report-only mode, then enforce block / allow decisions for approved resources. Microsoft provides built-in policy templates in the AI Agents tab of Conditional Access policy templates (Microsoft Entra admin center > Entra ID > Conditional Access > Create new policy from templates > AI Agents): Block high-risk agent identities, Configure policy for autonomous agent access, and Configure policy for on-behalf-of agent access

    Licensing prerequisite: Conditional Access for agent identities requires Microsoft Entra ID P1 (or P2 for risk-based policies) plus a Microsoft Agent 365 license per user. Microsoft Agent 365 reached general availability for the Commercial segment on May 1, 2026. Note that technical enforcement of the Agent 365 licensing requirement within the CA system is in progress ("coming soon" per Microsoft documentation). Organizations should verify current licensing requirements at Conditional Access for agents before deploying these policies in production.

    Agent registry sync (preview): The Registry sync feature in the Agent 365 agent registry (which synchronizes agents from external platforms such as Amazon Bedrock, Google Vertex AI, and Salesforce into the centralized Microsoft 365 agent registry) remains in public preview as of June 2026, while Agent 365 itself is generally available. Organizations should review preview terms before relying on registry sync for production governance workflows. 3. Cover all three access patterns: on-behalf-of user, application-only (app-only) agent access, and autonomous agent access 4. For each permitted counterparty, target only the required resource applications or MCP servers and the minimum required user or agent population 5. If External Identities cross-tenant access settings are part of the approved design, keep default inbound / outbound posture blocked and add explicit organization entries only for counterparty tenants listed in the trust relationship register

Step 3: MCP Server Attestation Registration

For each cross-tenant MCP server registration:

Step Owner Deliverable
1. Business request Requesting department Business justification and intended Copilot use cases
2. Publisher attestation Counterparty tenant Signed attestation document (publisher identity, data flows, residency, sub-processors, retention, incident contact)
3. Information Security review Information Security Attestation validation and risk rating
4. Privacy review Privacy / Legal Data-flow privacy impact assessment
5. Compliance review Compliance GLBA §501(b), Reg S-P, and (where applicable) MNPI handling assessment
6. Third-party intake Vendor Risk Management OCC Bulletin 2023-17 lifecycle intake (planning + due diligence)
7. Register MCP server M365 / Copilot admin Register endpoint with scoped audience
8. Add to monitoring SecOps Add to SIEM detection content and inventory

Step 4: Copilot Studio Multi-Tenant Publishing Controls

Portal: Copilot Studio > Manage > Publishing > External tenants.

  1. Disable open / unrestricted multi-tenant publishing at the tenant level
  2. Require an approval workflow for any agent that is published to one or more external tenants — record each destination tenant ID
  3. For each published agent, document: business owner, knowledge sources, connectors / tools in use, data classes in scope, and the regulatory disclosures shown to consuming users
  4. For inbound consumed agents (agents authored externally and installed by firm users), require admin approval before installation; block end-user self-installation of external agents

Step 5: Audit and Telemetry

Monitor both Copilot activity and Microsoft Entra Agent ID sign-in / audit logs. Agent identity audit events appear as application, service principal, or user events with agentType; sign-ins include agentSignIn and are queryable through Microsoft Graph beta. In Purview unified audit exports, include the MicrosoftEntra workload for agent identity administration and authentication events where available.

# Search the unified audit log for cross-tenant Copilot / Agent activity (illustrative filters)
Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) `
  -RecordType "CopilotInteraction" -ResultSize 5000 |
  Where-Object {
    $_.AuditData -like "*ExternalTenant*" -or
    $_.AuditData -like "*CrossTenant*" -or
    $_.AuditData -like "*AgentId*" -or
    $_.AuditData -like "*AgentIdentity*" -or
    $_.AuditData -like "*MicrosoftEntra*"
  }

# Review Microsoft Entra Agent ID sign-in events (Graph beta, illustrative)
Invoke-MgGraphRequest -Method GET -Uri 'https://graph.microsoft.com/beta/auditLogs/signIns?$filter=signInEventTypes/any(t: t eq ''servicePrincipal'') and agent/agentType eq ''AgentIdentity'''

Step 6: Decommissioning Runbook

When a counterparty relationship ends:

  1. Disable or remove associated Agent ID identities, blueprints, and Conditional Access exceptions; remove any supplemental External Identities cross-tenant organization entries if the approved design used them
  2. Remove or disable any MCP server registration sourced from that counterparty
  3. Withdraw any Copilot Studio agents published to that counterparty's tenant
  4. Notify business owners and end users that the agent is no longer available
  5. Confirm with the counterparty in writing the disposition of any data shared during the relationship (per OCC Bulletin 2023-17 termination expectations)
  6. Update the trust relationship register and retain decommissioning evidence for the firm's record-retention period

Financial Sector Considerations

  • OCC Bulletin 2023-17 lifecycle alignment: Map every external counterparty tenant to the third-party lifecycle phases — planning (use-case definition), due diligence (publisher attestation review), contract (data-handling and incident-response terms), ongoing monitoring (attestation re-validation, usage telemetry), and termination (decommissioning runbook). Cross-tenant agent endpoints are functionally third-party data processors and should not be exempt from the firm's standard third-party governance.
  • FINRA Rule 3110 supervisory systems and WSPs: Update written supervisory procedures to identify cross-tenant agents as a supervised technology surface. Supervisors should have documented procedures for reviewing cross-tenant agent activity, escalating anomalies, and evidencing supervision during examinations.
  • MNPI and customer NPI handling: For workflows where Copilot may include customer NPI or MNPI in prompts to a cross-tenant agent, organizations should confirm that the counterparty's handling controls meet (or exceed) the firm's internal controls. Where they do not, those data classes should be excluded from cross-tenant invocations via DLP and prompt scoping.
  • Information barrier scope: Organizations using information barriers (Control 2.4) should confirm that cross-tenant agent invocations respect those barriers — a cross-tenant agent invoked by a user on one side of an information barrier must not surface data from the other side.
  • Data residency posture: Cross-tenant agents may process data in regions outside the firm's approved residency boundaries (see Control 2.7). The trust relationship register should record each counterparty's processing region, and Regulated-tier policy should fail invocations where the counterparty's region is not on the approved list.
  • Examination evidence: Bank, broker-dealer, and insurance examiners are increasingly asking for inventories of AI agent integrations with external parties. The trust relationship register, attestations, and quarterly review records aid in producing this evidence quickly.
  • Model risk considerations: Cross-tenant agents may use models that have not been evaluated under the firm's model risk management program (Control 3.8). For high-impact use cases, organizations should treat the external agent as an in-scope model and apply proportionate validation.

Verification Criteria

# Verification Step Expected Outcome Tier
1 Review the cross-tenant agent inventory for completeness Every Entra Agent ID, MCP server, and Copilot Studio agent crossing the tenant boundary in either direction is listed with owner and data classes Baseline
2 Confirm trust relationship register exists Register lists every counterparty tenant with business owner, registration date, and decommission criteria Baseline
3 Verify Agent ID Conditional Access and cross-tenant allow-list posture Unapproved agent identities and resource access are blocked by default; only register-listed identities, resources, and counterparties are permitted Baseline
4 Confirm basic third-party due diligence per counterparty Each counterparty has documented vendor identification, business justification, and owner Baseline
5 Validate signed Entra Agent ID attestations Every inbound external Agent ID has a current signed attestation on file Recommended
6 Validate MCP server attestation policy in operation Every cross-tenant MCP server registration is supported by a signed attestation reviewed by Information Security Recommended
7 Confirm Copilot Studio publishing approval workflow Outbound multi-tenant publishing requires Compliance, Privacy, and Information Security review with named destination tenants Recommended
8 Test scoped enablement Users outside approved Entra security groups cannot invoke cross-tenant agents Recommended
9 Verify cryptographic provenance verification on invocation Failed signature validation blocks the invocation and generates a security event Regulated
10 Confirm quarterly trust relationship attestation review All active counterparties have re-attested within the last quarter; stale attestations are auto-suspended Regulated
11 Confirm independent third-party risk review per OCC Bulletin 2023-17 Each counterparty processing customer NPI or MNPI has a current independent review aligned with the lifecycle phases Regulated
12 Test decommissioning runbook end-to-end A simulated counterparty termination removes Agent ID access exceptions, supplemental Entra trust entries, MCP registrations, and published agents within the defined SLA Regulated

Additional Resources

FSI Copilot Governance Framework v1.4 - April 2026