Infrastructure Operations

Privileged Access Management Without Enterprise Tooling

Small and mid-size organisations need to run administrative scripts on servers but granting developers or operators full SSH access creates unacceptable risk. Broad shell access means accidental or deliberate damage, lateral movement after compromise, and compliance exposure. Enterprise PAM solutions (CyberArk, BeyondTrust) exist but cost tens of thousands per year and require dedicated infrastructure teams to operate. The gap between "SSH to everything" and "enterprise PAM" is wide and largely unaddressed for organisations with 10–100 servers.

The allowlist on each agent is the hard gate. Operators can run only named, pre-approved scripts. No shell. No lateral movement. The auth hook maps users and tokens to permitted operations. Cost is zero beyond the infrastructure already running. The optional script_dirs setting further locks agents down by restricting which filesystem directories scripts may be loaded from.

Audit Trail for Compliance

PCI-DSS, ISO 27001, SOC 2, and similar frameworks require evidence that privileged operations are logged and attributable to a named individual. SSH logs who connected but not what they ran. Bash history is easily cleared. Audit log gaps are a common finding in compliance assessments and a source of remediation cost.

Every operation produces a structured syslog entry on both the ctrl-exec and agent side, with a correlated request ID, username, source IP, script name, arguments, and exit code. The log cannot be cleared by the operator who ran the script - it is on both hosts. Feed syslog to a SIEM and the audit trail is complete and tamper-evident.

Reducing Blast Radius of Compromised Credentials

Stolen SSH keys or compromised operator accounts are a primary attack vector for infrastructure breaches. Once an SSH key is compromised, the attacker has the same access as the legitimate user - typically broad shell access. Key rotation across a fleet is operationally painful, so it is often deferred, extending exposure windows.

mTLS certificates are per-agent and signed by a private CA. The auth hook validates tokens separately from transport identity. Compromise of a token allows only the operations that token is permitted to run on the hosts it is permitted to reach - not shell access. A compromised agent cert can be addressed by re-pairing without affecting other agents.

Runbook Automation Without a Full Orchestration Platform

Operations teams maintain runbooks - documented sequences of manual steps for maintenance, incident response, and routine tasks. Executing runbooks manually is slow, error-prone, and ties up skilled operators on repetitive work. Full orchestration platforms (Ansible Tower, Rundeck, Jenkins) address this but introduce significant operational overhead, require dedicated hosts, and create single points of failure.

Runbook steps become named scripts on each agent. The ctrl-exec CLI or API executes them in sequence, in parallel across hosts, with structured output and exit codes. No orchestration platform required. The API enables integration with existing tooling - monitoring systems, ticketing platforms, or a simple cron job - without a full CI/CD pipeline.

Third-Party and Contractor Access Control

Managed service providers, contractors, and support vendors frequently need to run specific operations on client infrastructure. Giving third parties SSH access creates risk and is difficult to scope or revoke. Access is often too broad (full shell) or too cumbersome (jump hosts, VPNs, session recording systems). Revoking access when a contract ends is a known gap - accounts persist, keys persist.

A contractor receives a token scoped to specific scripts on specific hosts. The auth hook enforces the scope. When the contract ends the token is invalidated in the hook - no key rotation, no account deletion across multiple systems. The audit log shows exactly what the contractor ran and when. The contractor never has shell access and cannot enumerate what else is on the host.

Incident Response Speed

During an incident, operators need to run remediation scripts quickly across multiple affected hosts. SSH-based approaches require sequential execution or ad-hoc parallelism. Coordination overhead under pressure leads to mistakes - running commands on the wrong host, missing hosts, or running steps out of sequence.

A single command runs a remediation script across all affected hosts in parallel with a consistent structured result. Exit codes and output are collected and displayed together. The operator sees immediately which hosts succeeded and which failed without managing multiple terminal sessions. The request ID in logs ties the incident response actions together across all hosts for the post-incident review.

Third-Party and IoT / Edge Device Management

Managing a fleet of edge devices, embedded systems, or remote appliances with SSH is operationally difficult. Many edge environments have restricted network access. Devices may be behind NAT, on cellular networks, or in environments where opening firewall ports for SSH is not permitted. Proprietary device management platforms lock operators into vendor ecosystems.

The minimal footprint (Perl and openssl, both present on most Linux-based embedded systems) makes deployment practical on constrained devices. ctrl-exec runs natively on OpenWrt as a procd-managed service. No vendor lock-in; the entire codebase is auditable Perl.

Replacing Fragile Cron-Driven SSH Scripts

Infrastructure teams accumulate "cron to SSH" patterns - cron jobs on the control host that SSH into remote hosts to run scripts. These are notoriously fragile: SSH host key changes break them silently, key expiry is rarely monitored, failures produce no structured output, and the scripts accumulate without documentation or access control.

The ctrl-exec API is a direct replacement. The cron job calls the API endpoint; structured JSON output can be parsed and acted on; exit codes are reliable; failures are logged on both sides with a request ID. The allowlist documents what each host is expected to do, replacing implicit knowledge in shell scripts.

Open Source Supply Chain and Sovereignty

Dependency on third-party package registries (PyPI, npm, RubyGems) for operational tooling introduces supply chain risk. Several documented attacks have compromised operational tooling via malicious package updates. Organisations with data sovereignty requirements (particularly under GDPR in Europe) are increasingly scrutinising what software runs on their infrastructure and where it comes from.

ctrl-exec has zero external runtime dependencies beyond Debian system packages and the system openssl binary. Nothing is pulled from CPAN, PyPI, or any external registry at install or runtime. The entire codebase is auditable Perl. For organisations on European infrastructure with sovereignty requirements, this is a meaningful distinction.

Agentic AI

