Device Operations Bridge: how the components connect

A technician can reach the support API, but the laptop resolves only from a branch network. Now the large “cloud” box on the architecture slide is not much help. I would want to know where the operator is authenticated, which service can read LAPS data, how the request crosses that network boundary, and where the audit event ends up.

Device Operations Bridge is the public-facing name used here for a private implementation. To understand it, follow the separate pieces: operator clients, the API and shared Core services, Microsoft Graph, an optional network-side gateway, Windows endpoints, and the audit pipeline. They cooperate, but they do not all carry the same responsibility. That matters more than where the boxes sit on the slide.

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

Component responsibilities

Operator clients: several interfaces, one sensitive workflow

Operators have a few ways in. There is a PowerShell module for direct administration, REST endpoints for integrations, and MCP tools for compatible assistant clients. AgentHub can classify the request and send it to a domain-specific agent. A follow-up can stay with that active domain; the operator need not explain the whole problem again.

None of these interfaces gets to choose its own privilege. They change how somebody asks for a device lookup or session action, not the trust model underneath. I would also include the client, its transcript, and its telemetry in the data-flow review: tool results can carry sensitive material beyond the API.

API entry: authentication and authorization are separate gates

The .NET API has configurable JWT bearer, certificate, and API-key handlers. Each scheme identifies or validates a caller in its own way. After that, protected HTTP operations can check roles. The LAPS session routes include checks for LAPS.Admin and LAPS.User.

A valid token or API key is not permission to read any LAPS password or operate any device. The route still has authorization requirements. And an HTTP role filter does not automatically protect every MCP tool. Review and configure MCP as its own access boundary, rather than assuming the work was already done elsewhere.

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

The API and related components reuse operations from shared Core services. Graph-backed services retrieve Entra and Intune device information and access cloud LAPS data using the application's Microsoft Graph permissions. This is where I would keep two questions separate: may the service call Graph, and may this operator request the operation? Both controls must fit the task.

Session management sits here too. An active session ties together the operator, target device, expiry, status, and credential. But the current state lives in process memory, local to that API instance, and is volatile. It is not a durable database, a cross-instance lock, or the place to look for historical audit records.

AgentHub and MCP: orchestration is not a privilege boundary

AgentHub handles routing to a domain-specific agent; MCP makes selected capabilities available as tools. Useful for the operator, yes. Neither makes broad application permissions safe, and sensitive operations still need authorization.

Look carefully at what comes back. The MCP credential tool returns the actual LAPS username and password. Session start can return them too, alongside a session identifier. Logging the access does not redact those values. The response schema, assistant transcript, downstream telemetry, and retention settings therefore need one joined-up sensitive-data review.

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

Put the gateway where it can actually resolve and reach the Windows devices. It opens an outbound SignalR connection to the API, registers, sends heartbeats, and receives routed command requests. The API can choose among connected gateways, including by network segment, and correlate the returned result with the request.

The gateway's PowerShell remoting executor uses the supplied LAPS local account credential to establish WinRM. So there is an execution path from the network side when the API cannot reach the device. There is no bypass of role checks, no way to wake an unavailable device by architectural optimism, and no automatic setup of DNS, firewall rules, certificates, or WinRM.

Encrypted WinRM and certificate checks are configurable. In production, require encryption and certificate validation. Turning checks off to make a connection work removes a security control; do not let that become an undocumented default.

Audit service and optional persistence: events need a destination

Audit has its own path, separate from command execution and session state. Recent events stay in a bounded in-memory cache. Configured telemetry can go to Application Insights. Enable persistence with Service Bus available, and events can also pass through a queue and an Azure Function into SQL.

That queue/function/database route keeps durable storage out of the synchronous command path. It is optional, though. The bounded cache disappears with the process, and a telemetry or persistence failure does not necessarily fail the user's operation. If investigation records must survive, enable, monitor, and test persistence. “An event was emitted” and “an immutable record was retained” are different statements. A checkbox in the design review cannot reconcile them.

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.

Walking through a request like this helps avoid misplaced controls. Graph permissions govern the service's data access, not the operator's entitlement. API or MCP authorization governs the request. Network and WinRM controls determine whether execution reaches the device. Audit configuration decides what evidence remains afterwards.

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

I would use this table to discuss missing capabilities, not to justify removing controls. Deploy what the support model needs, then check the security and operational consequences of leaving the other pieces out.

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.

For me, the useful part of this topology is being able to say what can be left out, and at what cost. PowerShell users do not need AgentHub. A deployment without gateway-mediated execution can omit the gateway. Durable audit requirements need the queue/function/database path. Give each component an owner and test its failure mode. Then the discussion can move past the single box labelled “cloud,” which has already attended enough meetings.