#SysConf

SysConf 2026 · Sat 3 Oct · 12:25-12:55 WAT · Room 1 · Standard 30m

All talks

#SysConf 2026 · Standard · 25 + 5

Rexec: How to Safely Give AI Agents a Terminal

Alex Idowu · PipeOps · Lagos

Sat 3 Oct 2026 · 12:25-12:55 WAT · Room 1

Field notes · Rexec

Present P · Theme toggle in chrome · → ← · ?present=1 · speaker ?key=

01 · Intro

How to safely give AI agents a terminal - using Rexec

Rexec: How to Safely Give AI Agents a Terminal

Alex Idowu · PipeOps · Lagos · SysConf 2026

02 · Intro · about

Quick intro

I’m Alex Idowu - Co-founder & CTO at PipeOps, based in Lagos.

  • I build platforms, sandboxes, and isolation for a living - Rexec, agents, multi-tenant Kubernetes.
  • Decade-plus in cloud infra, IaC, and runtime security (gVisor, Firecracker, the messy middle).
  • When I’m not in production logs: One Piece, open source for fun, and shipping small tools that scratch my own itch.

That’s enough about me - let’s talk terminals.

Alex Idowu

03 · Goals

What this talk covers

How to safely give AI agents a terminal using Rexec - and the controls that still matter if you wire your own stack.

  1. The problem - agent exec on your workstation, not a sandbox terminal → next
  2. Security & limits - Proxmox lesson → shared host vs VM/node; then the ladder
  3. Reach & disposal - egress + lifecycle on either path
  4. Rexec build - components, then request dataflow
  5. Demo - create → prove → delete

Rexec is the through-line. The controls travel without it.

04 · Content · problem

Agents still get a terminal.
It just shouldn’t be your workstation.

They need to run commands - that’s the product. The shortcut is running those commands as you on a laptop, bastion, or shared runner.

This talk is not “harden your personal shell for AI.”

It’s give the agent its own disposable terminal. That’s what Rexec is for.

Disposable terminal. Now make the walls real.

05 · Content · security & limits

What walls does that terminal get?

Before Docker I ran Proxmox at home - one VM per agent. Heat, maxed box, nowhere to scale. That dead end is why Rexec exists.

Two approaches when I built it: shared host with runtime + kernel protection, or VM / node per agent when the threat model pays for a harder boundary. A delete button is not a boundary - pick a path, then a rung, then hard-cap it.

  • cgroup + caps - baseline on any shared host.
  • gVisor (runsc) - shared-host default; user-space kernel between sandbox and host.
  • Firecracker - guest kernel when one sandbox must not share fate with the next.
  • Default Docker (runc) - shares the host kernel; say so if that’s all you’re using.
  • CPU / mem / PID + TTL - hard caps on both paths; thrash is a DoS on yourself.

Proxmox taught density. Rexec default: shared host + gVisor; escalate to Firecracker / a node when the threat model says so.

06 · Content · reach & disposal

What the terminal can reach, and when it dies

Shared host or VM-per-agent - neither is safe if the shell can phone home forever.

  • Shell = network endpoint - peer traffic, metadata, HTTPS, DNS, demo ports.
  • Egress modes - none · allowlist · full (you accepted the leak).
  • ICC off - stops sandbox-to-sandbox on a Docker bridge; not “no internet.”
  • Lifecycle - create → short-lived secrets → run → attach → delete.
  • Long-lived sandboxes - become bastions with worse accountability (Proxmox pets included).

07 · Content · components

Stack

  • Browser / CLI - where humans and agents attach (xterm.js, API clients).
  • Control API - auth, policy, create / exec / delete, WebSocket sessions.
  • PostgreSQL - users, agents, session metadata.
  • Container Manager → Docker - disposable cloud sandboxes (limits, network, runtime).
  • Agent Handler → BYOS - outbound WebSocket to your machine; no inbound SSH.

08 · Content · dataflow

What happens when you send a request

Rexec request dataflow When you create a sandbox or run a command, the request hits the Rexec API, is persisted in PostgreSQL, then either the Container Manager talks to Docker or the Agent Handler relays over outbound WebSocket to a BYOS agent. Output streams back to the UI. Input create / exec Rexec API auth · route · policy WebSocket session PostgreSQL persist session Container Manager → Docker Engine sandbox Agent Handler → BYOS outbound WS Output stream → UI / agent One request in. Routed. Persisted. Executed. Streamed back.

Input → API (auth/route) → persist → Docker sandbox or BYOS agent → stream output back.

09 · Content · demo

Live: create → prove → delete

  1. Create sandbox (limits + network)
  2. Show the block
  3. Run something agent-shaped
  4. Delete
rexec sandbox create --network none # show the block rexec sandbox delete

10 · Conclusion

Build the agent a terminal.
Don’t share the one you live in.

  1. Secrets and prod never meet an agent on your laptop
  2. One sandbox per task. Then delete it
  3. Untrusted agent code → gVisor or stronger
  4. Egress is a decision. DNS is data
  5. Hard caps + TTL. Outbound agents, not inbound SSH

No Rexec? Same controls with Kubernetes Jobs + RuntimeClass + NetworkPolicy.

Straw Hat crew in a Ghibli-style thank-you scene
arigatou gozaimasu

11 · Resources

Resources

This talk

Isolation & runtimes

Platform building blocks

Questions? · @nitrocode · Lagos