The best way to give your AI agents access to production.

A Zero-Trust gateway connecting Claude, Cursor, ChatGPT, and other MCP agents to your infrastructure. Give your agents the tools to investigate incidents, manage deployments, and handle daily operations. You control what runs, what needs approval, and what stays off-limits in one central place for your Team.

Start free Run the quickstart

Free for 3 runners · No credit card required · Apache-2.0 open-source runner & MCP bridge

1,842

available actions · 103 packs

Zero-Trust for AI

built to Anthropic's control set

Audit logged

plus a hash-chained journal on each host

Open code

Apache-2.0 runner and MCP bridge.

With eyes on production

Your AI is brilliant. And blind.

Claude, Cursor, and ChatGPT reason about your stack all day — but they can't see it running. Emisar gives your agent eyes and secure hands on production.

Find actions for your stack

Starts from real state

Give your agent live logs, metrics, and service state. It can follow the evidence without waiting for you to collect every result.

Debugs what it shipped

Deployed something that misbehaves? Your agent can inspect the running result, find its mistake, and propose a fix. You don't have to gather the context for it.

Works the incident

When the page fires, your agent can investigate across the fleet, line up logs with metrics, and narrow down the cause. You get the evidence and a proposed fix.

The change waits for you

Let routine work run on its own. Put restarts, deployments, and other changes behind approval. Your agent does the legwork; you decide when the change runs.

How access works

Connect your infrastructure through one MCP server.

Add capabilities through packs, without buying another access tool or setting up agent access in another system. Your agents get one organized catalog, governed by the same policies, through the MCP connection they already use.

Versioned action catalog

Start with published packs for the software you run. Each action defines its command, arguments, and limits. Add your own procedures as custom actions; an admin must trust a custom pack before it can run.

linux-core/actions/systemctl_status.yaml

schema_version: 1
id: linux.systemctl_status
title: "Systemd unit status"
kind: exec
risk: medium
args:
  - name: unit
    type: string
    required: true
    validation:
      pattern: "^[a-zA-Z0-9@:_.][a-zA-Z0-9@:_.\-]{0,127}$"
execution:
  command:
    binary: systemctl
    argv: ["status", "{{ args.unit }}", "--no-pager", "--lines=10"]

Policy & approval

Choose which actions run automatically, need approval, or are denied. Set rules by risk, action, host, or group. Require one or several approvers. For repeated work, issue a standing grant. Limit its scope and revoke it at any time.

Risk-tier defaults

lowallow

mediumallow

highrequire approval

criticaldeny

Overrides first match wins

*.delete_* deny

nomad.job_* require approval

Or scope a stricter ruleset to a single runner or a group.

Audit + runner journal

Review the request, policy decision, and outcome in one place. Open the linked run for command details and redacted output. The runner keeps a separate hash-chained journal on the host. Team and Enterprise include audit-event export to your SIEM.

emisar.dev / audit

14:02

Run succeeded

action_run.success nomad.alloc_logs

api_key: claude-prod

14:01

Awaiting approval

action_run.pending_approval nomad.job_revert

api_key: claude-prod

13:58

Approval granted

approval.approved caddy.reload_config

user: ops@acme.co

13:52

Denied by policy

action_run.denied linux.reboot_host

api_key: claude-prod

Browse all 1,842 actions across 103 packs — Postgres, Docker, Nomad, Kubernetes, the AWS suite, and more

Watch it work

A real incident, start to finish.

A CSI driver erased 33 hours of metrics by reformatting a live storage volume. Follow the agent's investigation, the approved action that stopped further writes, and the Terraform fix it prepared for review.

# nomad-hvn03 · Dell R640 · Pure FlashArray over iSCSI multipath · democratic-csi v1.9.5

curl -fsSL https://emisar.dev/install.sh | sudo EMISAR_ENROLLMENT_KEY=emkey-enroll-… EMISAR_PACKS=linux-core,debugging,fs-search,docker,nomad bash

install target: linux/amd64 via systemd

latest release: runner-v0.31.1

install emisar runner-v0.31.1 to /usr/local/bin/emisar (and configure as a service)? [y/N] y

downloading emisar-0.31.1-linux-amd64.tar.gz from Emisar release mirror

checksum signature verified AndrewDryga/emisar/.github/workflows/runner-release-trusted.yml

checksum verified sha256:9f2c1e7b4a0d5c3e…

extracting

