Skip to main content

Security & compliance

Built so your security team says yes.

emisar exists because giving an LLM raw shell access is reckless. Every layer here is designed so the LLM is the least-privileged participant in the system — and every action is auditable.

No inbound port on hosts Secrets redacted before egress No raw shell, ever

Trust boundary

Who can do what, by design.

The LLM is never trusted with privileged execution.

LLM client untrusted

Claude, Cursor, or ChatGPT asks for one catalog action over MCP — with a required reason. It never gets a shell, and undeclared commands don't exist to it.

trust boundary
The gate · control plane require approval approved

Evaluates policy, checks scope and pack trust, routes, and writes the audit. A risky action waits for a human — and it never executes a shell itself.

with signed dispatch
Runner · on your host

Outbound WSS only — the host dials out, nothing listens. A non-root service user re-validates every argument against the schema, re-verifies the pack hash, drops to least privilege, runs argv arrays (never a shell string), and redacts before egress.

Hash-chained journal + cloud audit

Every input, output, exit code, and redaction — a SHA-256-chained JSONL journal on the host, mirrored to the searchable cloud audit and streamable to your SIEM.

The dashed line is optional and per runner: with signed dispatch, the runner trusts the client's signature on the MCP call, not the control plane above it — a compromised cloud can relay it, never forge it.

The approval loop

Watch one risky action cross the gate.

Claude proposes a config reload on a production edge host.
Here is everything that happens next.

Step 1 · Held

A pending approval in the emisar console: Claude, for Maya Chen, asks to run caddy.reload_config on the edge-fra-01 runner. The page shows the action's high risk, the exact command, the reason, the policy that held it, and Approve and send / Deny controls.

Policy holds the agent's request for a human — the exact command, the reason, and the risk on one screen.

Step 2 · Decide

The same approval with the decision note typed into the Decide panel: “validated config, active connections drained, deploy window open”.

Jordan reviews and writes the note the record will keep.

Step 3 · Approved

The request after the click: approved by Jordan Lee, with the note preserved as the decision reason.

Approved — decider, time, and reason on the record.

Step 4 · Executed

The run detail for the approved action: success on edge-fra-01 with exit code 0, the approval decision inline, the executed command marked secrets redacted, and the captured output.

Only now does the runner execute: exit 0, output scrubbed on the runner before it left the host.

Step 5 · Recorded

The audit log opened from View activity, pre-filtered to this dispatch's request-id trace: Run succeeded and Run awaiting approval for caddy.reload_config on edge-fra-01.

Seconds later the audit has the whole trail.

Step 6 · Evidence

The audit event detail for Run succeeded: when, event id, request id, actor Maya Chen, target runner edge-fra-01 with a link to the run, and the full JSON payload including the executed command and exit code 0.

The evidence one click deep — actor, target, request id, payload — exportable to your SIEM.

The demo workspace, captured as-is — a real request, decision, run, and audit trail.

Data handling

Boring, defensible defaults.

TLS-only transport

Runners connect to the control plane over WSS using TLS 1.2+. A single-use enrollment key is exchanged for a per-runner token that can be revoked from the dashboard.

No inbound connections to runners

Runners are outbound-only. No ports to expose, no firewall holes, no NAT traversal. Your hosts initiate every connection.

Hash-chained audit journal

Every action is recorded to an append-only JSONL audit on the host, with each line carrying the SHA-256 of the previous entry. Any edited line or break in the chain is caught by emisar audit verify.

Hash-pinned packs

Action packs are content-addressed. New, custom, or changed hashes block dispatch until an admin trusts the contents. Before execution, the runner recomputes the cloud-pinned hash and rejects a mismatch.

Secrets redacted before egress

20 built-in patterns — AWS keys, common provider tokens (GitHub, Slack, Stripe, OpenAI, …), JWTs, bearer and basic auth, private-key blocks, and secret assignments — plus your own per-action rules scrub stdout and stderr on the runner before anything is forwarded. The control plane receives only the redacted stream; per-rule hit counts are recorded so you can see what was masked.

SIEM export

The cloud audit is the searchable system of record. Stream it to your SIEM as NDJSON with cursor pagination, using a dedicated read-only audit key — so your SIEM never holds a token that can execute an action.

Organizational controls

The knobs your IAM team expects.

RBAC

Roles for owner, admin, billing manager, operator, and viewer, plus per-user runner and runner-group scopes.

Governed LLM access

Runner and MCP keys are short-lived and rotate themselves before they expire, and both belong to a member — revoke the member, revoke their keys.

MFA

TOTP (RFC 6238) on every plan, with one-time recovery codes and replay protection. Enforce it org-wide with one switch.

SSO & SCIM

OIDC sign-in with Google Workspace, Okta, or Keycloak, plus SCIM directory sync. Offboard someone in your IdP and their emisar sessions and keys are revoked automatically.

Independent standard

Built for “assume breach.”

Anthropic — the lab behind Claude — published Zero Trust for AI Agents, a framework for giving autonomous agents access to real systems: least agency, deny-by-default tools, human approval for high-risk actions, and an immutable audit trail. emisar enforces that control set — and assumes the agent may already be compromised, so a jailbroken or prompt-injected model still can't exceed the declared, gated, audited catalog.

Not affiliated with or endorsed by Anthropic. We cite the framework as an independent security reference.

Local admission control

Beyond the cloud policy, an operator can set an allow/deny list on the runner itself. Denied actions are hidden from the catalog and refused at execution — fail-closed, even against a compromised control plane. The host always has the last word.

Signed dispatch — the cloud can't act for you

A runner can be set to refuse the control plane's authority entirely: it runs only an action a real person signed in their own MCP client, with an Ed25519 key that never leaves their machine. A fully compromised emisar control plane can relay that signed request — it can never forge, alter, replay, or originate one. The signature, not the cloud, is the authority. Opt-in per runner; a runner can only make itself stricter.

Set it up — generate keys, distribute, rotate, revoke

Responsible disclosure

Found a security issue? We want to hear about it. Email security@emisar.dev with a description and reproduction steps. We acknowledge reports within 72 hours and credit reporters in our security advisories.

Full policy in SECURITY.md.

Ready to evaluate emisar for your team?

Start free on the Free plan, or book a walkthrough and bring your security team's questions.

Three runners. Seven-day audit. No credit card.