How it works: the agent plans, you approve, it executes, everything is logged
The agent collects read-only data, finds issues and drafts a plan. You approve it, the runner executes in your window, and every step is logged.
A runner in your environment, and nothing in ours
Sessionwright runs as a Windows service or a container that you host. It reads Citrix®, NetScaler® and Azure Virtual Desktop through documented APIs, makes no inbound connections and sends nothing to us.
The life of a change
- 01
Plan
Rules find the problem and attach the evidence. The planner turns findings into a typed plan, bound to real object IDs from your environment, never free text.
You see: The plan, its targets and why each step is there.
- 02
Dry-run
Every action runs its what-if: an ARM what-if, a NITRO read of current state, or a precondition check against Citrix.
You see: The diff, the blast radius in sessions, users and machines, and the approvals it needs.
- 03
Approve
A named person signs the exact plan hash in the CLI or console. Disruptive actions need a Change Approver and can require a second approver.
You see: A signed approval token with an expiry and a change window.
- 04
Execute
The executor checks the signature, the role, the plan hash, the window and the live state again, then runs one step at a time.
You see: Each step as it runs, with its health check.
- 05
Verify
Health gates after each step. Nothing proceeds unless every gate is green.
You see: Pass or fail per gate, with the evidence.
- 06
Roll back
A failed gate runs that action's rollback and halts the plan. Steps that cannot be rolled back are marked before you approve.
You see: What was reverted, and the state it returned to.
Rules find the problems. The model explains them.
Findings come from deterministic code, so they are reproducible and cannot be talked into or out of existence. The language model is advisory.
The rule engine
- Reads a versioned snapshot of your environment
- Produces findings with evidence, expected and observed values, and vendor references
- Gives the same answer for the same snapshot, every time
- Is unit-tested against healthy and faulty fixtures
The language model (Claude)
- Prioritizes findings and writes the narrative
- Answers questions about your environment through read-only tools
- Drafts plans from the action catalog
- Never executes, never holds credentials, never mints an approval
An audit log you can verify
Every record carries the hash of the record before it, so a deleted or edited entry breaks the chain. The runner can recompute the chain on demand, and you can stream it to syslog, Splunk or Azure Monitor.
Two ways to talk to it
Claude Code or Claude Desktop
A Sessionwright plugin backed by a local MCP server. It runs on your organization's own Claude seats.
The runner's web console
Findings, approvals, audit and chat in one place, using your own Anthropic API key or Claude in Microsoft Foundry.
{
"seq": 4812,
"time": "2026-10-17T22:41:07Z",
"actor": "a.okafor (Change Approver)",
"action": "plan.approve",
"plan": "NP-0142",
"planHash": "sha256:5f1c...a09e",
"prevHash": "sha256:9b27...41d3",
"hash": "sha256:c04e...7b18"
}Guardrails
- Blast-radius limits
- One HA node first, one site at a time. A disruptive action cannot target everything without showing the exact count.
- Change windows
- Disruptive actions are refused outside the window you set. A break-glass run needs a second approver and is flagged.
- Four-eyes option
- Require two approvers for internet-facing devices or any action tier you choose.
- Kill switch
- Stop every run on a runner immediately, from the CLI or console.
What it will never do
These actions are not in the catalog at all. There is no path for the model to request them.
- Delete machine catalogs, host pools or virtual servers
- Run arbitrary PowerShell or shell commands
- Export or display credentials
- Disable security features
- Host, cache or redistribute vendor firmware
Questions
Can the AI approve its own changes?
No. Approval tokens are signed with a key the model process cannot read, and they are minted only through the CLI or the console after a person authenticates. The executor rejects anything else.
What stops a malicious string in our environment from steering the agent?
Findings are computed by code, not the model, so injected text cannot create or hide a finding. Environment data reaches the model only as labelled, untrusted tool output; the agent that reads it has no outbound tools; and approvers sign the structured plan, not the model's prose.
Which model does it use?
Claude, through the endpoint you choose: your Claude seats, your Anthropic API key, or Claude in Microsoft Foundry. Findings do not depend on the model at all.
Do we need to open firewall ports?
No inbound ports. The runner makes outbound calls to the platforms it manages, your model endpoint and, if you choose, your SIEM.
Start read-only. Decide with evidence.
A drop-in assessment shows what the agent finds in your own environment, with nothing changed. The fee is credited toward a subscription if you continue within 60 days.