staging binary at /usr/local/bin/.emisar-stage.Qw3rTz/emisar

verified: emisar version 0.31.1

creating system user emisar

mkdir /etc/emisar

mkdir /var/lib/emisar

mkdir /var/log/emisar

installed binary to /usr/local/bin/emisar

installed pack linux-core (bundled)

installed pack debugging (bundled)

installed pack fs-search (registry)

installed pack docker (bundled)

installed pack nomad (registry)

writing pre-configured config to /etc/emisar/config.yaml

writing runner.env stub to /etc/emisar/runner.env

writing /etc/systemd/system/emisar.service

starting emisar.service

recorded installer ownership at /etc/emisar/install-receipt

installed emisar runner-v0.31.1

==============================================================

emisar runner-v0.31.1 installed.

Binary: /usr/local/bin/emisar

Config: /etc/emisar/config.yaml

Secrets: /etc/emisar/runner.env (chmod 600)

Data: /var/lib/emisar

Logs: /var/log/emisar/events.jsonl (security log)

Pre-configured from install env (EMISAR_URL + EMISAR_ENROLLMENT_KEY).

Edit /etc/emisar/config.yaml to tighten runner.group / labels later.

The service is running. Check the runner connection:

sudo /usr/local/bin/emisar status

sudo emisar status

✓ connection connected · heartbeat sent 3s ago

✓ catalog 5 packs · 191 actions advertised · all available

✓ process PID 2214 · up 9s · 1 connection attempt(s)

✓ runs 0 in flight (last reported by the daemon)

✓ checks 7 local readiness checks passed

Runner is connected and healthy.

sudo journalctl -u emisar -f -o cat

time=2026-10-28T13:41:06.873Z level=INFO msg=cloud.dial url=wss://emisar.dev/runner/socket/websocket external_id=nomad-hvn03

time=2026-10-28T13:41:07.412Z level=INFO msg=cloud.connected actions=191 packs=5 inflight_runs=0 requeued_starts=0 requeued_results=0

time=2026-10-28T13:47:02.114Z level=INFO msg=cloud.run_started request_id=req_7Hk2pQ9xWm4LsN1vT8cRaA action_id=nomad.alloc_stop

time=2026-10-28T13:47:02.497Z level=INFO msg=cloud.run_finished request_id=req_7Hk2pQ9xWm4LsN1vT8cRaA action_id=nomad.alloc_stop status=success exit_code=0 duration_ms=383 reason=""

emisar MCP connected · 14 tools · scoped to nomad-hvn03

grafana shows the last 7 days of metrics flat — only the last 12 minutes are alive. the process is healthy and ingesting. where did 33 hours of data go?

A flat week with only the last 12 minutes alive means VictoriaMetrics restarted onto empty storage. So I'll follow the data: look at its volume, then the kernel log from when it was mounted, then the CSI driver that mounted it.

emisar · fs.ls_long(path: "…/vm-data", reason: "what's actually on the VictoriaMetrics volume?")

drwx------ 2 root root 16384 lost+found

# a brand-new, empty ext4 — born 30 minutes ago. The 33h of history isn't here.

emisar · debugging.dmesg_tail(lines: 400, reason: "what happened at mount time?")

13:11:03 device-mapper: multipath 254:3: queue_if_no_path enabled

13:11:09 EXT4-fs (dm-3): mounted a clean filesystem # 6 seconds — with no active path

emisar · docker.logs(container: "democratic-csi", lines: 2000, reason: "did the CSI driver format it?")

GetDiskFormat /dev/mapper/3624…265c → blkid output="" (empty)

"unformatted" → mkfs.ext4 -F /dev/mapper/3624… → "successfully formatted" # over a LIVE LUN

Root cause: a multipath path-group race. On migration every path came up queue-ready but none active, so the first read returned empty — democratic-csi took "empty" for "unformatted" and reformatted the live LUN. It's the known CSI bug kubernetes#95183. VictoriaMetrics is overwriting the old blocks right now, so the first move is to stop the writes.

emisar · nomad.alloc_stop(alloc: "a1b2c3d4", reason: "CSI reformatted a live LUN — halt writes to preserve recoverable blocks")

⏸ pending approval — nomad.alloc_stop is high-risk; a human approves in the portal

✓ approved by you · one use · audit event recorded

alloc a1b2c3d4 stopped · writes halted · LUN frozen for forensics

