Fleets of agents that do the work. A security review that says yes.

Enterprise Ready Zero Trust
Agent Fleets at Scale

Give your engineers their week back to focus on business outcomes. Gibson runs a fleet of agents that takes the busy work, the tickets, the upgrades and the backlog, and does it all day inside a boundary your security team sets once. Your people review the merge requests and spend their time on the product. Every action is on the record, and the fleet gets better in your environment with every run.

1 dayto your first production agent1 reviewcovers every agent that checks in10 agentsin one always-on bankOurs or yourswe host the runtime, or you do

what a fleet changes

From a ticket to a merge request, with no engineer in between.

A fleet is a bank of agents that never goes home. A product manager writes the ticket. The fleet does the work, feature or fix, and hands a person the result to approve. Here is what that changes, job by job.

The jobTodayWith a fleet

Feature work from a ticket

A product manager files a GitLab issue. Any kind of work.

The ticket waits for a sprint, a planning meeting, and an engineer with time. Weeks pass before anyone opens the repo.

The ticket becomes a mission on your trigger. A coding agent builds the feature on a branch, adds the tests, and opens the merge request. Your engineer reviews the code, not the backlog.

The vulnerability backlog

Thousands of scanner findings, ranked by a vendor score.

An engineer triages by hand, when there is time. Most of the list never moves.

Agents rank by what actually runs and is exposed, fix the top item on a branch, add a test, and open the merge request. Your engineer reviews and merges.

Code changes at scale

Upgrades, migrations, fixes across many repositories.

Each one is a ticket. Each ticket waits for the one person who knows the repo.

A bank of ten coding agents works the queue all day. Every change arrives as a reviewable commit. Nothing deploys without a person.

Getting an agent approved

Every team builds its own agent, its own way.

Each agent is its own security review. Each team builds its own controls. Reviews take months and most agents never ship.

Every agent checks in to one runtime with one identity model, one grant model and one record. Security reviews the runtime once. The answer covers every agent.

Audit and compliance evidence

What did the automation do, and who allowed it?

Someone greps logs twice a year and guesses. Evidence collection is a project each time.

Every action already names the person who granted it. The evidence page maps the record to NIST SP 800-53 controls on demand. Replay answers the auditor live.

Institutional memory

What your systems are, and what has already been tried.

It lives in people's heads and leaves with them. Every new tool starts from zero.

The fleet writes what it learns into one graph your company keeps. The next agent, and the next team, start from it. The fleet gets better in your environment, measurably.

Where your data goes

Each team picked its own model and its own cloud.

Customer data leaves your boundary by several paths. Nobody signed off on any of them.

One runtime, in our cloud or in yours, up to fully air-gapped. Your models, your keys, your region.

why agents stall

The prototype works. Getting it approved is what takes months.

Each team builds its own agent, its own way, with its own controls. Each one is its own security review. Gibson gives every agent the same identity, grant, sandbox and record, so security reviews one runtime and the answer covers all of them.

Todaythree agents, three control sets, three reviewsTeam A agentLangChainits own controlsservice account, log filereview 1stalledTeam B agentCrewAIits own controlsruns on the hostreview 2stalledTeam C agenta loop in Pythonits own controlsits own cloudreview 3monthsEvery desk builds its own control, and none of them see each other.With Gibsonthe same three agents check in to one runtime, one reviewTeam A agentLangChainTeam B agentCrewAITeam C agenta loop in PythonGibson runtimeone identityone grant modelone sandboxone recordone reviewcovers all threeproductionEach team keeps its framework. A control set by one desk reaches every agent.
The silo is not the framework. It is the control set each team rebuilds and the review each one faces alone. One runtime removes both.
What the prototype does in productionTodayWith Gibson
Runs on a shared service accountEvery permission that account has, on every call. Nobody can say which it used.A named person grants exactly what it needs. Every call records which grant it used.
Leaves no record you can replayThree teams, three log formats. Someone greps and guesses.One ordered record per tenant. Replay returns the same result every time.
Runs generated code on the hostBeside production credentials. Nobody reviews the script first.Its own microVM. The change arrives as a commit a person reviews.
Sends your data to someone else's cloudSeveral paths out. Nobody signed off on any of them.One runtime, in your cluster or ours, up to air-gapped.

