Brex Lets AI Agents Run Freely and Watches What They Do on the Network

For most of the past two years, companies trying to deploy AI agents have approached security with a familiar instinct.

Restrict what the software can do.

Give it a narrow list of approved tools. Limit file access. Block shell commands. Define permissions carefully. Put the agent inside a small box and hope that the box stays small.

Brex has begun experimenting with almost the opposite idea.

Its emerging security model starts with a much more uncomfortable assumption. The AI agent may eventually be able to execute almost anything inside its environment. Its code may change. Its behavior may evolve. It may install software, write scripts, call APIs, or generate new capabilities that were never explicitly designed by the company.

Trying to inspect and control every possible internal action may therefore become impractical.

So Brex moved the security boundary outward.

Instead of asking only what code the agent is running, the company began asking a more operational question.

What is this agent trying to communicate with outside the environment?

That shift produced CrabTrap, an open-source HTTP proxy designed to monitor outbound network activity generated by autonomous agents such as OpenClaw. The architecture combines static security rules, large language models acting as semantic policy judges, and human escalation through tools such as Slack.

It is an important experiment because the real enterprise AI race may no longer be simply about building smarter models.

It may be about figuring out how to give increasingly autonomous software enough freedom to be useful without giving it enough freedom to become dangerous.

The enterprise AI conversation is moving beyond chatbots

The word agent has become so broad that it now describes almost everything from a chatbot that calls one API to an autonomous system that edits code, uses a terminal, sends emails and manages workflows.

That ambiguity is becoming a problem.

Brex prefers a more concrete mental model.

Think of the system as a virtual employee.

A virtual employee might appear in Slack. It could have an email address. It might participate in meetings, receive assignments, search company systems and communicate with colleagues.

That framing immediately changes the architecture.

A chatbot is primarily a user interface.

A virtual employee is an operational participant inside the organization.

The difference is enormous.

Once an AI system begins operating across real business systems, the company has to answer the same kinds of questions it answers for human employees.

What is this entity allowed to see?

What actions can it perform?

Who supervises it?

When does it require approval?

How does it escalate?

What happens if its credentials are compromised?

And perhaps most importantly, how do you monitor something capable of creating its own tools?

Those questions became urgent as newer coding models gained enough capability to bootstrap software environments and maintain codebases themselves.

Open-source systems such as OpenClaw illustrate the shift.

Instead of depending entirely on a fixed collection of developer-created functions, increasingly capable agents can write or modify the software they need to complete a task.

That makes them dramatically more flexible.

It also makes traditional control models harder to apply.

The security problem begins when the agent can write its own tools

Traditional enterprise software usually has a predictable architecture.

Developers write the code.

Security teams inspect the code.

Administrators define permissions.

The software performs approximately the same class of operations tomorrow that it performs today.

Autonomous agents weaken that assumption.

If an agent can execute code, install packages, create scripts and call new APIs, then the software running inside the environment may change continuously.

This creates an architectural dilemma.

One response is to restrict the agent's tools.

The enterprise can provide a carefully controlled set of APIs and prevent the agent from executing arbitrary code.

That certainly improves predictability.

But it may also remove much of the flexibility that made powerful coding agents interesting in the first place.

Brex reached a different conclusion.

Rather than constantly trying to determine whether every piece of dynamically generated code is safe, assume that the code inside the agent's container is potentially untrusted.

Then watch the boundary where that code interacts with the outside world.

This is closer to a zero-trust network philosophy than a traditional application security model.

The internal environment may be unpredictable.

The external communication boundary does not have to be.

CrabTrap moves the security perimeter to network traffic

CrabTrap is an HTTP proxy placed between an AI agent and the internet.

Outbound requests move through this layer before reaching external services.

The design starts from a deliberately pessimistic assumption.

The agent could theoretically do anything.

It might even already be compromised.

CrabTrap therefore does not depend on understanding every internal decision the agent makes.

Instead, it evaluates the consequences when the agent attempts to communicate externally.

That distinction matters.

Imagine an autonomous recruiting agent.

It may browse candidate profiles, gather information, score applicants and draft communications.

Searching a publicly accessible professional profile may be low risk.

Sending an email to a candidate is more consequential.

Sending proprietary corporate information to an unknown external server would be significantly more dangerous.

These actions can all appear as network requests.

That gives CrabTrap a relatively stable place to enforce policy even while the agent's internal software changes.

In infrastructure terms, the proxy becomes a control plane around an otherwise highly dynamic execution environment.

Brex uses two security lanes instead of asking an LLM about everything

Sending every HTTP request to a large language model would be expensive and slow.

Inference latency can add hundreds or thousands of milliseconds to an interaction, making the agent painfully inefficient.

Brex therefore separates traffic into two broad categories.

Predictable and previously approved actions can pass through static rules immediately.

