Microsoft integrations

Use Microsoft services from FabrCore agents, or expose FabrCore agents to Microsoft clients. Enable each integration independently.

FabrCore remains a standalone platform with other providers and integrations. Its runtime exposes APIs and WebSocket connectivity; login, consent and administrative user interfaces belong in an external application. Vulcan365 Insights is one cloud administration implementation.

Microsoft Foundry and Azure OpenAI

Microsoft Foundry (formerly Azure AI Foundry) is Microsoft's platform for models and agents. FabrCore's Azure provider uses AzureOpenAIClient to call an Azure OpenAI deployment. This lets a FabrCore workflow use an Azure OpenAI model managed through Foundry while FabrCore manages its own agent lifecycle, conversations and tools.

In ModelConfigurations, set Provider to Azure, Uri to the Azure OpenAI resource endpoint, Model to the deployment name and ApiKeyAlias to the configured credential alias. Use the resource endpoint supported by Azure OpenAI, not a Foundry project URL. See the model configuration examples.

This is model-deployment integration. FabrCore does not currently provide a dedicated Foundry Agent Service adapter or automatically import Foundry agents, tools, policies or project state. Foundry catalog availability does not imply that every model is compatible with the Azure OpenAI provider. Validate the selected deployment and required capabilities.

Microsoft's Foundry overview explains the current naming and resource model. For FabrCore's implementation, see the chat client service.

Choose the packages you need

FabrCore.Connections supplies public contracts and client tooling. FabrCore.Services.Connections supplies the host broker, protected grants and APIs. FabrCore.Services.RemoteAgents adds handle-addressable Studio and Work IQ conversations. Register only the required services and set their Enabled options. EntraAgentIdEnabled and ClientHandoffEnabled are independent opt-ins.

Start with the host setup, configure a principal-owned connection and consent, and deploy a connectedAgents blueprint. A binding does not grant access by itself: the connection profile must allow the deployed full agent handle.

Where Work IQ fits

Work IQ is an API surface for Microsoft 365 intelligence. FabrCore can consume its tools through existing MCP and plugin HTTP support, or expose its A2A conversation through a remote agent handle. The shared connection broker supplies the reusable consent, identity and token lifecycle for those calls. A dedicated Work IQ tool runtime is unnecessary.

Copilot Studio and Work IQ

Remote agents run behind ordinary FabrCore handles. A user and that user's agents share the remote handle's conversation. Cross-principal callers are rejected. Context is stored in normal FabrCore agent state and survives failover when the host has durable storage. Changing endpoint, provider, connection binding, or authorization resets that context.

• provider = work-iq uses A2A 1.0, streaming by default. Set streaming = false for synchronous send. Configure the delegated Work IQ resource scope api://workiq.svc.cloud.microsoft/WorkIQAgent.Ask. Work IQ uses delegated permissions; an app-only Graph registration is not a substitute.
• provider = copilot-studio uses Microsoft.Agents.CopilotStudio.Client 1.3.171-beta. Set endpoint to the published agent's direct-connect URL and resource base URL to its HTTPS origin/path. Configure delegated https://api.powerplatform.com/CopilotStudio.Copilots.Invoke consent. FabrCore does not treat inbound Studio A2A support as proof of outbound Studio A2A support. This adapter uses the Studio client SDK.
• Work IQ tools can also use authenticated MCP or ordinary plugin HTTP calls. No dedicated Work IQ tool runtime is required. Configure the resource scopes from the current Work IQ permission reference for the chosen endpoint.

Work IQ replies retain structured artifacts in AgentMessage.Data. Streaming progress is delivered as _remote-progress messages; Studio typing uses _status. Work IQ task/context IDs persist as updates arrive. Send message types _remote-task-status, _remote-task-resume, or _remote-task-cancel to inspect, subscribe to, or cancel the current task. _remote-reset starts a fresh local conversation binding; it does not cancel provider execution. Nonterminal tasks return _remote-task and task metadata. Timeouts are not automatically retried; inspect a known task before deciding whether to send again. No task ID can be recovered when a provider request was accepted but no response arrived.

Optional Entra Agent ID

Ordinary application registrations and user OAuth do not need Entra Agent ID. When separately enabled, configure:

• Authentication = AgentIdApplication or AgentIdOnBehalfOf;
• ClientId and CredentialReference for the agent identity blueprint;
• AgentIdentityClientId for the provisioned child agent identity;
• BlueprintAudience for the blueprint API in the delegated case.

The implementation obtains the parent's exchange token with fmi_path set to the child, then uses that token as the child's client assertion. Delegated mode also requires a validated human assertion targeting the blueprint API. The client obtains that assertion interactively, then submits it using ConnectAssertionAsync(new(connectionName, userAssertion)). Conventional OnBehalfOf uses the ordinary app's credential and incoming API audience instead. OBO refresh uses a resource refresh token if the provider issues one; otherwise the client must provide a current assertion. There is no fallback to app-only permissions after a delegated denial.

This is a protocol implementation behind FabrCore's SDK facade, not automatic Entra directory provisioning. Blueprint/identity creation, consent, sponsors, tenant governance, and directory lifecycle remain external administrative steps. The credential-provider extension supports integrating additional Microsoft identity tooling. Agent ID compatibility with each target Microsoft API must be validated in the target tenant; it is not implied by supporting the exchange.

Validation and current boundaries

Automated coverage includes disabled registration, principal isolation, explicit application grants, bounded HTTP destinations, token redaction, protected Orleans persistence, conditional profile updates, stale client rejection, handoff owner proof/replay/tampering, OAuth wire exchanges, and Work IQ stream/task parsing. No real Microsoft/Google tenant credentials were used for validation. Deployment requires tenant consent and live smoke tests for login, renewal, Studio, Work IQ, and any selected Agent ID combination. Provider-side revocation and consent remain provider operations; disconnect here clears FabrCore's local authorization.

References: Work IQ A2A, Work IQ API, Entra Agent ID, Microsoft Agents SDK, OAuth client credentials.