Inside Device Operations Bridge: control plane, agents, and gateway

A technician can reach the support API from the cloud, but the target laptop is resolvable only from a branch network. A diagram with one large “cloud” box hides the important questions: where is the operator authenticated, which component can read LAPS data, what crosses the network boundary, and where does the audit event go?

This article uses Device Operations Bridge as the public-facing name for a private implementation. The architecture is easier to reason about as a set of cooperating components with distinct responsibilities: operator clients, an API and shared Core services, Microsoft Graph, an optional network-side gateway, Windows endpoints, and an audit pipeline.

Figure 1: control-plane coordination, network-side execution, and audit persistence are separate responsibilities.

Component responsibilities

Operator clients: several interfaces, one sensitive workflow

The operator surface includes a PowerShell module for direct administration, REST endpoints for application integrations, and MCP tools for compatible assistant clients. An AgentHub can classify a request and route it to a domain-specific agent; a follow-up can remain with the active domain rather than starting from scratch.

These interfaces change how an operation is initiated, not the underlying trust model. A client may request a device lookup or session action, but it should not be trusted to decide its own privilege. Tool results can also include sensitive material, so the client, its transcript, and its telemetry belong in the data-flow review.

API entry: authentication and authorization are separate gates

The .NET API accepts configured authentication mechanisms, including JWT bearer, certificate, and API-key handlers. Authentication identifies or validates a caller according to the selected scheme. Protected HTTP operations can then apply role checks; for LAPS session routes, the relevant roles include LAPS.Admin and LAPS.User.

An API key or valid token is not a blanket grant to read a LAPS password or operate a device. The route's authorization requirements still matter. Nor should a role filter attached to an HTTP endpoint be assumed to secure every MCP tool: the MCP surface needs to be reviewed and configured as its own access boundary.

Shared Core and Graph-backed services: coordinate, do not replace management

Shared Core services provide reusable operations to the API and related components. Graph-backed services retrieve Entra and Intune device information and access cloud LAPS data under the application's Microsoft Graph permissions. The service's permission to call Graph and the human operator's role are different controls: both must be appropriate for the selected operation.

Session management also belongs to the coordination layer. It associates an operator, target device, expiry, status, and credential with an active session. Current session state is held in process memory, so it is volatile and local to the running API instance. It should not be described as a durable database, a cross-instance lock, or a source of historical audit records.

AgentHub and MCP: orchestration is not a privilege boundary

AgentHub can route assistant requests to a domain-specific agent, while MCP exposes selected capabilities as tools. This can make the workflow easier to use, but it does not make broad application permissions safe or remove the need to authorize each sensitive operation.

Some MCP tools return the actual LAPS username and password. In particular, the credential tool returns the credential, and session start can return it along with a session identifier. Audit logging records access; it does not redact returned values. Review the tool's response schema, the assistant transcript, downstream telemetry, and retention settings as one sensitive-data path.

Optional gateway and executor: bridge a network, not a policy gap

The gateway is deployed where it can resolve and reach the Windows devices it serves. It maintains an outbound SignalR connection to the API, registers itself, sends heartbeats, and receives routed command requests. The API can select a connected gateway, including by network segment, and correlate a request with its result.

On the gateway, a PowerShell remoting executor uses the supplied LAPS local account credential to establish a WinRM connection. That gives the service a network-side execution path for devices that the API cannot reach. It does not bypass role checks, make offline devices available, or configure DNS, firewall rules, certificates, and WinRM on the operator's behalf.

The implementation exposes configuration choices for encrypted WinRM and certificate checks. Production deployments should require encryption and certificate validation. Disabling certificate checks to get a successful connection trades away a security control and should not become an undocumented default.

Audit service and optional persistence: events need a destination

Audit handling is separate from both session state and command execution. The audit service keeps recent events in a bounded in-memory cache and can send telemetry to Application Insights when configured. Where persistence is enabled and Service Bus is available, events can be queued, consumed by an Azure Function, and written to SQL.

The queue/function/database route separates durable storage from the synchronous command path, but it is optional. The in-memory cache is bounded and disappears with the process; telemetry delivery or persistence failures do not necessarily fail the user's operation. If the organization needs durable investigation records, it must enable, monitor, and test the persistence path. “An event was emitted” and “an immutable record was retained” are not the same statement.

Follow one operation across the components

1. An operator client supplies a device identifier and requests an operation.
2. The API authenticates the caller and applies the authorization checks for that entry point.
3. A Graph-backed service reads the required device or LAPS data; the session manager records the bounded session context in process memory.
4. If remote execution needs a network-side route, the API selects a connected gateway and sends the request over SignalR.
5. The gateway uses WinRM to reach a resolvable, reachable Windows endpoint and returns the execution result.
6. API and gateway events flow to the audit service; configured telemetry and persistence destinations handle them separately.

The sequence makes it easier to place controls where they belong. Graph permissions govern the service's data access; API or MCP authorization governs who can request an operation; network and WinRM controls govern whether execution can reach a device; and audit configuration governs what evidence remains.

Optional components and the capability they add

Component	When it is needed	What its absence means
AgentHub	Assistant request routing is useful	PowerShell or direct API workflows can remain independent
Network gateway	The API needs a network-side route for remote execution	No gateway-mediated WinRM path is available
Service Bus, Function, and SQL	Audit events must be durably persisted	Only configured cache/telemetry behavior is available; do not promise durable audit storage

The table describes capability boundaries, not a recommendation to remove controls. A deployment should include only the components needed for its support model, while verifying the security and operational consequences of each choice.

Operational boundaries to verify

• Identity and roles: test each authentication route and the role claims expected by the protected operation.
• Graph permissions: grant only the read and rotation permissions that the chosen workflows require.
• Gateway scope: confirm heartbeat, network-segment routing, device name resolution, and firewall policy from the gateway itself.
• WinRM posture: require encryption and certificate validation; document any exception explicitly.
• Audit retention: test persistence delivery, alert on failures, and define retention beyond the in-memory cache.
• Assistant clients: treat tool inputs, outputs, and conversation history as part of the sensitive-data boundary.

This is a modular topology, not a promise that every component can be omitted without consequence. PowerShell users can work without AgentHub; a deployment that does not need gateway-mediated execution can omit the gateway; and durable audit requirements call for the queue/function/database path. Each component has a clear owner, a boundary to protect, and a failure mode to test. That is a much more useful design review than a single box labelled “cloud.”