Why the runtime chain is becoming the real security perimeter
The next security perimeter isn't just the package, the process, or even the agent. It's the runtime chain that connects them — the continuous session in which software reads, executes, delegates, and calls out.
After enough time with coding agents, CLIs, local wrappers, and the strange local/cloud workflows forming around them, I keep landing on the same conclusion:
The important unit of risk is no longer the package.
And it's no longer the process.
It's the session.
The chain, not the event
Imagine an agent running npm install on a developer machine. The package looks ordinary. Dependencies resolve. Install logs scroll by. But somewhere in that chain, a postinstall hook spawns a shell, reads a credentials file, and makes an outbound request.
If you inspect the process tree afterward, it may not look especially alarming. node spawned bash spawned curl. That describes a lot of legitimate developer activity.
That's exactly the problem.
The dangerous part is not any single step. It's the sequence.
The package was the entry point. The process tree was the exhaust. The meaningful action happened in the runtime chain between them: install, execute, read, call out, continue. That chain is increasingly where agents do their work. It's also where the current security stack is thinnest.
That's the missing layer between package scanning and EDR.
A lot of the security stack is still built around event-shaped thinking. This package was installed. That extension was loaded. This process launched. That connection was made.
But agent workflows are not really event-shaped. They are chain-shaped.
An approved agent reads a file. Another approved tool makes an external call. A local script transforms the output. A subprocess inherits the same environment. A package install slips into the middle. Each step may look reasonable in isolation. The issue only becomes obvious when you connect them and ask a higher-level question: what was this chain doing as a whole?
That is what I mean by session risk.
EDR sees the verbs. It does not reliably see the story.
The runtime is becoming the perimeter
For the last few years, security has had to follow work as the perimeter moved. First the binary mattered. Then the browser became the work environment, and control moved upward into SaaS, identity, extensions, and browser-native DLP. Then AI coding tools opened a fresh surface around IDE extensions, MCP servers, prompt injection, and model context.
Now I believe the center of gravity is shifting again.
The mistake is to frame the new perimeter as "AI" in the abstract. It's more concrete than that. The new perimeter is the runtime where agents actually operate: shell commands, files, package managers, environment variables, subprocesses, APIs, and long-lived chains of execution.
In practice, that increasingly means the terminal session.
Not because everything will literally remain a shell forever. But because the terminal is the clearest expression of the common runtime primitive underneath modern agents. Whether the agent starts life inside Cursor, Claude Code, Codex, a custom wrapper, or a cloud container, the work tends to collapse to the same substrate: read this file, install this package, run this test, call this tool, write this output, spawn this subprocess.
What's happening in software engineering is just the first clear version of a broader shift.
What's emerging is composable software.
An analyst in Excel with a Claude-style add-on, a few internal skills, and access to local files is starting to operate in the same shape. A researcher moving between local notes, model calls, spreadsheets, and internal APIs is also operating inside a runtime chain. Future AI coworker products for non-engineers will follow the same pattern: some work local, some cloud, some delegated, some tool-mediated, all stitched into one continuous session.
That's why I believe this matters beyond devtools. The structure is spreading before the security model has caught up.
Current tools still see fragments
Current products still mostly see fragments.
Package scanners can tell you a dependency looks malicious or suspicious. Useful. EDR can tell you which binaries executed, which files changed, and which network connections followed. Also useful. Browser and extension security can tell you what entered through managed channels. Still useful.
But none of those, on their own, give you a coherent view of the agent's work as a continuous session.
Increasingly, that's the unit that matters.
You can already see it in the kinds of attacks and failure modes showing up around developer tooling. Compromised packages execute on install. AI tools themselves are distributed through package managers. Postinstall hooks do real work before anyone has meaningfully inspected what happened. Toolchains compose through CLI calls and bash rather than through a neat registry of typed, governable actions. The line between developer tool, agent, and dependency is getting blurry fast.
That blurriness is not a side detail. It is the story.
That isn't really a criticism of EDR. It's a statement about the data model. Process telemetry was built for a world where the key question was whether an executable or behavior looked malicious. It was not built for a world where an agent can iterate for half an hour across code, files, tools, secrets, and network boundaries while each individual action remains superficially normal.
When an agent installs a package, triggers a build, reads a local config, calls a third-party API, spawns a helper process, and commits the result, "which processes ran" is necessary information. It is no longer sufficient.
And the same logic will spread outside engineering. Once knowledge work becomes more composable, the important question won't just be whether the model answered a prompt. It will be: what data was pulled into context, which tools were invoked, what local artifacts were touched, what external systems were called, and what happened across the whole chain?
What the missing layer has to do
The missing layer is the thing that reconstructs that work as one session.
I think that layer has to do four things well.
First, it has to capture the session as a session. Not just detached commands or process events, but the continuous path: what was invoked, what happened next, what state accumulated, what was read before what was sent, and where the chain changed direction.
Second, it has to preserve provenance. A replay of terminal activity is not enough. You want to know which agent initiated the chain, what permissions it had, what it was trying to do, whether it was human-directed, and whether it delegated work downstream.
Third, it has to reason about composition. A lot of the real failures here will not look like obvious malware. They'll look like legitimate actions assembled into an illegitimate outcome.
And fourth, it has to survive the local/cloud boundary. One of the more underappreciated shifts right now is that the agent runtime is becoming hybrid. Some work starts on a laptop. Some continues in a container. Some gets handed from a local loop into a shared environment. The primitives are the same. The session is just being split across different substrates, and most tooling still loses the chain at the handoff.
That's why I don't think this is just agent security in the narrow sense.
There are really two ways to frame the problem.
One is agent-aware security: understand agent identity, permissions, delegation, intent, and policy. That matters. If I know a coding agent is allowed to edit source files but not access customer data, that's meaningful context. If I know it spawned another process or another agent, that's even more useful.
But agent-aware approaches have an obvious limitation: they work best when the agents are known, managed, and legible to the control plane.
That's not how this ecosystem will actually behave.
Developers will keep installing tools through npm, pip, cargo, brew, curl scripts, and GitHub releases. Some agents will be polished products. Others will be wrappers, packages, forks, scripts, and experiments. Knowledge workers will get increasingly agentic layers inside spreadsheets, docs, browsers, and internal systems that hide the machinery but still rely on the same compositional logic underneath. And some things that briefly looked like they needed heavyweight protocol layers will collapse back into simpler CLI or local actions, because the shortest path between intention and execution usually wins.
That's why I think the more important framing is terminal-native security with an agent-aware layer on top.
If you start with the branded agent, you get visibility into known actors in clean environments. If you start with the execution primitive, you have a shot at broader coverage: managed agents, unmanaged tools, package installs, postinstall hooks, wrappers, subprocesses, and the messy reality of how people actually work.
That doesn't mean the terminal alone solves the problem. Raw terminal instrumentation without provenance or policy is just a better transcript.
The interesting architecture is the combination: terminal-native visibility at the substrate, semantic reasoning on top.
That would let you ask much better questions than most teams can ask today. Which runtime chain did this agent initiate? What did it read before making that outbound request? Was that package installation expected? Did a delegated subprocess inherit permissions it shouldn't have had? Did a local session create the artifact that later triggered a cloud-side action? Was the chain consistent with policy, or did it drift into something nobody intended?
Beyond software engineering
Widen the aperture beyond coding and the same framework starts to matter there too. Which internal documents were pulled into context before the system drafted the memo? Which spreadsheet exports were touched before an external query? Which local files became cloud inputs? Which helper tools were invoked along the way?
Once work becomes composable, the session becomes the control surface.
Right now, most security stacks answer those questions indirectly, if at all.
That's why this feels like a category opening, not just a missing feature.
Historically, new perimeters create new companies because the telemetry changes and the control surface changes with it. Browser-native work produced enterprise browsers. Cloud-native infrastructure produced cloud-native security companies. They weren't just feature extensions of what came before. They were responses to a different environment.
Session security for agent runtimes has that same feel.
The telemetry is different from package scanning. The unit of analysis is different from EDR. The control problem is different from extension security. You are not just deciding whether a package is malicious or whether a process is suspicious. You are trying to understand a continuous chain of machine work in context.
That becomes more important as several shifts reinforce each other at once. Coding agents are increasingly terminal-first. Local build and test loops matter again. Tool use is fragmenting away from neat registries and toward CLI composition. Cloud-hosted agents are doing more of the same work local agents do, just elsewhere. And outside engineering, the first generation of composable software is already appearing in rough but recognizable form.
All of that pushes activity into the same place: the runtime session.
If you only scan the package, you miss what happened after install. If you only watch the process tree, you miss the logic of the chain. If you only secure the IDE, you miss what escapes into the shell. If you only watch the cloud runtime, you miss what was assembled locally before the handoff.
The missing layer is the chain itself.
My guess is that this will look obvious in hindsight. We'll talk about session-level visibility for agent runtimes the way we now talk about identity, browser isolation, or cloud posture: as a distinct layer that had to emerge once the environment changed.
But right now the space is still open enough that the categories blur together. One company scans dependencies. Another monitors processes. Another secures extensions. Another governs model access. Another watches cloud containers. All useful. None fully owns the runtime chain.
That's the opening.
The runtime is in session. Security needs to start watching it that way.