Lightspeed Enterprise Agent Fleet

Articles

Secure Agent Fleets

Attack surface should scale with the work an agent does, not with the number of agents you run. Lightspeed's harness holds no operating system and no secrets, and isolates fleets at four boundaries.

The security problem with agent fleets is arithmetic before it is anything else. In the architecture every frontier harness assumes, an agent is a process inside an operating system, so a thousand agents are a thousand operating systems: a thousand kernels to patch, a thousand shells with credentials in their environment, a thousand machines that must be reachable from somewhere. Attack surface scales with the number of agents, and most of those agents are idle at any given moment. A bank ends up defending a fleet of machines that spend the day waiting for a reply.

Lightspeed inverts the arithmetic: the harness runs as a durable workflow, outside any operating system, and only borrows a machine when a task needs one. An idle agent is a row in an event store, not a host on the network. Attack surface scales with work.

The rest of this piece is how that plays out at four boundaries: tenant, credentials, compute and delegation. The vocabulary carries into the two companion pieces on governance and audit.

Tenant

A universe is Lightspeed’s tenant boundary: a project, a workspace, a business unit, a client. One deployment serves many universes through one gateway, one worker pool, one PostgreSQL server and one object store, and the isolation is enforced below the API, not by convention above it. Every universe-owned database record carries the universe in its primary and foreign keys. Object-store keys are prefixed with the universe. Workflow identities are composed from universe and session. Sessions, sub-agents, MCP servers, profiles, environments, credentials and blobs cannot resolve across universes because no query path spans them.

The public API has no universe parameter at all: the gateway resolves the universe before dispatch, from one of three modes. single serves one universe. trusted-header sits behind your authenticating platform or reverse proxy and takes the universe from a header that your edge is responsible for setting. api-key authenticates with a Lightspeed-issued key whose plaintext is printed exactly once; the database keeps a hash and a display prefix. All three fail closed: unknown universes are rejected and never created implicitly, caller-supplied tenant headers are rejected in the modes that do not expect them, and a revoked key gets the same answer as a key that never existed.

Credentials

The model never sees a secret. Secrets live in an AEAD-encrypted store at the universe boundary, an OAuth token broker refreshes tokens on its own, and credentials are injected into the environment or the job where the work happens. A deploy key, a database password, a cluster token: the agent uses them through the machine it borrowed and cannot read them back. Hosted MCP servers work the same way: the universe configures the server and its API-key or OAuth identity once, and a session carries only the selection, never the transport configuration and never the credential. Where a trusted service genuinely needs to retrieve a credential rather than have it injected, the grant is tagged retrievable at creation, leased at the execution boundary, and every lease is counted in audit metadata.

Compute

When a task needs a shell, a compiler or a file system, the session borrows a real machine, and the machine is the boundary, not the harness. The in-repo provider creates a restricted project and a private network per binding, applies CPU, memory and disk limits per instance, gives guests no access to the provider API, and blocks traffic to sibling networks, to the provider hosts and to the control plane. Provider-wide blocked egress ranges apply on top. The data-plane daemon on the machine is passive: Lightspeed dials it when an operation needs a connection, and nothing on the machine can initiate a transport back. A profile can provision a fresh machine per session from a versioned image and release it when the session closes, so a sub-agent that ran a test suite leaves no host behind. Machines that are kept pause, suspend or stop on idle policy and wake on next use.

Model traffic is a boundary too. Lightspeed talks to OpenAI and Anthropic natively, and to any OpenAI-compatible endpoint through universe-scoped endpoint records: a vLLM or Ollama server inside your perimeter is configured once, with its own URL and credential, and sessions select it by name.

Delegation

A fleet is agents starting agents, and the place most systems lose control is the second generation. In Lightspeed a session may only start sub-agents from an allowlisted set of profiles, each profile fixing the model, prompt, tools, grants and environment the child starts with, under root-scoped limits on depth, number of descendants, concurrency and deadline. Sessions created by a workflow have immutable tool bindings: the controller declares the tools once, at creation, and the agent cannot re-bind its own. Cancelling a parent closes its children.

What it adds up to

Count what a thousand-agent fleet exposes. Under one-OS-per-agent: a thousand hosts, each with a shell, credentials and a network address, most of them idle. Under Lightspeed: one gateway, one worker pool, a handful of machines borrowed by the sessions that are actually working right now, and no secret anywhere the model can read it. The fleet is larger; the surface is smaller.

Rests on: universe-owned auth, encrypted secrets, credential injection, dedicated and per-session environments, idle power policy, managed sessions, sub-agents. Source: github.com/smartcomputer-ai/lightspeed.