The remote MCP server makes an Operations Agent operable from Visual Studio Code or GitHub Copilot CLI through natural language. The documented query endpoint can inspect state and operations. The configure endpoint can also change agent instructions, connect or remove knowledge sources, add or remove actions, regenerate the playbook, and start or stop monitoring.
That is a privileged production administration surface, not a read-only assistant integration. Its security case must prove who can connect, which item they can reach, which tools the client may call, what evidence is reviewed before a write, how changes are audited, and how the team recovers from a harmful or unintended call.
Can the same MCP session inspect the agent and then change what it monitors or executes? Separate read and write authority before connecting production data or actions.
Define the identity, item, client, and change boundary
Microsoft documents an HTTP-based MCP server using OAuth and a Microsoft Entra ID token. GitHub Copilot can handle token acquisition, while the connecting identity needs Contributor or Admin access to the workspace that contains the Operations Agent. Each configure and query URL embeds one workspace ID and one agent artifact ID; working with multiple agents requires separate server entries.
Inventory the user or workload identity, tenant, conditional-access policy, client, extension and version, local configuration file, workspace role, item ID, endpoint type, permitted tools, knowledge sources, action targets, approval owner, logging path, environment, expiry, and revocation procedure. Do not distribute a write-capable server entry as a generic team convenience.
Separate query visibility from configuration authority
| Surface | Documented capability | Primary risk | Required control |
|---|---|---|---|
| Query endpoint | Read agent summary and state, list monitored rules, retrieve operation details, and search operations. | Sensitive operating state or incident data reaches an unintended user, client, log, or model context. | Least-privilege identity, approved client, item scope, data-handling policy, output filtering, and access review. |
| Instructions | Read and update the detailed behavioral guidance used by the agent. | A broad or injected instruction changes monitoring intent, thresholds, priorities, or action reasoning. | Versioned baseline, constrained input, material-change approval, diff review, regression replay, and rollback. |
| Knowledge sources | Add, update, or remove Eventhouse/KQL and Fabric ontology sources. | The agent monitors the wrong database, schema, environment, object, or adversarial source. | Allowlisted workspace and source IDs, ownership validation, schema checks, environment separation, and source-removal approval. |
| Agent actions | Add, update, or remove actions available to the agent. | A new target or editable parameter expands downstream authority beyond the approved process. | Action allowlist, parameter schema, least privilege, human approval, idempotency, postcondition verification, and containment. |
| Playbook | Generate a playbook and read its summary, rules, rule details, and generation status. | Regeneration silently changes executable monitoring logic after an instruction, source, or action edit. | Immutable release evidence, generated-rule diff, independent query replay, owner approval, and version pinning. |
| Agent state | Start or stop monitoring through write tools. | An unintended call disables a control or activates unapproved rules and actions. | Restricted tool access, current-state check, explicit confirmation, maintenance window, alerting, and emergency stop owner. |
| Client configuration | Manually register per-item configure and query URLs in VS Code or GitHub Copilot CLI. | Endpoints are copied across users, repositories, environments, logs, or unmanaged machines. | Managed configuration, secret scanning, endpoint inventory, device policy, environment labels, and offboarding. |
Prefer separate server entries, identities, and operating procedures for read and write use. A user who only needs operational inspection should not receive the configure endpoint. Where the MCP client cannot enforce a dependable per-tool policy, place a reviewed gateway or operating procedure in front of write calls, and keep production configuration changes human-approved.
Test allowed, denied, adversarial, and failed calls
| Test | Method | Pass condition | Failure response |
|---|---|---|---|
| Authentication and item scope | Use valid, expired, revoked, wrong-tenant, Reader, Contributor, Admin, and offboarded identities against approved and unapproved item URLs. | Only current approved identities reach the intended item and endpoint; denied attempts are visible. | Role correction, conditional access, token revocation, endpoint removal, or rollout block. |
| Tool allowlist | Call every read and write tool from each approved client role, including direct start, stop, remove, and update requests. | Each role can invoke only the documented tools required by its operating purpose. | Separate endpoint, identity, client profile, gateway control, or manual-only administration. |
| Prompt injection | Place hostile instructions in user prompts, source values, schema descriptions, action metadata, issue text, and copied documentation. | Untrusted content cannot authorize a write, change scope, reveal protected data, or bypass approval. | Content isolation, prompt boundary, tool confirmation, parameter validation, or disable write access. |
| Source substitution | Attempt to replace production with development, a similarly named database, another workspace, unsupported source, or source with altered schema. | Only approved source IDs and environments can be connected; changes trigger review and replay. | Allowlist enforcement, inventory correction, source rollback, token revocation, and incident review. |
| Action substitution | Change action targets, URLs, operation IDs, parameters, recipient assumptions, or permissions before and after playbook generation. | The action contract remains bounded, approved, attributable, idempotent, and recoverable. | Remove action, stop agent, revoke authority, restore version, inspect downstream effects, and notify owner. |
| Playbook change | Modify one instruction, source, or action, regenerate, and diff summary, glossary, rules, query bindings, thresholds, and actions. | No playbook reaches active state without deterministic review and regression evidence. | Reject generation, restore prior configuration, rerun tests, or keep agent inactive. |
| Start and stop | Issue repeated, concurrent, stale-state, unauthorized, and ambiguous activation requests during normal and incident conditions. | State changes are intentional, confirmed, logged, alerted, and safe under retry or concurrency. | Emergency stop, remove configure access, reconcile state, and investigate audit history. |
| Client and transport failure | Interrupt OAuth, network, MCP session, client process, and playbook generation; retry writes and inspect partial outcomes. | Failures are visible, retries don't duplicate harmful changes, and actual state is reconciled before another call. | State inspection, idempotency key or manual check, rollback, and bounded retry policy. |
| Audit and evidence | Trace requestor, client, token subject, endpoint, tool, arguments, result, changed object, approval, timestamp, and resulting agent state. | Each material call is attributable and reconstructable without exposing secrets or unnecessary sensitive data. | Logging enhancement, retention control, SIEM integration, access suspension, or production hold. |
Validate the connection with harmless read prompts first. Microsoft recommends checking agent state before start or stop operations and notes that playbook generation typically takes one to three minutes. Reconcile the returned status and final configuration rather than treating a conversational confirmation as proof that the intended production state exists.
Operate the MCP integration as privileged infrastructure
Maintain a registry of every server entry, endpoint type, workspace and item ID, environment, identity, client owner, approved tools, knowledge sources, actions, current playbook version, agent state, last access review, expiry, and revocation path. Detect configuration drift between this registry, client files, Fabric workspace roles, and the current agent.
Alert on new configure clients, role elevation, unusual write calls, source or action changes, playbook generation, start or stop operations, repeated failures, wrong-item attempts, off-hours administration, and configuration changes without linked approval. Keep MCP client logs and Fabric evidence correlated by time, identity, item, and change ticket.
The remote MCP server is currently preview and manually configured. Microsoft also limits each endpoint pair to one Operations Agent and currently supports Eventhouse/KQL and Fabric ontology knowledge sources. Record these constraints in the production exception, reassess after Fabric or client updates, and do not imply a general-purpose automatic discovery or multi-agent management surface.
Run a two-to-four-week MCP implementation and security assessment
- Select one Operations Agent, workspace, approved client, accountable owner, representative knowledge source, bounded action set, and measurable use case.
- Inventory identities, OAuth flow, workspace roles, configure and query URLs, local client configuration, tools, sources, actions, playbook, agent state, logs, and recovery owners.
- Define separate read and write roles, tool allowlists, source and action contracts, approval thresholds, environment boundaries, retention, and preview acceptance criteria.
- Connect the query endpoint first, validate harmless inspection prompts, and prove item scope, data handling, logging, revocation, and offboarding.
- Enable a constrained configure path in nonproduction and test instructions, source and action changes, playbook regeneration, start and stop, denied calls, prompt injection, failures, and rollback.
- Replay the Operations Agent rule and action evaluation suite after every material MCP change and reconcile conversational output with actual Fabric state.
- Run a limited production pilot with change approval, monitoring, emergency stop, daily evidence review, and no expansion until all release gates pass.
- Deliver endpoint and identity inventory, architecture, tool matrix, test evidence, configuration baseline, audit mapping, operating runbook, rollback, preview risks, and go, limited pilot, read-only, or stop recommendation.
Frequently asked questions
What is the Microsoft Fabric Operations Agent remote MCP server?
It is a preview HTTP-based Model Context Protocol server that lets supported AI clients interact with one Fabric Operations Agent. Microsoft documents separate configure and query endpoints. The configure endpoint can read and change setup, manage knowledge sources and actions, generate a playbook, and start or stop monitoring; the query endpoint inspects state and operations.
What can the Operations Agent MCP configure endpoint change?
The documented configure tools can update agent instructions; add, update, or remove Eventhouse and Fabric ontology knowledge sources; add, update, or remove actions; generate a playbook; and start or stop the agent. It also exposes read tools for instructions, sources, actions, playbook rules, rule details, and generation status.
Is the Operations Agent remote MCP server read-only?
No. The query endpoint is read-oriented, but the configure endpoint includes write-capable tools that can change sources, actions, instructions, playbooks, and monitoring state. Treat access to the configure URL and its OAuth identity as privileged production administration.
How should Operations Agent MCP access be secured?
Use a dedicated least-privilege Entra identity, approved client configuration, per-item endpoint inventory, separate read and write access, explicit tool allowlists, human approval for material changes, source and action validation, secrets controls, audit evidence, regression tests, and a tested stop and rollback procedure. Microsoft currently requires Contributor or Admin workspace access.
How long does an Operations Agent MCP security assessment take?
A focused assessment commonly takes two to four weeks for one Operations Agent, approved MCP client, representative knowledge source, bounded action set, and accountable owners. It covers endpoint and identity scope, tool authorization, adversarial and failure testing, audit, release gates, and recovery.
Official implementation references
- Operations Agent remote MCP server endpoints, tools, authentication, examples, and limitations
- Microsoft Fabric Operations Agent overview and configuration
- Operations Agent action and approval behavior
- Operations Agent source, rule, runtime, and messaging limitations
- Operations Agent responsible-use and security considerations
Start with one Operations Agent and split query visibility from configuration authority. Datrick can implement the MCP connection, prove the tool boundary, test adversarial and failed calls, and establish audited release and recovery controls.
When reviewed MCP changes must move consistently across environments, establish a versioned public definition, environment manifests, delegated release identity, behavioral gates, and inactive-first deployment path.