AI agent platforms - OpenClaw, NanoClaw, Eigent, NemoClaw, and the growing family of derivative tools - are focused on orchestration, reasoning, and task management. They handle the intelligence layer well. None of them address what happens when an agent reaches the infrastructure boundary and needs to do something on a remote Linux system.

At that point the agent either has broad shell access (dangerous) or no access at all (useless). ctrl-exec is the third option: a structured, allowlisted, auditable execution layer that any agent platform can integrate. The agent decides what to do; ctrl-exec controls how it is done, on what, and under what conditions.

Preventing Prompt Injection from Becoming Infrastructure Compromise

Indirect prompt injection is the documented primary attack vector against agentic AI systems. An attacker embeds malicious instructions in external content - a web page, a document, an email - that the agent processes as part of a legitimate task. The agent, believing it is following user instructions, executes the attacker's commands. Researchers have demonstrated data exfiltration via this vector against OpenClaw in production.

An agent that routes its infrastructure calls through ctrl-exec can only invoke named, allowlisted scripts. A prompt injection attack that attempts to run an arbitrary shell command, exfiltrate a file, or reach a system outside the allowlist receives a refusal - logged, with the request context recorded. The attack surface is structurally reduced, not policy-reduced. The agent cannot be manipulated into running commands that are not in the allowlist, regardless of what instructions it believes it has received.

Tamper-Resistant Execution Boundary for Containerised Agents

Container isolation (the approach taken by NanoClaw and similar) controls what the agent can access on the host machine. It does not control what the agent can do on remote systems it is legitimately permitted to reach. Inside the container, the agent has full bash access to any remote system its credentials allow.

exec-manager runs as a sidecar container alongside the agent container. The agent calls exec-manager; exec-manager calls the ctrl-exec server. The agent never holds API credentials directly - they live in the sidecar. Container isolation controls inbound access to the host; ctrl-exec controls outbound execution against remote systems. Together they form a complete execution envelope.

Giving AI Agents a Defined Capability Surface

An agent with broad shell access does not know what it is supposed to be able to do - it knows what it technically can do, which is everything. This makes agent behaviour unpredictable and makes incident investigation harder.

The discovery API exposes the available scripts across all connected agents. An agent can query the fleet before acting and learn exactly what capabilities are available on which hosts. The allowlist is the authoritative definition of what the agent is permitted to do. This creates a predictable, bounded agent: it knows what it can do, it can only do what it is permitted to do, and every action is logged with a request ID.

Fleet-Wide Agent Actions with Audit Trail

An AI agent managing infrastructure may need to execute an operation across many hosts - checking service health, applying a configuration, running a remediation script. An agent with direct SSH access to a fleet has to manage connection state, parallelism, and error handling itself.

A single API call runs a named script across multiple hosts in parallel. The response collects structured output and exit codes from all hosts. Every call produces a request ID that appears in logs on both the ctrl-exec server and each agent host. An AI agent can submit the call asynchronously, poll for completion, and report results - all without managing SSH connections or handling parallelism directly.

Conditional Execution via Auth Hook

AI agents operating autonomously create new categories of risk around when actions are taken. An agent running a destructive operation at 3am because a scheduled task triggered it, an agent taking an action that requires a human to be present - these are constraints that application-level controls cannot reliably enforce, particularly under prompt injection.

The auth hook evaluates any external condition before permitting execution. Time-of-day restrictions, business hours enforcement, change window validation, operator presence detection, rate limiting per identity, and external policy API checks are all implementable as auth hooks. The hook is called on every invocation, outside the agent's control, and cannot be bypassed by the agent.

AI Agent Actions in Sovereign and Air-Gapped Environments

Organisations with sovereignty requirements, regulated data environments, or air-gapped infrastructure cannot deploy AI agent platforms that require cloud connectivity or have external runtime dependencies.

ctrl-exec has zero external runtime dependencies. A companion OpenWrt VM can enforce a hard network boundary around the execution environment - cutting internet access entirely while still permitting the agent to operate against local infrastructure through ctrl-exec's allowlisted interface. The full isolation stack uses only open source components with no proprietary dependencies at any layer.

Platform-Specific Integrations

NanoClaw

NanoClaw isolates agents from the host using container boundaries. ctrl-exec completes the security model by controlling what those agents can do on remote systems. The reference deployment is a three-container Docker Compose configuration: NanoClaw agent container, exec-manager sidecar (holds API credentials, enforces the allowlist), and the ctrl-exec server running outside both agent containers.

OpenClaw

OpenClaw's ClawHub skills marketplace is the distribution mechanism. A ctrl-exec skill gives any OpenClaw user a structured, allowlisted execution boundary for their infrastructure operations - directly addressing the security concerns that led to CNCERT's warning and government restrictions on OpenClaw in regulated environments.

Eigent

Eigent's multi-agent architecture includes a Developer Agent that writes and executes code and runs terminal commands. When that agent needs to interact with remote infrastructure, ctrl-exec is the execution boundary. The audit trail, argument-level policy, and tamper-evident logging are directly aligned with the compliance-driven and regulated enterprise deployments Eigent targets.

NemoClaw

NemoClaw (NVIDIA) is an enterprise-grade agent platform positioned at Salesforce, Cisco, Google, Adobe, and CrowdStrike. It is an orchestration and observability layer - it does not address infrastructure execution. ctrl-exec is the component NemoClaw needs at the infrastructure boundary. The CrowdStrike security operations use case is particularly direct: agents triaging alerts, running remediation scripts, and querying system state require exactly the audit trail, allowlist enforcement, and argument-level policy that ctrl-exec provides.

For the sysadmin task reference - the specific operations ctrl-exec is suited to - see Tasks.