Sessionwright

Security at Sessionwright: read-only by default, every change approved and logged

How Sessionwright stays safe: a runner you host, read-only collectors, signed approvals for every change, rollback and a tamper-evident audit log.

Book an assessmentSee how it works

Summary

No customer data reaches us

In v1 the runner lives in your environment and has no connection to Sessionwright at all.

No inbound connections

The runner only calls out: to the platforms it manages, your model endpoint and your SIEM.

Credentials stay in your vault

They are resolved inside collectors and the executor, never placed in a prompt, a tool result or a log.

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.

What data stays where

Where each kind of data lives and whether it leaves your network
DataWhere it livesLeaves your environment?
Credentials and secretsYour vault: Windows DPAPI, Azure Key Vault or HashiCorp VaultNever
Inventory snapshots and raw evidenceRunner storage in your environmentNo
Findings and reportsRunner storage in your environmentOnly if you choose to share a report; secrets are redacted first
Chat and plan narrativesYour model endpointRedacted findings go to the endpoint you choose, when you use chat or narratives
Audit logRunner, append-only and hash-chainedOnly to the SIEM you configure
Anything sent to SessionwrightNot applicableNothing, in v1

Credentials, by platform

Read-only first. Write identities are separate, scoped, and fetched just in time by the executor.

Read and write identities per platform
PlatformRead-only (default)Write (only when enabled)
Citrix Virtual Apps and DesktopsService account (gMSA) with the Read Only Administrator roleA scoped custom role for maintenance mode and messages; disruptive changes use a separate identity checked out from your vault
Citrix DaaSRead-only Citrix Cloud API clientA separate, scoped API client with a short-lived secret
NetScalerNITRO user bound to a show-and-stat command policyAn upgrade account from your vault, used only in the window; never nsroot
Azure Virtual DesktopDesktop Virtualization Reader, Reader, Log Analytics ReaderScoped operator roles, or PIM-eligible assignments activated for the window

Platforms named here: Citrix® Virtual Apps and Desktops, Citrix DaaS, NetScaler® ADC and Gateway, and Azure Virtual Desktop.

Every action has a tier

  1. T0Read

    Examples: Inventory, findings, metrics, logs, NITRO show and stat

    Gate: Allowed. Results are redacted and labelled as untrusted data.

  2. T1Low-risk write

    Examples: Save the NetScaler config, drain a host with no sessions, create a disabled scaling plan

    Gate: Plan, dry-run and one approval. Automatic rollback available.

  3. T2Disruptive write

    Examples: Firmware upgrades, failover, reboots with users on them, image updates

    Gate: Change Approver, optional second approver, change window, backup, staged rollout, health gates, rollback.

  4. T3Never

    Examples: Deleting catalogs or host pools, arbitrary shell, credential export

    Gate: Not in the catalog. There is no way to request it.

Approvals the model cannot forge

The executor accepts only an Ed25519-signed approval token that names the plan, its hash, the approver, their role, an expiry and the change window. Tokens are minted through the CLI or console after a person signs in, with a key the model process cannot read. Before each step the executor checks the token again, along with the live state, because time has passed since the dry-run.

Prompt-injection defenses

Machine names, session client names, descriptions and log lines can all carry hostile text. The design assumes they will.

  • Findings are computed by rules, so injected text cannot create or suppress a finding.
  • Environment data reaches the model only inside tool results, JSON-encoded and labelled as untrusted.
  • Free-text fields are truncated and stripped of control and zero-width characters.
  • The agent that reads environment data has no outbound tools: no web, email or webhooks.
  • Actions bind to object IDs from the snapshot, never to free-text targets.
  • Approvers sign the structured plan rendered by the executor, not the model's prose.

Bring your own model endpoint

Sessionwright uses Claude through the endpoint you choose: your organization's Claude seats through the Claude Code or Claude Desktop plugin, your own Anthropic API key, or Claude in Microsoft Foundry. Your provider's terms govern that data. Under Anthropic's Commercial Terms, customer content is not used to train models.

Source: Anthropic Commercial Terms

Firmware and vendor terms

We never host, cache or redistribute NetScaler firmware; you download it with your own entitled account. Sessionwright uses documented vendor APIs only: no scraping, no undocumented endpoints, no reverse engineering.

Compliance status, stated plainly

SOC 2
On the roadmap. Not started; we will begin when the hosted control plane ships or a customer needs it.
Security whitepaper and questionnaire answers
In preparation. Ask and we will walk you through the architecture.
Penetration test of the runner
Planned before any customer write action.
Insurance (tech E&O and cyber)
To be bound before any customer write action. Until then, engagements are read-only.

Reporting a vulnerability

If you find a security issue in Sessionwright or this website, email hello@sessionwright.com with details. We will acknowledge your report and keep you updated. Please do not test against systems you do not own.

How Nightpatch handles NetScaler upgradesStart with a read-only assessmentPricing

Questions

Does Sessionwright store any of our data?

Not in v1. The runner keeps snapshots, findings and the audit log in your environment. Nothing is sent to Sessionwright.

Who can approve a change?

People you assign in the runner. Operators can approve low-risk actions; disruptive ones need a Change Approver, and you can require a second approver. Roles map to your directory groups.

Are you SOC 2 certified?

No. SOC 2 is on the roadmap. Because the runner is hosted by you and no customer data reaches us, most pilots proceed on an architecture review instead.

Can we keep model traffic inside Azure?

Yes. Use Claude in Microsoft Foundry as the model endpoint, so model calls go through your Azure subscription.

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