Map your controls to MisterShell.
A reference for security and compliance teams: how MisterShell’s capabilities support the control families your audits assess. It speeds your evidence-gathering — it is not a compliance attestation.
How to read this
MisterShell is self-hosted: you run it under your own controls, and your data, sessions, and credentials stay in your environment. MisterShell is not itself a certified product. The mapping below shows where its capabilities support the controls auditors assess — to shorten evidence-gathering, not to claim compliance. Several mapped capabilities are edition-gated: enterprise sign-in and multi-core high availability come with the Pro edition, and the policy engines with session recording come with Enterprise (see pricing). References are indicative; confirm scope and applicability with your auditor.
Identity & access control
Single sign-on via SAML, OIDC, or LDAP with directory-group-to-role mapping (MFA enforced by your IdP, and authenticator-app or email MFA enforced by MisterShell for local and LDAP sign-in); a maximum sign-in duration that activity does not extend, and administrator-set maximum lifetimes for API keys and SSH keys; role-based access scoped to locations, seeded with built-in roles for common responsibilities; access approvals that require a human decision before a privileged session or file transfer begins, kept as evidence; credentials that require each person's own login, so actions on the target stay individually attributable; firewall-style session policy and per-command ACLs that stop unauthorized commands before they reach the target.
Logging, audit & monitoring
Session Policy writes an audit trail of accept/deny decisions — per rule, with who, what, and where — and every access approval request and decision is kept in its own evidence timeline; the AI audit trail correlates every agent run, model request and tool call with actor, origin, timing and outcome; Review keeps fleet-wide Health and Compliance timelines; full session recording and replay (terminal, RDP, VNC, web) kept as immutable operational evidence in your own object store — each recording SHA-256 hashed at capture, the hash held apart from the recording and verified on replay — with capture, destination store, and retention set per session class by Recording Policy (route by data residency; retain per policy); security, policy, API and AI-metadata events exported to your SIEM via syslog (RFC 3164, RFC 5424, CEF) or webhook (JSON or Splunk HEC).
Cryptography & data protection
Self-hosted with no SaaS control plane — your data stays in your environment; credentials and secrets encrypted at rest and in transit, with secret fields masked in the UI; recordings stored in an object store you own. File-catalog stores mount onto the location tree, so attaching a regional bucket to a location keeps files for the resources beneath it in that jurisdiction — residency follows your topology rather than depending on operators choosing the right destination.
Network security & segmentation
Outbound-only workers connect out over HTTPS — no inbound firewall rules into protected zones, and resources are never exposed to the public internet through MisterShell; deploy workers per site or segment to match your network policy; file transfers are brokered by the worker nearest the resource, so a managed system never reaches an object store directly and no new egress path is opened, with an ordered File Transfer Policy enforcing which files may move in which direction between the catalog and a resource; SSH host keys strictly verified by default, with any change requiring explicit acceptance, for live sessions and background checks alike; optional passive IDS sensors attributed by resource and location.
Availability & resilience
MisterShell deploys active/active: multiple cores self-cluster into one mesh where every core serves traffic and an elected leader orchestrates scheduling exactly-once, so the loss of a core is absorbed automatically with no single point of failure in the application tier. Session recordings replicate across the cluster and finalize to your object store. MisterShell also ships scheduled database backups and a validated single-core restore through its operator console. The same model extends active/active across regions for geographic resilience.
Scope: MisterShell makes its own application tier highly available and, by design, leverages the managed load balancer, database, and cache you already operate rather than duplicating platforms your team already runs. Their high availability and failover are yours to operate (MisterShell backs up its own database on a schedule; it does not run yours), as is the object store durability that preserves recordings. This maps the availability of the access platform itself, not a business-continuity program for your whole estate.
Configuration change tracking
Configuration snapshots with structured diffs and a timestamped changelog, each change attributed to its author whenever one can be identified — so unexpected or unauthorized changes are detected and attributable.
Scope: MisterShell provides change detection and an attributable record, and can author and push standardized configuration from reusable templates — and, wired to Fact Policy and automation, run a detect-and-remediate loop in which a push can be gated behind a human Approve step. It is not a full change-management system, nor a turnkey config-baseline compliance suite with canned CIS/PCI/NIST libraries; pair it with your change-management process or a dedicated NCCM where those are required.
Operational state assurance (continuous checks)
Fact Policy turns the operational facts MisterShell collects into continuous compliance checks: declare an intent — NTP synchronized, an approved software version running, an expected route present — and every in-scope resource is verified against its actual collected state on each snapshot, producing a pass/fail result tracked over time as a compliance heatmap at fleet, location, and resource scope. A status change can raise an automation event and write a security-log entry for your SIEM.
Scope: this verifies operational state against your declared intent — continuous detection and evidence, not configuration-baseline auditing of running-config text. Fact Policy itself changes nothing on a device; remediation is a separate, explicit step — a Compliance Violation event can drive an automation playbook that renders and pushes a configuration stack, with every push recorded — and that playbook can pause on a human Approve step before anything is pushed. Pair it with your change-management process for what lies beyond that.
AI governance
Interactive AI assistance runs under the invoking user’s permissions and location scope; background automation agents are constrained by agent type and per-agent tool restrictions; external agent platforms act as a signed-in user through your own identity provider, with exactly that user’s permissions. All AI is limited to the tools you grant, read-only by default per resource type, and rate-limited. Every chat, agent run, model request and tool call — external agent calls included — is correlated into one AI audit trail with actor, model, tool and outcome, and a metadata-only stream can be forwarded to your SIEM. Bring your own LLM; nothing is sent to a provider until an agent is invoked.
These are management frameworks rather than technical control IDs — MisterShell’s attribution, least-privilege, and human-oversight controls support an auditable AI governance program.
How MisterShell itself is built
A platform on the privileged path should hold itself to the discipline it enforces.
- 27,000+ automated tests. They cover the backend, UI and workers, including 2,000+ integration and end-to-end tests. Over 85% of the codebase is covered.
- Every change gated by CI. Lint, the unit suite and a dependency audit run on every change before it merges.
- Weekly CVE review of the dependency chain. Critical and high findings are evaluated every week, and fixes ship in minor releases, each one traceable in the changelog.
- Regular AI-assisted security reviews. The codebase is reviewed for vulnerabilities and insecure patterns with the latest frontier models from Anthropic and OpenAI.
Control identifiers reflect SOC 2 (AICPA TSC), ISO/IEC 27001:2022 Annex A, NIST SP 800-53 Rev 5, PCI DSS v4.0, and CIS Controls v8 as of 2026. This mapping is provided for guidance, speeds evidence-gathering, and does not constitute a compliance attestation, certification, or legal advice. Validate scope and applicability with your auditor.
Get in Touch
Want a guided demo, or a trial license to evaluate Pro or Enterprise on your own infrastructure? Tell us — we'd love to hear from you.