Console and desktop app
Where people work with agents: chat, files, Git, a terminal, tickets, deployments and the audit log, in the browser or as a desktop app.
How Agenstra works, from the first prompt to the last packet
A control plane that decides and agent managers that execute. Every environment runs in its own container, can run inside a gVisor sandbox, and reaches the internet only through its own egress guard.
Six moving parts, one clear chain of command
Agenstra separates deciding from doing. The control plane knows who you are and what is allowed. The hosts run the agents and enforce those decisions right next to the workload.
Agent controller
The control plane. It authenticates people, resolves policy, keeps tickets, knowledge and audit events, and routes every request to the host that runs the workspace.
Agent manager
One per Docker host. It owns the containers, probes which isolation levels the host can really run, applies message filters and collects every egress decision.
Agent worker
One container per environment. It holds the cloned repository, the agent runtime, a terminal and a full desktop with a browser, and runs as an unprivileged user without sudo.
Egress guard
A small sidecar per environment that owns the worker's network. DNS lookups and web requests pass through it and are checked against your policy.
Identity and access
Single sign-on through Keycloak, built-in users or API keys. Workspace roles decide who may see, chat with and change which environments.
Connections go one way
The controller connects out to each agent manager, and managers never call back. Hosts only need to accept connections from the control plane.
REST and live events
HTTP for state, WebSockets for chat, terminals, desktop streams and boards. Both share one port per service.
Secrets stay out of sight
Credentials are encrypted at rest and reach a worker through a root-only volume, not container variables that show up in a docker inspect.
What happens when you send a prompt
The same six steps apply whether a developer types in the console or a ticket automation starts an autonomous run. Each step has an owner, and each leaves a trace.
Sign in and authorize
You authenticate with single sign-on, a built-in account or a scoped token. The controller checks your role in the workspace before anything reaches a host.
Resolve the policy
Global, workspace and environment configuration are merged into one effective policy: models, tools, permissions, web traffic and message filters. It is synced to the host.
Filter the message
Message filters check every message in both directions. A rule can drop it, rewrite matches or flag it for review. When several rules match, the most restrictive one wins.
Work in the environment
The agent reads and edits the cloned repository, runs commands and tests, and opens a browser if it needs one. All of it inside its own container, optionally on gVisor.
Reach out, within limits
Package installs, API calls and Git pushes leave through the guard. Each connection is allowed, blocked or, in monitor mode, observed against the web traffic policy.
Record and notify
The controller pulls filter hits and traffic decisions into the audit log and can send signed webhooks, so your security tooling sees what the agent did.
Four isolation levels, never a silent downgrade
A regular container shares the host kernel with everything else on the machine. Agent code is code you have not reviewed yet, so Agenstra can put a second kernel in between: gVisor, or a whole virtual machine.
Probed, not assumed
Each host proves with real test containers what it can run: at startup, every six hours and on demand.
Fails closed, overrides are on record
If the sandbox cannot start, the environment is not created. Choosing a weaker level needs a confirmation and is recorded with the person who chose it.
Runs on ordinary cloud VMs
gVisor's systrap platform needs no KVM or nested virtualization. Hosts with hardware virtualization additionally run gVisor on KVM and full microVMs. Provisioned hosts get everything installed and verified automatically.
Standard
runc- Agent and its tools
- Host kernelnamespaces, cgroups, seccomp
Docker's default. Available on every host. Choose it for workloads that need Docker-in-Docker, eBPF, io_uring or KVM.
Limits and mitigationsSandboxed
runsc- Agent and its tools
- gVisor SentryLinux implemented in user space
- Host kernelsmall, filtered set of calls
Preselected wherever the host is ready. A kernel exploit has to break the Sentry first before it can reach the host.
Limits and mitigationsSandboxed + KVM
runsc-kvm- Agent and its tools
- gVisor Sentryin a hardware-virtualized address space
- Host kernelsmall, filtered set of calls
Available where the host exposes KVM. System calls trap into the Sentry through the CPU's virtualization extensions instead of seccomp.
Limits and mitigationsMicroVM
KVMQEMU- Agent and its tools
- Guest kernelits own Linux, inside the VM
- HypervisorKVM, in a locked-down container
- Host kernelonly the VM's virtual hardware
Preselected where the host exposes KVM. The agent gets its own kernel in a virtual machine; an exploit has to escape the hypervisor and a locked-down container before it reaches the host.
Limits and mitigationsOne guard per environment, and nothing gets around it
The worker does not have a network of its own. It joins the network namespace of its egress guard, the only container allowed to change firewall rules. Requests that ignore proxy settings are intercepted anyway.
Web traffic policy of one environmentEnforcing
{
"egress": {
"mode": "enforce",
"block_private_networks": true,
"allow_hosts": [
"github.com",
"npmjs.org"
],
"deny_hosts": ["paste.example"],
"network_allow": [{
"protocol": "tcp",
"ports": "22",
"destinations": ["10.20.0.0/16"]
}]
}
}No TLS decryption
HTTPS is decided on the server name of the handshake. Nothing is decrypted and the agent does not have to trust an extra certificate.
Locked down first
The guard blocks everything before its policy loads, and it exists before the worker does. An invalid policy never replaces the last one that worked.
No side doors
QUIC, DNS over TLS and undeclared protocols are denied. Private networks are blocked by default. Deny rules always win over allow rules.
Fits your corporate proxy
If your network requires a proxy, the guard forwards allowed traffic to it. Your existing controls still see every request.
Four modes, roll out at your pace
offOff
No filtering. The default for environments that do not need a guard yet.
monitorMonitor
Everything is allowed, would-be blocks are recorded. Test a policy against real traffic first.
enforceEnforce
Allow and deny lists apply. Hosts, IP ranges, plain HTTP URL patterns and non-web exceptions.
offlineOffline
No outbound traffic at all. The console, chat and file access keep working.
What the guard can see
Plain HTTP
Full URL, method and status
- URL
- Method
- Status
HTTPS
Hostname only, never paths or content
- Hostname
- Path
- Content
DNS
Every lookup, filtered and logged
- Query name
- Answer
Other TCP and UDP
Denied unless explicitly allowed
- IP and port
- Payload
Policy flows downhill
Security sets the floor once, globally. Workspaces and environments can add to it but never take anything away, so a new team cannot opt out of what everyone agreed on.
The same heredity covers models and providers, MCP servers, permissions, web traffic and message filters. Lock a whole section on a higher layer and lower layers cannot touch it at all.
Global
Platform and security teams: approved models, blocked hosts, mandatory message filters.
Workspace
Team leads: the package registries and APIs this team needs, inside what global allows.
Environment
One agent: narrower still, for example offline for a sensitive repository.
Each level, its limits stated plainly
Good security decisions need to know where a control ends. Compare what each isolation level costs, where it stops and what covers the gap. You choose per environment, and a weaker choice is on record.
The agent shares the host kernel
Every system call goes straight to the host kernel, filtered by namespaces, cgroups and seccomp. A kernel exploit inside the container reaches the host.
Chosen for compatibility, never by accident
Docker-in-Docker, eBPF, io_uring and KVM work as on any Docker host, and the level is available everywhere. Where a stronger level is ready, choosing it needs a confirmation.
One kernel for host and agent. The boundary is the container and the controls around it.
gVisor is not a virtual machine
It shrinks the host kernel's attack surface considerably, but it is not a full virtual machine. Where the host supports KVM, the Sentry is additionally isolated by hardware virtualization, or the environment runs as a full microVM. It works together with unprivileged workloads, the egress guard and a hardened host.
The sandbox costs some speed
CPU-bound work runs at near-native speed. Dependency installs and builds that touch many small files are noticeably slower than on the standard level.
Not every kernel feature is there
No io_uring, iptables or KVM inside, limited FUSE, and no Docker-in-Docker or other container runtimes. Tools that need eBPF, kernel modules or perf do not run.
No single layer has to be perfect. Where one control ends, the next one takes over.
Still no virtual machine boundary
The Sentry runs in a hardware-virtualized address space, but there is no guest kernel. The attack surface shrinks like on the sandboxed level; it does not become a virtual machine.
Fastest on bare metal
Under nested virtualization every VM exit is expensive, so system-call- and network-heavy work can be slower than on the sandboxed level. The same kernel feature gaps apply.
It needs hardware virtualization
The host has to expose KVM, which most ordinary cloud VMs do not. Without it the level is not offered.
System calls trap into the Sentry through the CPU's virtualization extensions instead of seccomp.
A microVM boots before it works
Every environment starts its own Linux kernel first: about 2 to 5 seconds on bare metal or one nesting level, longer under deeper nesting. The launcher takes about 384 MiB on top of the guest memory, and each command run in the environment pays roughly 0.2 seconds for the bridge.
It needs hardware virtualization
The host has to expose KVM. Most Hetzner Cloud and DigitalOcean VMs do not, so microVMs are offered on dedicated or bare-metal hosts and on VMs with nested virtualization. Nested, I/O-heavy work is noticeably slower.
The launcher shares the host kernel
QEMU, libvirt and virtiofsd run in a container on the host kernel. It gets only the KVM device, no network or system administration rights and no new privileges; the hypervisor runs as an unprivileged user.
Not every container feature carries over
There is no KVM inside the guest, ports below 1024 cannot be forwarded and microVM environments cannot be checkpointed or restored. Volumes and copied files live below /guest.
A guest kernel exploit lands in the VM. Reaching the host means breaking QEMU's device model and the locked-down container around it.
What the guard cannot see
HTTPS filtering trusts the name
Without decryption, domain fronting on shared CDNs and encrypted client hellos cannot be told apart by name. Narrow allowlists, blocked IP literals or offline mode close that gap.
Non-root matters
On the container-based levels, a process with root rights inside a worker could bypass the DNS policy, though not the web rules. That is why workers run as an unprivileged user without sudo. In a microVM even root cannot: all guest traffic leaves through the launcher's own sockets.
The same architecture, wherever it runs
Run the control plane yourself or let us operate it. Either way, agents run on hosts that belong to you.
Self-hosted
Container images for the controller and for every agent manager. Add hosts by hand, or let the controller provision them on Hetzner Cloud or DigitalOcean with Docker and gVisor prepared and verified.
Agenstra Cloud
We run the controller, keep it current and scale it. You get the same isolation levels, egress guards and policy layers as a self-hosted installation.
Walk through the architecture with your security team
Bring your threat model. We show you a live environment, its sandbox and its guard, and answer the questions your review will ask.
