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
The design turns on one decision, and it is worth stating plainly because most products of this kind make the opposite one.
The dispatcher is a control and convenience layer. It is deliberately not a trusted component. Enforcement lives in the agent, on the machine the work runs on, which is the only place that can be certain about what actually happened.
So the guarantee is this: a caller holding a valid certificate can invoke the approved actions and nothing else, and 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.
The practical consequence is that the blast radius of any compromise is the set of actions an operator already approved, fully recorded, and no more.
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.
Wide platform support
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 both stop at the edge of a site unless something carries them across it, and what usually carries them is a set of shell accounts and shared keys that nobody wants to own.
Xi-Exec is that link, and it brings the encryption, the authentication, the permissions and the controls with it. 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
The question people ask is what happens when the automation is wrong, or is taken over. It is the right question, and the answer is structural rather than reassuring.
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 what it is permitted to do is not one of them, and cannot be made into one from where it sits.