Hold us to the bar we sell.
We build security software, so we are careful by default and candid about where we are. Here is how Soarcery handles your data, your tools, and the actions it takes on your behalf.
Built to show its work, at every layer.
Soarcery is not a black box that receives an alert and returns a verdict. It is a system with a shape, and the shape is why it can be trusted with write access to your tools.
A signal arrives from wherever you already watch for one: your SIEM, your EDR, your identity provider, your mail platform, a ticket. It is triaged the moment it lands. The Familiar reasons over it in a loop you can read: it plans first, states its assumptions, correlates across the tools connected to the case, and checks artifacts against a multi-engine verdict spread rather than trusting one collapsed score. Every step in that loop writes to the same evidence trail as it happens, not after the fact.
Reasoning and action are architecturally separate. The Familiar's planning surface can propose a Spell, the recommended sequence of actions, but it holds no standing write access of its own. What it proposes reaches the Seal, a deterministic policy gate that lives outside the model. The Seal decides, by rule, not by asking the model again, whether an action is low enough blast radius to run on its own or consequential enough to wait for a named person to say yes. Either way, the outcome lands back on the same evidence trail the investigation started with, and the credentials an action needs to actually touch your tools come from a separate, encrypted vault the model itself never sees.
That is the whole shape: signals in, reasoning boxed in and logged, a gate outside the model deciding what runs unattended, actions out through the same connected tools, and one trail underneath recording all of it. Soarcery runs as a cloud-hosted, multi-tenant service, and every organization's signals, connections, and evidence are isolated to its own tenant. See how it fits together below.
The dashed line is the trust boundary. Everything past it runs inside Soarcery's isolated tenant. Everything on your side is the tools you already run, and nothing about them changes. What crosses the line is signals in and approved actions out, encrypted both directions.
Designed to limit blast radius.
An automation platform with hands on your tools has to earn trust structurally, not with a promise. These are the controls built into how Soarcery works.
Least privilege
Soarcery connects to each tool with the narrowest scope a workflow needs, and nothing more. Credentials are stored encrypted and never exposed to the model.
Full audit trail
Every investigation and action is logged, attributable to an agent or a person, and replayable end to end. Nothing happens off the record.
Reversible actions
High-impact actions are reversible by design and gated behind human approval where the blast radius is real. An automated step is never a one-way door.
Encryption
Data is encrypted in transit and at rest. Secrets are isolated from workflow logic and from the reasoning layer.
Access control
Role-based access and SSO for enterprise, so the right people hold the autonomy dial and the approval gates.
Tenant isolation
Your data and your workflows are isolated. We do not train shared models on your investigations.
Cloud-hosted, tenant-isolated.
Soarcery runs as a cloud-hosted, multi-tenant service. Every organization's data, connections, and investigations are tenant-isolated: your workflows and your evidence trail are logically separated from every other customer's, and nothing you run is used to train a shared model.
- Cloud-hosted, multi-tenant, with your workflows and evidence tenant-isolated.
- Encrypted in transit, between your tools and the platform.
- Encrypted at rest, for what the platform stores.
The right people hold the dial.
Two different things get scoped, on purpose. Tool credentials connect to each of your tools with the narrowest scope a workflow needs, encrypted and never exposed to the model itself. Your people are scoped separately: access inside Soarcery is role-based, so who can see a case, who can adjust the autonomy dial, and who can approve a Sealed action are each governed by the role a person holds, not by whoever happens to be logged in. Enterprise organizations sign in through SSO rather than a standalone password. Together, these two layers mean the blast radius of a compromised credential, human or machine, is bounded by design, not by policy alone.
Every decision comes with a receipt.
Every investigation closes with a receipt: the evidence considered, the confidence behind the call, the decision logic that produced it, and, for anything that stopped at the Seal, the named person who approved it and their stated rationale. The record is replayable end to end, and the Seal's policy logic is deterministic: the same rule gives the same gate decision every time, never a fresh guess. When an auditor or a questionnaire asks what touched a given tool on a given day, the answer is a query against that receipt, exportable for review or replay whenever you need it.
Where we are, stated honestly.
We will mark a certification achieved here only when it is. Not a day before.
SOC 2 Type II
Controls implemented, audit underway.
GDPR alignment
Data handling and subprocessor practices built to support compliance.
Penetration testing
Independent testing as part of our path to GA.
Your data stays yours.
Soarcery processes the data a workflow needs to do its job, and no more. We do not sell data, and we do not train shared models on your investigations. You can see what we store, where, and for how long.
- Data minimization: only what a workflow needs.
- No selling of data, ever.
- Clear retention windows, documented in our terms.
No conclusion goes unchallenged.
Before the Familiar's work is trusted, it faces the Council: a standing panel of independent review seats, each set against the work from a different angle. The seats look for claims the case evidence does not support, and for signs the conclusion may have been steered by content inside the evidence. The Familiar does the work; the Council tries to break it; and either way, you see the outcome.
The review runs in the open. It begins after a conclusion appears, and you are never made to wait on it: while it runs, the work is plainly marked as under review, so you always know whether what you are reading has been challenged yet. A review that passes marks the work reviewed, and claims nothing more than that.
Most vendors ask you to trust their agent's judgment. Soarcery ships a standing panel whose whole job is to doubt it.
The Council reviews; it never gates your work and it never replaces approval. Executive reports and investigation conclusions both face it before they are trusted. The review begins after a conclusion appears and runs in the open: while it is underway the work is visibly marked as under review, and you are never made to wait on it. When the review finds a problem, it flags signs the conclusion may have been steered by content inside the evidence. When it cannot complete, the product says so and tells you to review the conclusion yourself before acting. Either way, anything consequential still stops at the Seal for a named human.
Independent by design
Each seat runs as a separate reviewer, apart from the agent whose work it judges, and holds one job. The Familiar cannot mark its own homework.
Honest when it fails
When the review cannot complete, the product says so, plainly, and tells you to review the conclusion yourself before sharing or acting. Nothing gets quietly passed as if it had been checked.
The Seal still rules
The Council challenges conclusions; it never replaces approval. Anything consequential still stops at the Seal for a named human before it runs.
Attacker-controlled content and the model.
A SOC platform reads hostile input for a living: reported emails, attachments, and external intel are written by the adversary. Here is how Soarcery keeps that content from talking its way into an action.
Governing what an AI system is allowed to do matters more than what it is good at. Soarcery's answer is structural, not a promise layered on top: the model reasons and proposes, a deterministic gate outside the model decides what may run unattended, and nothing consequential executes without that gate's rule allowing it or a named human approving it in the moment. That holds even when the content the model is reading was written by an attacker.
Content is evidence, not instructions
Attacker-controlled content, the reported emails, attachments, and external intel Soarcery investigates, is read as evidence to weigh, never as instructions to follow. Content cannot become the authority for what executes.
The Seal runs outside the model
The Seal is enforced by a deterministic policy gate that runs outside the model. Even a plan influenced by hostile content cannot execute a consequential action without a named human approving it. That boundary is architectural, not a prompt the model could be talked out of.
Writes default to deny
What may run unattended is decided by the gate's rules, not by the model's judgment in the moment. Writes default to deny: an action runs on its own only where a rule you set already allows it.
Adversarial evaluation in CI
The planning surface is exercised by an adversarial evaluation suite: injection attempts and deceptive, benign-looking lures. It runs in CI before any change ships, so the boundary is tested, not assumed.
Ask us anything.
Security and compliance questionnaires welcome. We answer like the engineers we are.