From SSH Bastion to AI Agent Firewall: How Expacti Evolved

SSH Sessions Were Black Boxes

If you've ever managed production infrastructure, you know the feeling. Someone SSH'd into a box, did something, and now the database is down. You check bash history. You scrub syslog. You piece together what happened after the fact, like a detective arriving at the scene hours later.

The fundamental problem was visibility. An SSH session is a stream of bytes between two endpoints. The server faithfully executes whatever arrives. Nobody is watching in real time. Nobody can say "wait, don't do that" before the damage is done.

For years, this was an accepted reality. You mitigated the risk with access controls, jump boxes, and the hope that the people with root access knew what they were doing.

Bastions Helped With Access Control, Not Intent

The bastion host pattern was a genuine improvement. Instead of direct SSH to production, you route all traffic through a single hardened jump server. This gives you a few things:

• Centralized access. One place to manage who can reach what.
• Session recording. You can capture terminal I/O for later review.
• Audit trails. At least you know who connected and when.

What bastions don't give you is intent. They can tell you that Alice connected at 3:17 AM. They can even replay what she typed. But they can't tell you whether what she typed was a good idea, and they certainly can't stop her from doing it.

Session recording is forensics, not prevention. It helps you write the postmortem. It doesn't prevent the incident.

The AI Agent Moment

Something changed in the last two years. Large language models started executing shell commands autonomously. Not as a demo, not as a prototype — in production, at scale, across thousands of engineering teams.

An AI coding agent doesn't just suggest code. It runs npm install. It executes docker build. It calls kubectl apply. It does whatever it thinks is needed to complete the task you gave it. And it does it fast, often chaining dozens of commands in a single session without any human in the loop.

This is extraordinary in terms of productivity. And it breaks every assumption the bastion model was built on.

Why the Old Model Breaks

The bastion model assumed a human at the keyboard. A person who types maybe two commands per minute, who pauses to think, who reads the output before deciding what to do next. The security model was: give them access, log what they do, review it later.

An AI agent doesn't pause. It doesn't second-guess. It can execute a hundred commands in the time it takes you to read this sentence. And when it makes a mistake, the blast radius compounds with every subsequent command that builds on that mistake.

Think about what "review the session recording later" means when an agent ran 200 commands in 90 seconds. Nobody is going to watch that recording. Nobody is going to catch the one command on line 147 that dropped a database table.

The problem isn't that AI agents are malicious. They're not. The problem is that they're fast, confident, and operating on incomplete context. They make the same kind of mistakes a tired engineer makes at 3 AM — except they make them at machine speed, and they never get tired enough to slow down.

Before-Execution, Not After-the-Fact

This realization is what drove us to rethink expacti from the ground up. The original architecture was a standard SSH proxy: intercept the connection, record the session, provide a nice audit trail. Useful, but fundamentally reactive.

The new architecture flips the model. Instead of recording what happened and reviewing it later, we intercept each command before it executes. The agent types rm -rf /var/data/*, and instead of faithfully passing it to the target server, expacti holds the session and asks: should this run?

That question gets routed to a reviewer — a human, or an automated policy, or both. The agent's session blocks until the answer comes back. If approved, the command runs. If denied, it never reaches the target. The server never sees it.

This is a fundamentally different posture. You're not building a better SIEM. You're building a firewall for intent.

Making it fast enough to be usable

The obvious objection is latency. If every command needs human approval, the agent is going to be incredibly slow. Correct — which is why blind approval for every command isn't the goal.

Expacti uses a whitelisting engine that auto-approves commands matching known-safe patterns. ls, cat, git status — these flow through instantly. The agent barely notices the proxy is there.

The commands that get held for review are the ones that should be held: destructive operations, privilege escalation, access to sensitive paths, anything the policy engine flags as risky. A well-tuned whitelist means the agent runs at full speed 95% of the time, and only pauses for the 5% that matters.

Add Slack-native approval buttons, risk scoring, and anomaly detection, and the reviewer experience is fast too. Most approvals take under three seconds. The ones that take longer are the ones where pausing was the right call.

From "SSH Proxy" to "AI Agent Firewall"

The pivot wasn't just technical. It was a shift in how we think about the product.

An SSH proxy is infrastructure tooling. It sits in your network diagram, it speaks a specific protocol, and its value proposition is better visibility into SSH sessions. That's a narrow market with known players.

An AI agent firewall is a security primitive. It sits between autonomous code execution and the systems that code can affect. The protocol doesn't matter — SSH today, API calls tomorrow, browser automation next week. What matters is the pattern: intercept, evaluate, decide, execute.

Every AI agent that runs commands in production needs this pattern. Today those agents use SSH and WebSockets. Tomorrow they'll use MCP tools, direct API calls, browser automation frameworks. The commands change, but the need for a decision point before execution doesn't.

What We Learned Along the Way

A few lessons from building this that might be useful if you're thinking about AI agent security:

Whitelists beat blacklists, always. Trying to enumerate every dangerous command is a losing game. New tools, new flags, new attack patterns — the list never ends. Instead, enumerate what's safe and hold everything else. The default posture should be "prove this is okay," not "prove this is dangerous."

Latency is the enemy of adoption, not security. The number one reason teams turn off security controls is that they slow things down. We spent more engineering time optimizing the approval flow (WebSocket latency, Slack integration, auto-approve policies) than on the actual command interception. If the security layer adds perceptible delay to the happy path, people will route around it.

Audit trails matter more than you think. Even with before-execution approval, you need hash-chained audit logs that can prove what happened and when. Not just for compliance — for debugging. When an agent does something unexpected, the audit trail is how you figure out which approved command led to the problem.

Agents are harder to secure than humans because they don't context-switch. A human engineer will notice something feels wrong. They'll stop and check. An agent just keeps going. Your security layer needs to be the thing that notices, because the agent won't.

What Comes Next

SSH is where we started, but it's not where we'll stop. The same intercept-evaluate-decide pattern applies to:

• API calls. An AI agent calling your internal APIs needs the same kind of gating. Should this agent be allowed to call the billing API? Should it be able to modify user records? The answer shouldn't be baked into a static API key — it should be evaluated per-request, in context.
• Browser automation. Agents using tools like Playwright or Puppeteer to interact with web applications. Every page navigation, every form submission, every click is a potential action that deserves scrutiny.
• Code execution sandboxes. When an agent runs arbitrary code in a container or VM, the same principle applies: intercept the execution request, evaluate the risk, decide whether to proceed.
• MCP tool calls. The Model Context Protocol is becoming a standard for how agents interact with external tools. Each tool call is an action that can have real-world consequences.

The protocol details differ, but the architecture is the same. An approval queue. A policy engine. A human in the loop when it matters. A fast path when it doesn't.

We think every team running AI agents in production will need something like this within the next 18 months. Not because the agents are dangerous, but because trust needs a mechanism. You don't deploy to production without CI/CD. You don't merge without code review. And pretty soon, you won't let an AI agent execute commands without an approval layer.

The bastion gave us access control. The firewall gives us intent control. That's the upgrade the AI agent era demands.