Security model

The agent driving these tools can be prompt-injected, so execkit treats every tool argument as untrusted. Anything dangerous to the host or filesystem is controlled by the operator at startup through environment variables, never by a per-call agent argument. An injected agent cannot change where the audit log is written, which directory SSH keys come from, or the session limits.

Operator settings

EXECKIT_MCP_KEY_DIR and EXECKIT_MCP_KNOWN_HOSTS default off the home directory, which resolves by priority ($HOME, then the passwd database), so the defaults are correct even when $HOME is unset. Run execkit-mcp doctor to see what each one resolves to on your machine.

What is enforced where

• Host keys are verified by default (TOFU against known_hosts; a changed key is rejected as a likely MITM). Pin an exact key with fingerprint, or set the insecure env var only for throwaway hosts.
• key_path is sandboxed to EXECKIT_MCP_KEY_DIR; traversal or out-of-bounds paths are rejected with a generic error that does not leak path existence.
• The audit destination is operator-chosen, never a tool argument, so an injected agent cannot write to arbitrary files.
• Docker sessions reach any container the daemon can see. Grant Docker access deliberately and scope the context.
• The server speaks MCP on stdout; all diagnostics go to stderr.

Secret redaction

Output (stdout and stderr), the echoed command field, the audit log and the live notifications are all redacted before they leave execkit. Matches become [REDACTED]. Redaction runs before output budgets, so a secret cannot survive by being cut in half.

Redacted output is not file-accurate. Redaction can also hit ordinary code: a secret-named field with a bare identifier as its value, such as TypeScript password: string, comes back as password: [REDACTED]. Never write command output back to a file (for example cat-ing a file and saving what came back); edit files in place with sed, patch or similar instead.

Redaction is a safety net for accidental leaks, not a guarantee. An agent that wants to exfiltrate a secret can encode it first. Keep secrets the agent should not see out of the environment it can reach.

The fence is advisory, not a sandbox

allow / deny command lists are defense in depth, not a jail. Matching on command strings is trivially bypassable (env rm, $(echo rm), base64, bash -c "..."). Name matching looks at the first word of each pipeline segment, so deny: ["curl"] blocks curl and /usr/bin/curl but not env curl or sudo curl. Treat the fence as a guardrail against accidents and obvious mistakes. A denial names the rule or pattern that matched, so the agent can see why a command did not run.

The real security boundary is the operating system: run the agent’s shell as a least-privilege user, in a container, or on a scoped SSH account, so that even a fully compromised agent can only reach what that account can. execkit gives you visibility and undo on top of that boundary; it does not replace it.

Operator command policy

Point EXECKIT_MCP_POLICY_FILE at a JSON file to set an allow/deny fence the agent cannot edit (unlike the per-call allow/deny, which the agent supplies):

{
  "allow": ["git", "ls", "npm"],
  "deny": ["rm", "dd", "shutdown"],
  "deny_patterns": ["\\brm\\b", "kubectl\\s+delete", "git\\s+push\\s+.*--force"]
}

• allow (program names): if non-empty, only these may run. Empty/absent = all.
• deny (program names): always blocked; deny wins over allow.
• deny_patterns (regex over the whole command): for what names cannot express.

Prefer a deny_pattern over a name deny for anything that matters: name matching only sees the program name per pipeline segment, so deny: ["rm"] misses sudo rm and xargs rm, while deny_patterns: ["\\brm\\b"] catches them. In JSON the regex backslashes double up (\\b); use (?i) for case-insensitive matching.

A blocked command never runs; it is recorded in the audit log, shown in watch, and pushed to the client as a warning. This is an ADVISORY guardrail, not a sandbox: string matching is trivially bypassable (env rm, base64, bash -c). The real boundary is a least-privilege user, a container, or a scoped SSH account.