If a recruiting workflow regularly needs to open a candidate's LinkedIn page and policy already permits that behavior, there is little reason to ask an expensive AI model to evaluate the request every time.

More ambiguous or higher-risk activity follows a different route.

Those requests are evaluated by an LLM acting as a policy judge.

According to the system described by Brex, only about 2 percent of complex requests require this slower model-based evaluation.

That number is architecturally significant.

A security architecture where every action depends on an LLM would probably be too expensive and unpredictable for many production systems.

A security architecture where models only inspect the semantic edge cases is much more practical.

The static system handles the obvious cases.

The model handles ambiguity.

Humans handle exceptions that require organizational authority.

This is essentially a three-level decision hierarchy.

Rules first.

Machine judgment second.

Human authority last.

Why an LLM can understand network traffic surprisingly well

The interesting discovery was not merely that an LLM could evaluate policy.

It was that the models appeared unusually comfortable interpreting HTTP requests.

That makes sense when you consider what modern language models have consumed during training.

Their datasets include enormous quantities of internet text, documentation, API examples, HTML, software repositories and web traffic patterns.

A request such as sending data to a particular API endpoint is not simply a sequence of technical characters to the model.

It contains semantic information.

The domain matters.

The endpoint matters.

The HTTP method matters.

The parameters matter.

The surrounding business objective matters.

A traditional firewall might see a request to an external service.

A language model may be able to reason that the request represents something more specific.

For example:

This agent is authorized to research candidates.

This request reads a public profile.

That aligns with policy.

Another request might say:

This agent is authorized to evaluate applicants but is attempting to send an unsolicited outbound email.

That requires additional approval.

The important innovation is not that the model replaces deterministic security.

It does not.

The model becomes a semantic interpreter between simple rules and human review.

Jim shows what the virtual employee model looks like

Brex tested the approach with a virtual recruiter called Jim.

Jim operates on top of OpenClaw and performs tasks associated with recruiting.

It can source candidates.

It can score inbound applicants.

It can send email.

These are not theoretical demonstrations.

They involve actions that affect real people and real company processes.

That means the system needs governance.

Suppose Jim attempts to send an email that current policy does not permit.

CrabTrap can identify the request and escalate the decision through Slack.

A human manager receives a message explaining what the agent is trying to accomplish and why the action requires approval.

The system can then suggest a policy change.

The manager accepts or rejects it.

The interesting part is that this resembles how organizations already manage human employees.

A junior employee encounters an unusual situation.

They ask a manager.

The manager evaluates the circumstances.

If the action is reasonable, the organization may expand that employee's authority.

The next similar request can proceed with less friction.

This turns agent governance into something closer to organizational management rather than static software configuration.

The data becomes part of the product

A network-level agent security system generates something extremely valuable.

Behavioral data.

Every attempted external interaction can potentially create information about how autonomous agents behave inside a company.

Which domains do they contact?

Which actions trigger policy conflicts?

Which operations require human approval?

Which permissions are repeatedly requested?

Which agents generate unusual traffic?

Which approvals eventually become permanent policies?

This data could become more valuable than the proxy itself.

Over time, organizations could build behavioral profiles for autonomous workers just as security teams currently build access models for human employees and production applications.

The resulting dataset could support anomaly detection, compliance audits, agent performance analysis, risk scoring and policy optimization.

That creates the possibility of an entirely new enterprise infrastructure category.

CrabTrap looks like infrastructure today but could become a platform

At the moment, CrabTrap is an open-source infrastructure project.

But the architectural idea points toward something much larger.

If companies begin deploying hundreds or thousands of virtual employees, they will need centralized systems governing how those agents access the outside world.

Such a system could eventually manage:

authentication,

network permissions,

approval workflows,

policy enforcement,

human escalation,

audit trails,

risk classification,

agent identities,

budget controls,

and compliance records.

At that point, the product stops looking like a proxy.

It begins looking like an agent governance platform.

This distinction matters commercially.

A narrow security proxy is a useful developer tool.

A governance layer controlling thousands of autonomous workers could become strategic enterprise infrastructure.

The economic value would come from reducing the risk and operational cost associated with deploying increasingly autonomous agents.

The competitive battleground will move upward

Brex is not primarily a cybersecurity company.

That makes its decision to build CrabTrap more revealing.

The company built the system because it could not find an existing commercial product that satisfied its requirements.

That gap will not remain empty for long.

Cloud providers, cybersecurity companies, AI infrastructure vendors and agent platforms are all natural candidates to attack this layer.

The strategic competition may eventually occur between several architectural models.

One model restricts the agent's capabilities.

Another isolates agents inside controlled environments.

Another monitors the network.

Another emphasizes identity and authorization.

The strongest enterprise systems will probably combine all of them.

The question is therefore not whether CrabTrap itself becomes dominant.

The more important question is whether the network becomes one of the primary security boundaries for autonomous software.

Brex's experiment suggests that it might.

The biggest risk is semantic security pretending to be deterministic security

