Bastion host searches are up 30% as security teams scramble to manage agentic AI. Discover why perimeter defense falls short and what you need instead.
How Apple broke "Sign in with Apple" with an unannounced and silent redirect
I've been doing this long enough to have watched the same castle get rebuilt under a different name many many times. Decades in security teaches you that the industry doesn't actually invent new fears nearly as often as it invents new vocabulary for old ones. Right now, watching security teams respond to agentic workloads, I'm watching it happen again, in real time.
You don't have to take my word for it either. Global search interest in "bastion host" is up more than 30% year over year, and if you isolate to just the last three months against the same period last year, it's up more than 110%. People are reaching back for the old vocabulary faster than ever, and you can watch it happen in a browser tab.
A bastion was a fortress feature centuries before it was a server. Build one strong, well watched point of entry, force everyone through it, and you can defend the whole perimeter without having to defend every wall equally. That idea worked for medieval fortifications, and it worked reasonably well for network security for the last twenty five years too.
So when agentic workloads started showing up inside enterprise environments, doing things nobody had fully mapped yet, a lot of security teams reached for exactly this playbook. Segment the environment. Route traffic through a VPN. Stand up a bastion host, force authentication and authorization at that one chokepoint, and call it covered.
The newest version of that instinct is an interesting one. A lot of teams have started treating MCP servers as a glorified VPN. Wrap every tool an agent needs behind one MCP server, put a single credential in front of it, and suddenly it feels like you've recreated the chokepoint you're comfortable with, just with a modern acronym on the label. It's the same architecture as a corporate VPN concentrator from two decades ago. One tunnel, one login, everything behind it assumed trustworthy once you're in. The label changed. The blind spot didn't.
I understand the instinct completely. It's the tool that's always worked. And sometimes the old ways really are the best ways. I'd be the last person to tell you that segmentation and controlled chokepoints are bad ideas. They're not. They're just answering a question that agentic workloads never actually asked.
Here's the quiet part out loud. A bastion host assumes the thing moving through it moves at a pace a human can review, approve, and reason about. It assumes lateral movement inside the network happens slowly enough that a chokepoint upstream can catch what matters before damage compounds.
Agentic workloads don't honor that assumption. They act at machine speed, make dozens of tool calls and decisions in the time it takes a human to read the first line of a log, and they don't confine themselves neatly to network boundaries the way the bastion model expects. A shell command executed locally never crosses the VPN. A file write never touches the segment boundary you spent months architecting. The fortress model assumes the enemy has to go through the gate. Agents don't have to go through anything. They're already inside, doing the job you gave them.
This isn't a network problem wearing a new hat. It's a different problem entirely, and the tools built for the old one were never going to be enough for it, no matter how well you configure them.
So what actually works at this speed?
The answer isn't a better bastion host. It's moving the control point to where the action actually happens: the agent harness itself, the layer that sits between an agent and every tool, file, API, and system it can touch. That's where Ory Agent Security operates, and it's built around a question the old model never had to ask: not "did this get through the gate," but "should this specific agent be allowed to take this specific action, right now, on this specific workload."
That only matters if it works everywhere your agents actually run, which is exactly why Ory just expanded coverage on two fronts at once. The harness side grows from five to eleven: Claude Code, Gemini CLI, OpenAI Codex, OpenClaw, and OpenCode were already covered in production, and Continue, Goose, Cline, Amp, Pi, and Google Antigravity just joined them. Alongside that, an entirely new product line launched: thirteen Agent SDK integrations, bringing the same identity, authorization, and audit model to teams building their own agents on frameworks like LangChain, CrewAI, Mastra, AWS Strands, and Pydantic AI, instead of running an off-the-shelf harness. Eleven coding harnesses and thirteen frameworks, enforced from one shared policy model. Not a checklist of logos. The control layer meeting engineers wherever they actually put their agents, whether that's a terminal or a custom pipeline nobody outside the team has ever heard of.
It's powerful because it's not watching from the perimeter. It's present at every point an agent could act, which means it sees shell commands and file writes and tool calls the old chokepoint model never could since it was structurally blind to them. And it doesn't force you into an all or nothing rollout either. You can run it in monitor mode first, actually see what your agentic workloads are doing across the board before you write a single blocking policy, and then tighten controls deliberately, allowing exactly the behavior you want and inhibiting exactly the behavior you don't.
Sometimes the old ways really are the best ways, and I'd never tell a team to throw out a working defense just because something new showed up. But a bastion host was built to guard a gate. Agents don't use the gate. Pretending otherwise isn't discipline. It's nostalgia wearing a badge.