Writes are stopped. Now a durable fix — it goes in the infra repo, since a host change won't survive the next drain. The driver has a node.format.disabled flag that should prevent this; I'll check the source before relying on it.

gh · democratic-csi/democratic-csi@v1.9.5 — read NodeStageVolume in src/driver/index.js

async NodeStageVolume(call) { … await filesystem.formatDevice(device, fs_type) }

# formatDevice runs mkfs unconditionally, and nothing on this path reads node.format.disabled — it's a no-op in v1.9.5.

So the flag won't help. I'll shadow mkfs inside the CSI container so the driver can't reformat a live Pure LUN, and still set format.disabled (commented) so we pick up the upstream fix when it lands.

git · open PR "csi: guard against the driver reformatting live LUNs"

1 file changed, 38 insertions(+)

@@ template local/driver-config.yaml @@

node:

+ format:

+ # ignored by v1.9.5 (filesystem.formatDevice); kept for when upstream honors it

+ disabled: true

@@ task node · shadow mkfs before exec democratic-csi @@

+ for n in mkfs mkfs.ext4 mkfs.xfs …; do mv "$d/$n" "$d/$n.real"; cp guard "$d/$n"; done

@@ new file local/mkfs.guard @@

+ case "$dev" in /dev/*) ;; *) exec "$real" "$@" ;; esac

+ grep -qiE 'nvme|Pure|FlashArray' "$sys/model" || exec "$real" "$@" # local disk → real mkfs

+ [ "$(blkid -o value -s TYPE "$dev")" = ext4 ] && exit 0 # re-attach → no-op

+ exit 64 # blank or unsure on a live Pure LUN → refuse, never mkfs

33 hours of metrics are gone — overwritten before I caught the writes. The disk is frozen if you want to attempt recovery. The PR keeps format.disabled for when upstream honors it, and adds mkfs.guard so the driver can't mkfs a mounted Pure LUN. Review and merge before the next node drain.

The agent used fs, debugging, docker, and nomad packs from the catalog. Only the high-risk action was paused for human approval.

Why not just…

Production access. Without the blank check.

An agent with unrestricted host access and your SSH keys can investigate, deploy, or delete. emisar gives your agent production tools with rules enforced before each action. A custom MCP server puts those controls on your own build list.

emisar compared with unrestricted agent access through SSH and a custom MCP server
Capability	emisar	Unrestricted SSH access	Custom MCP server
Read logs and query metrics	Yes	Yes	Build it
Deploy and restart services	Yes	Yes	Build it
Run your own procedures	Yes	Yes	Build it
Limit actions by policy	Yes	No	Build it
Validate action arguments	Yes	No	Build it
Require approval for changes	Yes	No	Build it
Issue and revoke standing grants	Yes	No	Build it
Record actions and policy decisions	Yes	No	Build it

Read logs and query metrics

emisar: Yes
Unrestricted SSH: Yes
Custom MCP: Build it

Deploy and restart services

emisar: Yes
Unrestricted SSH: Yes
Custom MCP: Build it

Run your own procedures

emisar: Yes
Unrestricted SSH: Yes
Custom MCP: Build it

Limit actions by policy

emisar: Yes
Unrestricted SSH: No
Custom MCP: Build it

Validate action arguments

emisar: Yes
Unrestricted SSH: No
Custom MCP: Build it

Require approval for changes

emisar: Yes
Unrestricted SSH: No
Custom MCP: Build it

Issue and revoke standing grants

emisar: Yes
Unrestricted SSH: No
Custom MCP: Build it

Record actions and policy decisions

emisar: Yes
Unrestricted SSH: No
Custom MCP: Build it

Read the full SSH-for-AI comparison Compare with a custom MCP server Compare with the copy-paste workflow

Case studies

Two incidents, in full.

The storage wipe from the demo, written up end to end — and a completely different failure on the network. Both real, both logged with the command output to prove it.

storage

A CSI driver wiped 33 hours of metrics

The incident from the demo, in full — including the twist. The obvious one-line fix was a no-op, so the durable fix the agent shipped is a guard that refuses to trust the driver.

Read the post-mortem

ingress

A fleet-wide 502 no backend was causing

Every app behind one edge threw intermittent 502s — yet every backend was green. The agent traced it across five layers to an OOM loop and a stuck node still advertising a dead ingress, then stopped the bleed behind gated approvals.

Read the post-mortem

See every use case — the daily wins and the war stories

Zero Trust for AI Agents

The framework a frontier lab published — enforced by emisar.

Anthropic's Zero Trust for AI Agents guide says an agent with access to real systems needs four things: least agency, deny-by-default tools, human approval for high-risk actions, and durable audit evidence. Emisar applies these controls to each action and records the work in the cloud audit and a separate journal on the host. We ship core action controls on the Free plan.

See emisar mapped to the framework, control by control

Not affiliated with or endorsed by Anthropic. We cite the framework because emisar is built to the control set it describes.

Deploy in about five minutes.

Keep your existing infrastructure and AI client. The runner connects out, so there's no inbound port to open or SSH key to hand over.

Follow the quickstart

01

Install the runner

Create a free account and copy the install command to your Linux host. The runner connects to emisar automatically.
02

Choose your packs

Use the packs suggested for your host. Set which actions run on their own and which need approval.
03

Connect your agent

Add emisar to your MCP client. Ask your agent to investigate a service, check a deployment, or handle a routine task.

Pricing

Pay per runner. Not per seat.

Free for 3 runners and 1 user. Team is $20/runner/month with unlimited users.

Free

For a first host or a small setup.

$0 / forever

Start free

3 runners
1 user
7-day audit retention

For teams

Team

For teams operating production.

$20 / runner / month

Start free

Up to 100 runners
Unlimited users
90-day audit retention
Automated invoices, email support

Enterprise

For larger fleets and procurement requirements.

Custom

Talk to sales

Unlimited runners & users
365-day audit retention
Security and procurement review
Design-partner deployment planning

FAQ

Before you get started.

What can the agent run through emisar?

Only actions from trusted packs that pass your access rules and policy. The runner checks each request again on the host. Any other tools you give your agent need their own access controls.

What can it actually do?

Your agent can read service logs, query metrics, inspect databases and containers, and carry out operations such as restarting a service. Install published packs for the software you run, or write an action for your own procedure. Your policy decides which requests are allowed.

Where do approvals happen?

In the web UI and your email inbox. The approver sees who requested the action, its arguments, the target host, and the policy rule requiring approval. They can approve or deny the request.

Do I have to approve every action?

No. Set rules by risk tier, action, runner, or runner group. New accounts allow low- and medium-risk actions, require approval for high-risk actions, and deny critical actions. You can change these rules or create standing grants for repeated work.

What if my runner dies mid-run?

On Linux, when the runner exits, it stops the action it started. If only the connection drops, the action keeps running while the runner is alive. After a host or runner failure, inspect the target before repeating a change: the action may have run even if you never received its result.

Is this MCP-compatible?

Yes. Claude.ai and ChatGPT connect through remote MCP with OAuth. Fifteen local clients, including Claude Code, Claude Desktop, Cursor, Windsurf, Zed, Copilot CLI, Gemini CLI, and Codex CLI, can use the emisar stdio bridge. The bridge also works with almost any other MCP agent.

Can I self-host the control plane?

Emisar's supported product uses the hosted control plane. You can run the repository code for evaluation, but we don't offer supported self-hosted or air-gapped deployments. Contact us if self-hosting is a requirement.

What about secrets?

The runner masks output that matches configured patterns before sending it back. Unknown secret formats can still pass through. Run history stores exact arguments, with sensitive fields masked in console and API views; the cloud audit records decisions and outcomes.

Give your AI production access. Without losing sleep.

Let your agents investigate, deploy, and keep production running. You set the rules. emisar enforces them on every action.

Prefer a walkthrough first? Book a 30-minute demo.

Free for 3 runners. No credit card required.

The best way to give your AI agents access to production.

Your AI is brilliant. And blind.

Starts from real state

Debugs what it shipped

Works the incident

The change waits for you

Connect your infrastructure through one MCP server.

Versioned action catalog

Policy & approval

Audit + runner journal

A real incident, start to finish.

Production access. Without the blank check.

Read logs and query metrics

Deploy and restart services

Run your own procedures

Limit actions by policy

Validate action arguments

Require approval for changes

Issue and revoke standing grants

Record actions and policy decisions

Two incidents, in full.

A CSI driver wiped 33 hours of metrics

A fleet-wide 502 no backend was causing

The framework a frontier lab published — enforced by emisar.

Deploy in about five minutes.

Install the runner

Choose your packs

Connect your agent

Pay per runner. Not per seat.

Free

Team

Enterprise

Before you get started.

Give your AI production access. Without losing sleep.