Sessionwright

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.

Book an assessmentRead the security overview

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.

Sessionwright v1 architectureThe Sessionwright runner runs inside your environment. It reads Citrix, NetScaler and Azure Virtual Desktop through documented APIs, computes findings with a rule engine, drafts plans, and executes only signed approvals. Model calls go outbound to the endpoint you choose. Audit records go to your SIEM. No connection goes to Sessionwright.Your environmentAdmin workstationClaude Code or Claude Desktop with the Sessionwright plugin, or the runner's local web consolelocal MCP or HTTPS, approvals signed hereSessionwright RunnerWindows service or container. No inbound ports.Collectorsread-onlyRule enginedeterministicFindingswith evidencePlannerdry-run, diffApproval gateEd25519-signed tokenExecutorverify, gate, roll backAudit loghash-chained, append-onlyCredentials stay in your vault (Windows DPAPI, Azure Key Vault or HashiCorp Vault).They never enter a prompt, a tool result or a log.documented APIs onlyCitrix CVAD or DaaSBroker PowerShell SDKCitrix REST APIsNetScaler HA pairNITRO APIread-only command policyAzure Virtual DesktopARM and Log Analyticsleast-privilege RBACYour model endpointYour Claude seats, yourAnthropic API key, or Claudein Microsoft Foundry443 outRedacted findings only, never credentialsYour SIEMSyslog/CEF, Splunk HECor Azure MonitorSessionwright (us)No connection from yourenvironment in v1. No customerdata reaches us.
Everything inside the dashed boundary runs in your environment. The only outbound traffic is to the model endpoint you choose and the SIEM you already run.

The life of a change

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 05

    Verify

    Health gates after each step. Nothing proceeds unless every gate is green.

    You see: Pass or fail per gate, with the evidence.

  6. 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"
}
An audit record, synthetic example. Hashes shortened.

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
For Citrix environmentsFor Azure Virtual DesktopNightpatch for NetScaler

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.

Book an assessmentBecome a design partner