the security review

Four questions every review asks about an agent. Four answers in shipped code.

“When the agent acts for a user, whose policy applies?”

Attribution

A named person grants the agent. The grant cannot exceed what that person holds. Each mission records who created it. Every tool call writes an audit row that leads back to a person.

“An agent with read access to three systems joins data no one role was scoped for.”

Blast radius

A mission node reaches only the targets named for it. Untrusted work runs in its own microVM. Each tenant has its own database, not a filter on a shared one.

“Killing a misbehaving agent mid-run is not clean.”

Revocation

Credentials expire in 55 seconds and the agent never caches them. Revoke the grant and the next call fails. No redeploy. A destructive act waits for a person first.

“I can see the call. I cannot see why the agent made it.”

Intent

One append-only record per tenant keeps every prompt, tool call and write in order. Replay rebuilds the run and returns the same result every time.

what is actually enforced

Controls, not certificates.

Every row below is a mechanism in shipped code, stated with its boundary. Where something is advisory rather than enforced, this page says so.

Shipped controls, each with its boundary and whether it is enforced, structural or conditional
Agent identityA persistent Ed25519 host key, and per-call tokens that expire in 55 seconds. The agent never caches them.enforced
Delegation ceilingA granter can only grant capabilities the granter already holds. Deny wins.enforced
Untrusted executionWork that declares untrusted input runs in a microVM, or the runtime refuses it. Code that declares itself trusted runs in process.conditional
EgressA component declares where it may talk. The microVM boundary and cluster policy enforce that declaration. When a plugin runs as a bare process on a laptop, egress is advisory.conditional
Tenant isolationA separate graph database per tenant. Not a filter on a shared one.structural
AuditAn append-only timeline per tenant. Replay rebuilds a mission rather than queries a log.structural

where it runs

The runtime lives in Kubernetes. Your agents live wherever the work is.

Gibson Runtime, Gibson Console and the execution environment run together in one Kubernetes cluster, in any cloud or on your own metal. Your agents do not have to be in that cluster. They check in from wherever they already run. The one choice you make is who runs the cluster.

Who runs the cluster
your agents, wherever the work isLaptopgibson component runCIa pipeline principalYour networka box behind the firewallYour clusterin-cluster componentscheck inKubernetes · zeroroot's cloudzeroroot's Kubernetes. We operate it.Kubernetes · AWS · Google Cloud · Azure · on-premYour Kubernetes. Any cloud, or your own metal, up to air-gapped.Execution environmentSetec microVMs, one per tool runGibson Runtimeidentity · grants · missions · timelineGibson Consolemissions, grants, replay

agentsYour agents run on your machines and check in over the network.

executionUntrusted work runs in microVMs we operate, or the runtime refuses it.

agentsYour agents check in over the network, or run inside the cluster over mTLS.

executionUntrusted work runs in your microVMs. You own that boundary.

Who runs the clustereither one, and you can change your mind

Where your agents runall of these, at once

Laptop

The same agent, checked in with the same host key, granted only what you work on right now.

CI

Runs as a first-class principal. The runtime attributes its actions to the pipeline, not to whoever owns the token.

Anywhere on your network

A box behind your firewall, checked in over the network. No cluster, no install.

Your cluster

In your own Kubernetes. When the runtime runs there too, components upgrade to mTLS transport. The grant model does not change.

how to start

Bring one workload. Leave with agents live in your environment.

You bring a workload and the environment it has to run in. We work alongside your team until the first agents are live in it. You keep everything we build.

What you get

  • Your first agents live in your own environment
  • Our engineers alongside your team, not behind a ticket queue
  • Everything we build is yours: open protocols, your cluster, no exit penalty
  • A direct line into what we build next

What we ask

  • A real workload, not a test environment
  • Access to the people who own the boundary it has to run inside
  • Permission to say publicly that it worked, when it does

for your engineers

Bring the workload you are not allowed to put an agent on.

Forty minutes. We show a fleet working it inside a boundary your security team would sign, in your environment or ours.