The Part Rewst Gets Right
Let’s start with the steelman. Rewst solves a real problem. Before Rewst (and Liongard, and a handful of similar tools), MSPs had two bad options for cross-tenant PowerShell automation: log in to each client tenant individually and run scripts locally, or build homegrown orchestration with service accounts and a scheduler. Both scale poorly.
Rewst productized the “run PowerShell across N client tenants from one control plane” pattern. It’s good at that. MSPs who adopt it save real hours per week on repeatable actions — user provisioning, license assignment, group management, mailbox configuration.
We are not claiming Rewst is a bad product. We are claiming it’s designed around the wrong axis.
The Part Scripting-First Architectures Get Wrong
A PowerShell script is an execution artifact. You read the code, you run it, you get output.
But a script that adds a user to a Global Admin group isn’t just code. It’s an authorization event that an auditor will want to reconstruct two years from now. A script that resets a user’s password and emails it to a backup address isn’t just code — it’s a compliance event, potentially a legal-hold event, potentially a client-trust event if the wrong address was picked.
Scripting-first automation platforms treat the script as the primary artifact and governance as metadata you add afterward. Execution logs exist; approval workflows exist; redaction features exist. But they’re composed on top, in the MSP’s operational layer, not baked in.
What goes wrong in practice:
- The approval layer is workflow-level, not action-level. Once the workflow runs, the individual actions inside it execute without per-action review. Fine for bulk password resets during a known-to-be-safe event. Less fine if the workflow was wrong in one of its branches.
- Sensitive output in logs is the MSP’s problem. Service account tokens, one-time recovery codes, generated passwords — if the PowerShell emits them to stdout, they end up in the execution log. Redacting them is a cleanup step, not a first-class pipeline concern.
- The audit story is execution-centric, not change-centric. “What PowerShell ran against this client tenant on this day?” is answerable. “Who authorized the privilege change on user X at 3:47 PM” is sometimes answerable, sometimes not — because authorization may have been an implicit outcome of workflow configuration, not a discrete event.
These are not hypothetical complaints. They’re the specific audit questions SOC 2 reviewers, CMMC assessors, and HIPAA auditors ask MSPs who build their operations on top of automation scripts.
Governance-First: What Changes
JieGou’s automation layer starts from a different premise: the client tenant is a governance boundary, and every action crossing that boundary is a reviewable event.
The consequences:
-
Per-action approval, not per-workflow. A job to “reset the CEO’s password and email it to their recovery address” is a single reviewable event. Approver sees the rendered PowerShell, the target tenant, the action’s blast radius, before approval. Per-workflow approval (the Rewst/Liongard model) conflates the review point with the composition point — you approve “this workflow looks fine” once, and then all its individual branches fire.
-
Shadow-mode is a first-class tier, not a workflow variant. Every action can run in shadow mode: the PowerShell is prepared, the inputs are resolved, the output is simulated without calling Microsoft Graph / Exchange / whatever. The MSP operator reviews exactly what would have happened. Only then do they promote to live.
-
Output redaction is built into the runner pipeline. The PowerShell runner captures stdout/stderr, runs it through a redaction pass (removing token-shaped, password-shaped, and other sensitive-shaped strings), and stores only the redacted version to the audit log. The operator sees the redacted version in the UI. The raw output is never persisted.
-
AI-generated actions share the pipeline. This is the meaningful architectural difference. When an AI draft is prepared — whether it’s a PowerShell snippet, a ticket response, or a time-entry write — it enters the same approval queue as human-initiated actions. The MSP operator doesn’t need to separately govern “things AI did” and “things scripts did.” It’s one queue.
-
Emergency override is audited, not undocumented. Sometimes an outage can’t wait. Owner and Admin roles can override a pending approval by supplying a reason. The override action, the reason, the approver identity, and the original request are all preserved. The override exists for emergencies, not as a shortcut.
What It Looks Like Head-to-Head
We published a feature-by-feature comparison on the PowerShell Automation feature page. Summarizing the row that matters most:
Per-action approval. Rewst: workflow-level only; once the flow runs, individual actions fire without per-action review. JieGou: individual action-level — approve or reject each change, with the rendered PowerShell visible.
You can squint and argue these are the same thing if you design your workflows in single-action branches. True. But workflows don’t stay that tidy in a 20-client MSP, and the pressure to compose bigger workflows grows with scale. Per-action approval keeps the reviewable unit at the right granularity.
When Rewst Is Still the Right Call
We’re trying not to pretend JieGou is right for every MSP. Cases where Rewst is still the better fit:
- You’ve already standardized your automation library in Rewst and your team has a year of muscle memory. The switching cost is real.
- Your MSP’s value proposition is “we automate aggressively, governance is a secondary concern.” That’s a defensible positioning. JieGou is for MSPs who want governance to be first-class.
- You need a specific Rewst-native integration that we don’t ship. We cover the common MSP integrations (ConnectWise Manage, Microsoft Graph, Exchange, Intune, Azure AD) but Rewst has a deeper catalog in some niches.
Where We Think the Market Is Heading
The MSP channel is 18 months into the “AI for MSPs” conversation. Two things have shifted:
-
Compliance buyers (MSPs with MSA clauses for SOC 2 evidence) want governance-native automation. Not “we add governance on top.” They want the platform they bought for MSP operations to be the platform that answers the auditor’s questions — same audit log, same approver trail, same redaction.
-
AI-assisted actions are no longer separate from scripted actions in any operational sense. If your MSP’s AI layer drafts a ticket response and your MSP’s automation layer writes the ticket time entry, and both travel through the same client tenant, they want to be one pipeline. Not two pipelines to reconcile.
JieGou is built for those two market shifts. Rewst is not — by design. That doesn’t make Rewst wrong. It makes it a different product for a different MSP.
If that different MSP is you, you should keep using Rewst and the rest of this post is not for you.
If you’re the MSP who wants governance-native, AI-native, audit-native operations — we’d love to show you the pipeline running end-to-end. Book a demo or take the operational bleed audit to see where your current gaps would cost you.