Agentic
Infrastructure

A concrete proposal for running agent-driven workloads without pretending they are ordinary scripts.

Execution Isolation Self-Service Platform Hardened Substrate Adversarial Engineering

Goal: feedback from Platform on the direction, the boundaries, and what should be validated next.

01

Why this is different

Traditional automation

  • Known script or build step
  • Expected side effects
  • Deterministic enough to reason about before execution
  • CI assumptions mostly fit the workload
cron/script
known code → expected side effects

Agent with tools

  • Decides what to do at runtime
  • Reads files, runs commands, calls APIs, writes code
  • May consume hostile input or generate unsafe actions
  • Closer to giving a human local access than running a cronjob
agent
prompt + model + tools + inputs
→ emergent side effects
Core premise: prompts are not a security boundary. The platform has to assume an agent can malfunction, overreach, or be steered by adversarial input.
02

The platform problem

Workloads people will want

  • One-off agent research and code tasks
  • Scheduled agent jobs and batch workflows
  • Internal tools, dashboards, and small apps
  • Persistent shared agents connected to Slack or internal systems
  • Browser-heavy automation and sandboxed experiments

What Platform still needs

  • Isolation between unrelated workloads
  • Clear ownership and lifecycle controls
  • Scoped credentials and secret delivery
  • Network boundaries and observable egress
  • Logs, audit, cleanup, and recovery paths
We need a paved road that is easier than improvising, without giving every agent ambient access to sensitive infrastructure.
03

A three-layer model

The concrete names matter less than the responsibility boundaries. The proposed stack puts disposable execution cells at the top, runs them through a self-service platform layer, and lands that platform on a hardened host substrate.

%%{init: {"theme": "dark", "themeVariables": {"lineColor": "#f97316", "primaryTextColor": "#f0f0f0", "primaryColor": "#1a1008", "edgeLabelBackground": "#0d0d0d"}}}%% flowchart TB U["Humans / Agents"] --> E["Execution cells\nPi runner-shaped tasks"] E -->|"deployed / scheduled onto"| I["Platform layer\nBlob self-service control plane"] I -->|"runs on"| S["Hardened substrate\nNixtrient-managed hosts"] E -. current artifact .-> P["Pi runner"] I -. current artifact .-> B["Blob"] S -. current artifact .-> N["Nixtrient"] style U fill:#141414,stroke:#333,color:#f0f0f0 style E fill:#1a1008,stroke:#f97316,color:#f0f0f0 style I fill:#1a1008,stroke:#f97316,color:#f0f0f0 style S fill:#1a1008,stroke:#f97316,color:#f0f0f0 style P fill:#141414,stroke:#c2510c,color:#f0f0f0 style B fill:#141414,stroke:#c2510c,color:#f0f0f0 style N fill:#141414,stroke:#c2510c,color:#f0f0f0
04

Execution layer: disposable agent cells

Current artifact: Pi runner POC

  • One agent task per disposable runtime
  • Explicit task, workspace, scratch, and output directories
  • Runs non-root and avoids ambient local context
  • Designed to become a Kubernetes Job/CronJob-shaped workload
  • Useful as a standard runner image, not as the whole security model
Design rule: the runner image should be boring. Policy and isolation belong outside the agent.

Code: github.com/PSPDFKit-labs/agentic-infrastructure/tree/main/pi-runner-v1

%%{init: {"theme": "dark", "themeVariables": {"lineColor": "#f97316", "primaryTextColor": "#f0f0f0", "primaryColor": "#1a1008", "edgeLabelBackground": "#0d0d0d"}}}%% flowchart TD T["/task\ntask.txt or task.json"] --> R["Agent runtime\nPi headless"] R <--> W["/workspace\nwritable working set"] R <--> C["/scratch\ntmp, cache, HOME"] R --> O["/outputs\nstdout, stderr, result metadata"] R --> M["model + approved tools"] style R fill:#1a1008,stroke:#f97316,color:#f0f0f0 style T fill:#141414,stroke:#333,color:#f0f0f0 style W fill:#141414,stroke:#333,color:#f0f0f0 style C fill:#141414,stroke:#333,color:#f0f0f0 style O fill:#141414,stroke:#333,color:#f0f0f0 style M fill:#141414,stroke:#333,color:#f0f0f0
05

Platform layer: self-service deploy and operate

Current artifact: Blob Demo live

  • Start from a folder, static site, Dockerfile, or OCI image
  • Deploy through a small app-centric CLI/API
  • Get a public HTTPS URL without touching routers or schedulers
  • Operate through status, logs, scale, restart, releases, rollback, jobs, audit
  • Usable by humans directly or by agents through a skill

Code: github.com/irrigationreal/blob