There is an obvious danger in using an LLM as a policy judge.

Language models are probabilistic.

Security policies usually prefer deterministic behavior.

The same flexibility that helps a model interpret ambiguous network requests also creates the possibility of inconsistent judgment.

An agent might manipulate context.

A malicious webpage could attempt prompt injection.

A compromised model workflow could intentionally disguise network activity.

Even innocent requests may be difficult to classify correctly.

The 2 percent escalation architecture helps because deterministic rules still handle the bulk of known traffic.

But enterprises would be making a serious mistake if they treated model judgment as equivalent to cryptographic enforcement.

Semantic security should complement deterministic controls, not replace them.

Logs, identities, sandboxing, credentials, network segmentation and explicit permissions remain necessary.

AI adds another layer of interpretation.

It does not eliminate the foundations.

There is also an economic risk

Running sophisticated autonomous agents is expensive.

Monitoring them is another expense.

Adding model-based security adds further inference cost.

Human approvals create operational overhead.

Companies could easily build impressive autonomous systems whose infrastructure costs exceed the value of the work they automate.

This will create strong pressure to optimize the entire stack.

Simple requests will need cached permissions.

Low-risk traffic will need deterministic rules.

Models will need to be invoked selectively.

Human approvals will need to decline as policies mature.

The winning systems will probably not be the ones with the most AI.

They will be the systems that apply intelligence only where ambiguity exists.

Enterprise architecture will start resembling organizational architecture

The most interesting implication of Brex's experiment is not CrabTrap itself.

It is the organizational model behind it.

Companies have spent decades building infrastructure around human employees.

Employees have identities.

They have job descriptions.

They have supervisors.

They have permissions.

They have budgets.

They have escalation paths.

They have audit histories.

Virtual employees will eventually require the same structure.

Instead of asking only which model an organization uses, enterprise architecture teams may begin asking a different set of questions.

Who owns this agent?

Which department does it belong to?

Which systems can it access?

What can it spend?

Who approves exceptions?

What happens when it violates policy?

Where are its decisions recorded?

That is a major change.

AI infrastructure starts merging with identity management, cybersecurity and organizational governance.

Companies should experiment before the commercial stack becomes obvious

Brex openly acknowledges that its internal solution may not remain necessary.

Commercial vendors will catch up.

A mature agent security platform may eventually make some of today's custom infrastructure obsolete.

But that does not necessarily mean building early was a mistake.

Brex estimated there was a significant chance the system would eventually be discarded.

The company considered the knowledge gained from operating ahead of the market more valuable than preserving the software.

That distinction is important for enterprises evaluating AI investments.

Sometimes the return on infrastructure experimentation is not the infrastructure.

It is organizational learning.

A company deploying autonomous workers today learns what permissions they require.

It learns where agents fail.

It learns how employees interact with them.

It learns where approvals create bottlenecks.

It learns what security teams actually fear once the systems reach production.

Companies waiting for the market to produce a perfect platform avoid some engineering cost.

But they may also postpone this operational learning.

What businesses should do now

Enterprises should avoid jumping immediately from AI assistants to unrestricted autonomous workers.

A more useful approach is incremental.

Start with a workflow where the business outcome is measurable.

Give the agent a clear identity.

Place it inside a contained environment.

Route important network activity through auditable controls.

Separate routine permissions from high-risk actions.

Introduce model-based judgment only where deterministic rules cannot capture the necessary context.

Escalate unresolved decisions to humans.

Then record those decisions and gradually convert repeated approvals into durable policy.

Most importantly, treat the system like an employee rather than a clever API integration.

That mental model forces organizations to design ownership, accountability and escalation from the beginning.

Conclusion

The first phase of enterprise AI was about access to intelligence.

The next phase is about access to authority.

A chatbot that writes a paragraph represents limited operational risk.

An autonomous agent capable of running code, accessing internal systems and communicating with the outside world is something entirely different.

Brex's approach recognizes that distinction.

Rather than assuming enterprises can permanently control every line of code generated by increasingly capable AI systems, CrabTrap moves enforcement toward a boundary companies already understand well.

The network.

Static policies handle predictable actions.

Language models interpret ambiguous ones.

Humans remain the authority for exceptions.

Whether CrabTrap itself becomes a widely adopted platform is less important than the architecture it represents.

As agents become more capable, enterprises may stop asking how to prevent them from doing anything unexpected.

They may instead assume unexpected behavior is inevitable and design systems around observation, containment and accountability.

That is a very different way to think about enterprise software.

And it may be the architecture required when software stops behaving like a tool and starts behaving like a coworker.

SEO keywords: AI agent security, CrabTrap, Brex AI, OpenClaw security, enterprise AI agents, virtual employees, agent governance, network security AI, LLM security judge, autonomous AI agents, AI network proxy, human in loop, enterprise AI security, agent infrastructure, AI governance platform