The Data Plane for Agents

What a data plane is

The term comes from networking, where a system splits into a control plane that decides policy and a data plane that everything actually flows through. The data plane is the load-bearing part: nothing gets anywhere without passing through it.

Until now, the layer between software and your data only had to connect and move it. Ordinary APIs did that, and the Model Context Protocol now does it for agents: a standard way to plug in and pass data back and forth, indifferent to what the data says. That is enough when software is only shuttling records between systems.

Agents change the requirement. An agent does not just receive data, it pulls it into context and reasons over it, and whatever lands in that context can steer what it does next. A connection that moves data blindly is no longer safe, because the data is being understood and acted on, not merely passed through.

So the data plane for agents has to govern what it carries: which agent may see which field, what is redacted before it reaches the model, which actions are allowed, and what is recorded. That control lives in the plane itself and runs on the data as it moves, scoped to the agent, on every request, instead of being applied somewhere else after the fact.

We have argued that this layer has to live at the boundary between the agents and your systems, in the connector itself. Read Compartmentalizing the Agentic Workforce for that case. This piece is about what that layer becomes once every agent in a company gets its data through it.

The position on the path

Start with a single agent that reaches its data through PortEden. That is a feature. Now make it every agent in the organization. The boundary stops being a feature and becomes a position: it sits on the path between every app the company has connected and every agent the company runs.

That position is two-sided. On one side, applications connect to the boundary once. On the other, agents consume scoped data through it. Both sides build against the same surface, and the surface is the only place that sees the whole picture.

A new layer in the stack

Software has done this before. Each time two populations needed to connect at scale, the ecosystem grew a layer in between, so each side could build against one surface instead of wiring itself into every counterpart by hand. Payments got one. Bank connections got one. Messaging got one.

Each of those layers ended up standardizing the same thing for its domain: a single, governed way for one side to reach the other.

The scoping flywheel

Standing on that layer makes a genuinely new thing possible. The hard question in running a fleet of agents is not whether to scope them. Everyone agrees they should be scoped. The hard question is which scope is the right one: which set of tools, which fields cut, which shape of context actually produces an agent that works.

That question has a measurable answer now. Over-exposure is not just a breach risk, it is a reliability and cost problem too: too many tools wreck tool selection, too much context degrades the answer, and every unused tool definition and unread field is input tokens you pay for and latency you wait on, on every single call. We covered the evidence in Context Rot: Why Scope Isolation Makes Agents Reliable. The upshot is that the right compartment is not only safer. It makes the agent more accurate, cheaper, and faster, because it has less to wade through.

A data plane that sits in front of many fleets of agents is in the one position to learn which compartments those are. Across deployments, it can see which tool sets, which field cuts, and which context shapes correlate with agents that run cleanly, and turn that into starter scopes, recommended compartments, and benchmarks. Every new customer arrives to a library of scope shapes already proven to work, and every deployment makes that library a little better. The compartments get smarter with scale.

Your scope set is a living policy map

The most valuable thing the data plane holds is not the data passing through it. It is the configuration the company writes on top: the scopes that say which agent may see which field, call which tool, in which window, on whose behalf. Read together, those scopes are a precise, current map of how the business actually runs, and of who is allowed to touch what.

That map is the company's own, and it appreciates. Nobody writes it in a day. It is built one careful decision at a time as the fleet grows, it gets more accurate the longer it is in use, and it doubles as the governance record an auditor wants: not a static document, but the live policy the agents are actually held to. The data itself is borrowed from the systems it lives in. The scope set is something the company creates and keeps.

Why the path is good for everyone on it

A two-sided surface earns its position by being better for both sides than the alternative, not by trapping them. An application integrates with the boundary once and is reachable by every agent that should reach it, instead of being wired separately into each one. An agent gets data that is already scoped and already redacted, which the research says is also the data it reasons over best. A security team gets a single place to see every request and change every rule, instead of chasing per-agent credentials across a dozen apps.

That is why the layer forms at all. A surface that makes apps integrate once, gives agents data they can actually reason over, and gives security one place to see and change every rule is simply the cheaper way to run agents at scale. The data plane earns its place the way connective layers always have, by being less work for everyone on it than the alternative.