Device Operations Bridge: LAPS sessions and password rotation

A technician opens a session on a cloud-managed laptop, runs a remote check, and closes it. The tool reports success. I would still ask two questions: did the password rotate, and did the assistant receive it during the session? Windows LAPS gives access as a local administrator. Calling that access a session does not make the secret disappear.

Figure 1: a session makes the intended use and end state visible, but each client response and close route still needs to be examined.

Start with the secret's audience

The API's Graph-backed service retrieves the device's LAPS credential. The API then builds a session record with the operator, device, expiry, status, and credential, held by the session manager in process memory. Protected HTTP session endpoints apply the configured LAPS role filter. MCP needs a separate look: that HTTP filter is not automatically protection for every tool.

Here the response is the important part. The MCP credential tool returns the actual username and password. The session-start tool also puts the password in its success response, with the session ID and expiry. Both are secret-bearing outputs. The session ID does not stop the client receiving the credential, and an audit event does not redact the response.

Review the client, transcript, diagnostics, telemetry, and retention settings together. Tool results and assistant conversation history are sensitive here. If the selected tool returns the LAPS password to the caller, do not promise that it stays out of model context.

Track where the credential is used

After session creation, the gateway executor can use that LAPS username and password for a WinRM PowerShell remoting connection. Command policy is checked before dispatch. Execution still depends on the network: the device must be online and resolvable from the selected gateway, rules must permit the connection, and WinRM must match the deployment's security posture.

Expiry and a configurable concurrent-access policy use process-local session state. This is not a durable lock shared automatically between instances. Restarts, failover, or running multiple API instances can change what is tracked as active. I would test those cases before writing procedures that depend on the session record being a persistent source of truth.

Rotation depends on the entry point

MCP stop-session checks two things: is auto-rotation enabled, and does another session remain active for this device? With rotation enabled and the final session ending, it can call the Graph service's cloud-LAPS rotation method. That call is best effort. A failed rotation can leave the stop operation successful, with a result saying the password was not rotated.

HTTP stop and stale-session cleanup behave differently in this implementation. They close or expire the tracked session and emit audit events, but they do not call the Graph rotation method. Even an event saying rotation was initiated does not establish that Graph received a request, much less that the device password changed.

So the configuration flag is only the start of the check. Use a non-production device, test the route operators actually use, confirm the required Graph permission, and verify the password update itself. Repeat for manual stop, expiry, and cleanup. Ending the same session record does not mean every route does the same work.

A separate flow for other sensitive values

There is another path for values such as BitLocker recovery keys: the secure vault. It can return a short-lived, one-time link instead of putting the value in the MCP result. The described lifetime is five minutes. Retrieval consumes the entry, and possession of the URL token is the authorization.

That reduces recovery-key exposure in the assistant tool response, but moves the sensitive item to the URL. It is a bearer secret: somebody who obtains it before first use may consume it. Keep the link out of logs, tickets, and forwarded conversations, choose an appropriate short lifetime, and verify storage and expiry in the deployed system. This does not change the MCP LAPS tools; they still return the actual local administrator password.

What to verify before relying on the workflow

1. Choose the intended client path. Confirm whether operators use MCP session tools, REST endpoints, or PowerShell, then test that exact path and its authorization controls.
2. Inspect sensitive outputs. Check API responses, MCP transcripts, diagnostics, telemetry, and command output for credential exposure or accidental persistence.
3. Prove close behavior. With rotation enabled, close the last session on a test device and verify Graph's result. Repeat for manual stop, inactivity, and maximum-duration cleanup.
4. Plan for process-local state. Test restart, failover, and multiple-instance behavior; do not treat the in-memory manager as a durable lock service.
5. Test the audit destination. Confirm which events reach Application Insights and whether the optional Service Bus, Function, and SQL route retains them durably.
6. Protect one-time links. Treat vault URLs as bearer secrets and verify their real deployed expiry and one-time consumption behavior.

For me, this workflow earns trust only when scoped roles, a time window, a reachable execution path, and tested cleanup all work together. A missing control is not covered by the others. Report only what the end-to-end test proved: “we requested rotation,” “an audit event was emitted,” and “the password changed” remain three different statements. The paperwork may prefer one status field. The system does not.