Xi-Exec
Controlled remote script execution for Linux infrastructure. Named, pre-approved scripts over mutual TLS, with centralised access control and a structured audit log.
Xi-Exec dispatches named, pre-approved scripts to remote hosts over mutual TLS, with centralised access control, structured logging, and no shell access required.
It is the secure execution layer between scheduling and output: Xi-Batch decides when work should run, Xi-Exec carries it to the hosts where it has to happen, and Xi-Text delivers the result.
How Xi-Exec compares with the usual answers
Where it is enforced
Xi-Exec separates the dispatcher from the execution environment. The dispatcher handles control and convenience, and is not treated as a trusted component. Enforcement lives in the agent, on the machine the work runs on.
A caller holding a valid certificate can invoke the approved actions and nothing else. It cannot alter the allowlist, the authorisation hook, the configuration, the trust store or the audit trail. That holds even if the dispatcher is entirely under someone else's control.
If the dispatcher is compromised, the attacker can run only the actions an operator has already approved, and each run is recorded.
Allowlist execution
Each agent defines the exact set of scripts it will run. Nothing outside that list can be invoked, regardless of credentials. No shell access is exposed.
The remote host decides what may run on it - not the caller, and not whoever holds a credential.
Mutual TLS transport
Every connection between the controller and an agent is cryptographically authenticated on both sides. No shared passwords. No key distribution. Certificates are managed automatically.
Centralised access control
An auth hook evaluates every request before execution - validating tokens, enforcing time-of-day or change-window restrictions, applying per-script argument policy. It integrates with LDAP, OIDC and existing identity infrastructure rather than requiring a second set of accounts.
Structured audit log
Every operation is logged on both controller and agent with a correlated request ID, the script name, the arguments, the caller identity and the exit code.
The log cannot be cleared by the operator who ran the script.
Parallel fleet execution
A single command dispatches to multiple hosts simultaneously and collects structured results. Suitable for routine operations, incident response and automated workflows.
REST API
A full HTTP API with an OpenAPI specification, for integration with monitoring systems, dashboards and automation pipelines. The live specification reflects the scripts currently available across the connected fleet.
Platforms
Runs on Debian, Ubuntu, Alpine and OpenWrt. Minimal dependencies - system Perl and OpenSSL only. No external package registries required at install or at runtime.
Works with Xi-Batch
Xi-Exec dispatches batch jobs to remote hosts and returns structured results. Existing network management systems can query, create and manage batch processes through Xi-Exec's API without direct host access.
Works with Xi-Text
Xi-Exec manages Xi-Text instances remotely - triggering document generation, managing output queues and controlling print distribution. Operations and document workflow teams work independently through a stable interface.
Working between sites
Scheduling and print management stop at the edge of a site unless something carries the work across. Usually that is a set of shell accounts and shared keys.
Xi-Exec carries the work across with encryption, authentication, permissions and audit. A job scheduled in one data centre runs at another. Output produced centrally prints where the paper and the people are. Neither needs a login on the far side, a key to distribute, or a firewall rule that is wider than the work requires.
The audit record is written on the host that did the work, so the trail crosses the sites with the job rather than stopping at each boundary.
If you are putting automation, or an AI, into operations
If the automation is wrong, or is taken over, it can do no more than any other caller.
An automated caller uses the same door as everyone else, and gets no more than anyone else. It presents a certificate, it names an action from the allowlist, the authorisation hook decides whether that caller may run that action now, and the agent records what happened. There is no shell to reach for and no way to add an action to the list from the outside.
That makes the useful things safe to delegate. Releasing a held print queue, rerunning a failed step, moving work off a printer that has jammed, holding tonight's run pending a decision - all of these are ordinary allowlisted actions that automation can be given.
Changing its own permissions is not on the list, and cannot be added to it from the caller's side.
Talk to us
Request an evaluation ยท The nightly cycle · How it is tested