Orchard
Trust & Security
Security & Data Handling
We capture the semantics of work,
not surveillance of people.
A plain-English overview for security and IT leaders evaluating Orchard — what we record, what we will never touch, and how your data stays yours and stays isolated.
The capture boundary
This line is enforced in the agent itself — it is how the product is built, not a policy we promise to keep.
What Orchard records
Enough to understand and replay work.
- Foreground application in focus
- Window title of the active window
- Active vs. idle time
- On-screen control type & label (e.g. "Button — Save")
- The field value needed to replay a recorded action
- Pasted clipboard text during a recording — never password fields
- Endpoint health — hardware, OS, heartbeat
What Orchard never records
By design. There is no setting to turn these on.
- No screenshots or screen images
- No keystroke text — Orchard is not a keylogger
- No passwords by default — password fields are skipped at the source unless you deliberately enable credential capture (below)
The result: Orchard can record a task and let you automate it, without ever imaging the screen or logging keystrokes — and without touching a password unless you turn that on yourself.
Credential capture is opt-in, and encrypted on the device
Some workflows can't be replayed without signing in. For those, and only when you switch the capture dial to its top setting, Orchard captures the credential entered into a login field — so an automation can authenticate on your behalf on another machine. This is off by default, and it is the one setting that reads a password field at all.
When it is on, the design is built so that a captured credential is useless the moment it leaves the device:
- Sealed on the endpoint. The credential is encrypted on the machine that captured it, to a key held in a hardware security module. That machine holds only the public half — it cannot read back what it just sealed, and neither can anything intercepting the network.
- Opened only under audit. A credential is decrypted solely to replay a workflow you authorized, through a key that never leaves the HSM, and every single use is logged where you can see it.
- One key per workspace. Your credentials are sealed to your workspace's own key. Turning credential capture off, or deleting a credential, is immediate.
Screenshots and keystroke logging remain impossible at every tier, including this one.
How your data is protected
Isolation at the database, least privilege at the edges, accountability for the one exception.
Tenant isolation, fail-closed
Every record is scoped to your organization and enforced in the database with PostgreSQL Row-Level Security. If a query arrives without your tenant context, it returns zero rows — never another customer's data. The default is "nothing," not "everything." Your end-clients live inside your tenant as separate client organizations, each with its own scoping and per-client automation controls, while your MSP stays the hard isolation boundary.
Least-privilege access
Your team's console has owner / admin / read-only roles. Agent and enrollment tokens are locked to a single tenant. Logins are rate-limited and timed uniformly to resist account-guessing.
Multi-factor authentication
Every operator can turn on app-based two-factor authentication (TOTP), backed by one-time recovery codes. Owners can require MFA for their whole workspace — anyone not enrolled is walked through setup before they can use the console again. On Orchard's own staff console, MFA is mandatory, not optional.
Our access is the audited exception
Orchard support tooling is a separate system with its own separate credentials and multi-factor authentication, on a database role that can only read tenant data. Every read it makes is written to an immutable audit log — who, what, which tenant, when. The one path that bypasses isolation is fully accountable, never silent.
Encrypted in transit
Traffic between endpoints, the Orchard API, and your console is protected with current TLS. Passwords and tokens are never written to logs.
When Orchard acts on your systems
Automation is the point — so the controls that bound it are built in, not bolted on. You hold the dial: scope what may run unattended, see everything it did, and pull one brake to stop all of it.
You set the autonomy ceiling
Every playbook runs under a trust dial you control. Set it to supervised and every unattended run holds its outward changes for a person to approve — regardless of what the playbook itself says. Tighten it further for an individual end-client. Whoever presses Run is always their own supervisor.
Irreversible steps can be gated
Orchard classifies every action as read-only, reversible, or irreversible — a sent email, a shell command, a driven desktop. Switch on the irreversible-step gate and those are held for human approval before they fire. Anything we can't prove we can undo is treated as irreversible.
Every action is logged — like our staff's reads
Each run, and each step it took — inputs, outputs, outcome — is recorded to a per-tenant history you can review. Operator changes land in an append-only audit trail: who, what, when. The action side is as accountable as the read side.
One brake stops everything
A single switch pauses all unattended automation — for your whole account, or for one end-client — instantly. Scheduled and triggered runs stop; a person keeps manual control for incident response. And when a run can be undone, the revert engine walks it back step by step and reports plainly what it could and couldn't reverse.
For a change on a machine, Orchard acts through the agent already running on that endpoint — in the machine's own signed-in session — not by holding your administrator passwords centrally. For a change in a connected app, it uses the integration credentials you chose to connect. And it never pretends to un-send an email or un-run a command: where an action can't be reversed, the product says so — and can hold it for your approval first.
Where it lives & who we rely on
A deliberately short list of vendors — fewer hands on your data.
Google Cloud Platform (GCP)
Cloud infrastructure and the managed PostgreSQL database that runs the platform, hosted in the United States (us-central1). The database sits on a private network with no public address.
Cloudflare
Edge network and TLS termination in front of the platform — the traffic layer between your endpoints, your console, and the Orchard API.
Resend
Transactional email only — things like password resets and account notices.
Your own integrations
Connections you choose to add — for example a read-only ConnectWise/PSA link — stay under your control. They are your integrations, not ours.
What you can count on
The commitments behind the architecture.
- You decide what's monitored. You authorize the endpoints and the purpose — Orchard acts on your instructions, as your data processor.
- We don't sell your data, and we don't use it for anything other than running the service for you.
- The privacy limits are structural. No screenshots, keystrokes, or passwords — enforced in the capture agent, not toggled by policy.
- You can get it back or have it deleted. On request, and on termination, we return or delete your data.
- Internal access is accountable. When our team can see tenant data at all, it is read-only and every view is logged.
- The full detail is on paper. Our Data Processing Agreement covers processing terms, sub-processors, breach notification, and data-subject rights — available for your review.
Where we are, and what's next
We'd rather tell you our stage plainly than dress it up.
Orchard is an early-stage platform in active design-partner deployments. The protections above are how the product works today — the capture boundary is enforced in the agent, tenant isolation is enforced in the database, automation runs under the controls you just read, and every action and staff read is logged. What we haven't done yet, we won't claim. The items below are on our roadmap as we move out of the design-partner stage — not finished audits.
- SOC 2 — we're pursuing SOC 2, beginning with the Type I foundation. Not yet audited; we'll share current status on request.
- Independent penetration test — a third-party test is on the near-term plan; the report will be available under NDA once complete.
- Single sign-on (SSO) — SAML / OIDC sign-in for your team's console. Multi-factor authentication already ships (see above); SSO is the next step.
- Published retention windows — concrete data-retention and deletion timelines, written into the Data Processing Agreement.
- Compliance frameworks — a DPA is available now. We are not certified against HIPAA, PCI-DSS, or CJIS today, and we'll tell you plainly what we can and can't meet for a given end-client rather than imply coverage we don't have.
Want to go deeper?
We're glad to walk your security team through the architecture, share the full Data Processing Agreement, and answer anything this overview didn't. Ask your Orchard contact.