How it works
Your agent requests. Your runner executes.
When your agent needs something done — say a service is failing and it wants to investigate — it doesn't open a shell or connect directly to the host. It asks emisar for one declared action, on one server, for a stated reason. Depending on your rules, that request runs right away, gets refused, or waits for a person to approve it. A small program on your server called the runner does the actual work, and every step is written down in the audit log.
The three pieces.
The runner opens an outbound TLS WebSocket and exposes no inbound listener; commands return through that established connection.
Your AI agent
Claude, Cursor, ChatGPT — anything that speaks MCP
Emisar cloud
Your catalog, your rules, approvals, and the audit trail
The runner
A small program on your server that does the work
Watch it work
Watch a real incident resolve.
A CSI driver reformatted a live LUN and wiped 33 hours of metrics. Watch the agent investigate through declared actions, stop the writes behind one approval, and hand back the durable fix as a Terraform PR — over MCP, no SSH, every step on the record.
The agent used fs, debugging, docker, and nomad packs from the catalog. Only the high-risk action was paused for human approval.
One request, start to finish.
Here's a real one: checkout is failing, and the agent wants to restart the service.
-
01
The agent asks
The agent can't run commands — asking is all it can do. The ask is one action from your catalog, the arguments to fill it in, and a reason a human can read later.
the request{ "tool": "run_action", "action_id": "systemd.unit_restart", "args": { "unit": "checkout-api.service" }, "reason": "checkout-api is returning 502s — restart it", "runner": "api-iad-02" } -
02
emisar checks it
Before your rules even come into it, emisar checks the basics: the action really is in your catalog, it comes from a pack version your account trusts — an exact hash in the published catalog auto-pins, and a pack whose content changed on the host is blocked until an admin reviews it — the arguments fit the schema, and this agent is allowed to touch that server.
the checks✓ action systemd.unit_restart — in your catalog ✓ pack linux @ 4e91ab27… — trusted for this account ✓ args unit = "checkout-api.service" — fits the schema ✓ runner api-iad-02 — allowed for this agent
-
03
Your rules decide
This is where your policy comes in: it can let an action run freely, refuse it outright, or require a person to sign off. A service restart is disruptive enough that it waits — Jordan gets the approval, reads the reason, and taps Approve.
the decisionpolicy Service restarts require approval decision require_approval → waiting for a person approved Jordan Lee · 41 seconds later ✓
-
04
The runner does the work
The runner doesn't blindly trust the cloud. It re-checks the pack and the arguments on your own server, runs that one command — there's no shell involved — and scrubs anything that looks like a secret from the output before it leaves the machine.
on your serverrunner api-iad-02 check pack hash + arguments — verified again on the host ✓ run $ systemctl restart checkout-api.service result exit 0 · 0.38s · secrets scrubbed from the output
-
05
Everything is on the record
The whole story — who asked, why, who approved, what ran, and what came back — lands in the audit trail. The host keeps its own copy, each line chained to the one before it, so tampering shows. Search the trail in the console, or have your SIEM poll it out.
the audit entry{ "event": "execution_completed", "action": "systemd.unit_restart", "requested_by": "Maya Chen · Claude Code", "approved_by": "Jordan Lee", "exit_code": 0, "prev_hash": "9a72d4…" }
Run your first gated action in five minutes.
Install the runner, connect your agent, and put a real request through.
Three runners. Seven-day audit. No credit card.