%%{init: {"theme": "dark", "themeVariables": {"lineColor": "#f97316", "primaryTextColor": "#f0f0f0", "primaryColor": "#1a1008", "edgeLabelBackground": "#0d0d0d"}}}%% flowchart LR F["project folder\nor image"] --> CLI["blob deploy"] A["agent skill"] --> CLI CLI --> API["platform API"] API --> B["build / image / manifest"] API --> R["run / route / observe"] R --> URL["https://app.example"] API --> OPS["logs · scale · rollback · jobs"] style CLI fill:#1a1008,stroke:#f97316,color:#f0f0f0 style API fill:#1a1008,stroke:#f97316,color:#f0f0f0 style URL fill:#141414,stroke:#c2510c,color:#f0f0f0
The interface is the experiment: can users and agents operate workloads without learning the substrate?
06

Example: deploy this presentation

What the user says

"Deploy this presentation to the Blob demo platform."

What the agent does

  • Uses the provided Blob skill and scoped demo token
  • Creates a static app wrapper around this HTML file
  • Writes a minimal blob.yaml
  • Runs blob deploy
  • Verifies the resulting HTTPS URL

Minimal app definition

name: agentic-infra-stack
form: static
root: .
Why this example matters: the presentation itself can be shipped through the same interface it is proposing. That makes the platform shape concrete instead of abstract.

Demo URL: agentic-infra-stack.blob-demo.tritile.com

07

Substrate layer: hardened hosts

Current artifact: Nixtrient Reference

  • Proposed alternative to imperative/Ansible-style host management
  • NixOS flake defines the system state
  • Provisioning through Terraform, nixos-anywhere, and disko
  • Atomic rebuilds and rollback through Git/Nix history
  • Hetzner-focused templates for reproducible bare-metal/VPS hosts

Code: github.com/PSPDFKit-labs/nixtrient

Erase Your Darlings

  • On boot, root filesystem / is wiped
  • Only explicitly declared persistent state survives
  • Expected persistence: /persist, /nix, /var/log
  • Harder for accidental or malicious changes to become permanent
  • If it matters, it must be declared
This is the substrate discipline: machines should not accumulate undocumented state just because someone or something got a shell.
08

What each layer owns

Layer
Owns
Does not own
Execution cell
Task runtime, filesystem contract, tool harness, result metadata
Scheduling, tenancy, host network policy
Platform control plane
Deploy API, ownership, routes, logs, rollback, jobs, managed-service bindings
Host hardening by itself, final kernel/VM isolation
Substrate
Machine reproducibility, base hardening, persistence model, rollback foundation
App UX, agent semantics, workload ownership model
The boundary is the point: if these responsibilities blur, we either make the interface too low-level or mistake a demo runtime for a security model.
09

Security model: assume the agent misbehaves

A malfunctioning or compromised agent should be able to fail its own task. It should not be able to blow up the host, steal broad credentials, pivot across workloads, or exfiltrate freely.

10

What the platform must enforce

Non-negotiables

  • No broad static credentials inside jobs
  • No Docker socket, privileged mode, casual host mounts, or host networking
  • No unrestricted outbound internet by default for sensitive lanes
  • No treating “internal” as automatically trusted
  • No prompt-only policy

Likely production direction

  • Kubernetes/k3s as the hidden substrate API
  • Kata Containers through RuntimeClass for container-shaped isolation
  • NetworkPolicy, likely Cilium where supported
  • Isolated build workers separate from runtime nodes
  • Separate node pools or trust lanes for risky workloads
Kata is the likely default for container-shaped agent workloads. Full VM systems may need a separate lane: Firecracker, microsandbox, or something else is still an open question.
11

What is real today

Pi runner

  • Working headless Pi container
  • Explicit task/output contract
  • Validated with model + web search
  • Next: richer task schema, event logs, scheduler integration

Blob

  • Live demo control plane
  • Deploys real static/container apps
  • Logs, scale, restart, rollback, jobs, audit
  • Next: harden substrate and policy model

Nixtrient

  • NixOS/Hetzner provisioning reference
  • Erase-your-darlings templates
  • Declarative rebuild and rollback story
  • Next: validate operational fit for Platform
These are not the final architecture. They are concrete artifacts we can now critique.
12

Open architecture questions

  • Is Kata enough for most agent workloads?
  • Which workloads require a full VM or stronger sandbox lane?
  • Should all agent jobs default to strong isolation?
  • What outbound network profiles are acceptable?
  • Where should browser-heavy workloads live?
  • How much UI is needed versus CLI + agent skill?
  • What identity/project model does Platform need?
  • Does NixOS/Nixtrient fit the host management path?
  • What should be v1 versus explicitly later?
  • What production-shaped workload should validate this first?
13

What we want from Platform

Feedback

  • Does this layered model make sense?
  • Is the threat model framed correctly?
  • Is Kubernetes + Kata the right hardening direction?
  • Is Nixtrient worth pursuing as a substrate alternative?

Validation

  • What would Platform need before real internal workloads?
  • Which guardrails must exist before broader dogfooding?
  • What would make this easier than shadow infrastructure?
  • What should we build or test next?
Desired outcome: not approval of a finished architecture — validation of the direction and open discussion while the shape is still cheap to change.
14

We do not need to pretend this is production-ready.

We need to decide whether this is the right shape to harden.

Concrete artifacts Adversarial defaults Platform feedback needed
15