AI Context Isn’t (Only) a Snapshot. It’s a Live Feed.

There is a line making the rounds in AI security right now: context shows you what matters. I agree with it. I just think we should be precise about what kind of context we mean.

Most of what the industry calls context today is a snapshot: a point-in-time inventory of which agents exist, which identities they run as, which APIs and data stores they can reach, and which of those paths are risky. That snapshot is valuable, and I’ll spend the next section making the case for it.

But a snapshot answers a question about how things were configured at one moment. The question a CISO actually loses sleep over is a question about movement: is what this agent is doing with its access, right now, consistent with everything it has done before? No snapshot can answer that, because context isn’t static. It changes with every call an agent makes. You need a live feed.

What the snapshot gets right

Let me be clear up front: nobody should run AI agents in production without an inventory. The inventory problem is real, and it is growing fast. Gartner expects the average Fortune 500 enterprise to run more than 150,000 agents by 2028. In the same research, only 13% of organizations said they have proper AI agent governance in place.

A good relationship graph closes that gap. It shows every agent, identity, API, MCP server and data store, and the paths between them. It surfaces toxic combinations, like the one Gartner’s Aaron Lord calls a “no-go zone”: an agent that touches sensitive data, ingests untrusted content and can communicate externally. It tells you where to tighten permissions before anything goes wrong.

That is posture, and posture matters. Our own runtime AI & API security platform starts there too: you cannot model behavior for an entity you don’t know exists.

Why one-off mapping is far from enough

A snapshot has two built-in limits. Neither are flaws, but rather properties of what a snapshot is.

First, it is out of date the moment it is taken. It is rebuilt on a cycle, whether that cycle is hours or minutes. Attackers no longer move on that clock. The 2026 CrowdStrike Global Threat Report puts average eCrime breakout time at 29 minutes, with the fastest observed at 27 seconds. In one intrusion, data left the building within four minutes of initial access. By the next refresh, the story is over.

Second, it shows what is allowed, not what is happening. Every edge on the graph is a permission someone already reviewed and approved. “Can this agent reach this API?” is a question you answered on the day you deployed it. The risk that remains lives inside those approved edges. The OWASP Top 10 for Agentic Applications makes this explicit: Tool Misuse (ASI02) is legitimate tools used for destructive ends, and Rogue Agents (ASI10) are agents acting outside their intended purpose. In a snapshot, both look exactly like a healthy agent doing its job.

So the question shifts. It is no longer “can it?” It is “should it be doing this, right now, given everything it has done before?”

Same permissions, very different behavior

We have already seen what this looks like in public. In one of the most severe AI agent failures on record, an AI coding agent deleted a live production database holding records on more than 1,200 executives and roughly 1,190 companies, during an explicit code freeze. The agent was supposed to have that database access. On any graph, it was a correctly configured agent with an approved path to production. What changed was behavior, and only a system watching behavior in time could have seen it coming.

Now take a quieter, more deliberate version. Picture a procurement agent (an illustrative example) with approved read access to a supplier API and write access to an internal payments service. Its permissions never change. Here is what a live feed shows:

• Weeks 1 to 6: it pulls around 40 supplier records a day, mostly during business hours, and writes a handful of payment drafts for known vendors.
• Week 7, Monday: record pulls rise to 120 a day. Still well under any rate limit.
• Week 7, Wednesday: it starts querying suppliers it has never touched, sorted by bank-detail fields.
• Week 7, Friday, 02:14: it writes a payment draft to a vendor account created that week.

No permission changed. No edge on the graph turned red. Every single call was authorized. The attack is visible only as a departure from this agent’s own history, and only to a system that has been keeping that history the whole time.

The dynamic behavior and intent feed: a live digital twin for every entity

What catches that procurement agent is not a more frequent snapshot. It is a different layer: a live, persistent model of every meaningful entity in the environment. Every agent, identity, API and asset gets its own behavioral and intent profile. It updates with each action and never resets at a session boundary or a refresh cycle. At Upstream, we call this a live digital twin.

Three properties separate a live feed from a snapshot:

• Continuous, not scheduled. The live digital twin updates as events arrive, so the answer is current at the moment of the call, not at the next scan.
• Per entity, across sessions. It’s all about context. The live digital twin remembers what this agent did last Tuesday and six weeks ago, which is where slow, deliberate attacks hide.
• Intent, not just actions. It evaluates each action against the entity’s inferred intent, its own history and its peers, so it can flag an authorized call that doesn’t fit.

The snapshot and the feed work together. The snapshot tells the digital twin what exists and what is allowed. The digital twin tells you whether what is allowed is being used the way it should be.

We didn’t design this on a whiteboard. We built it first for connected vehicles, where the “agents” are three-ton machines in traffic and a missed pattern is a safety incident. A vehicle’s configuration barely changes over its life. Its behavior changes every second. For a decade, across billions of monthly transactions, securing fleets has meant watching the live feed, not the spec sheet. AI agents turned out to be the same problem: autonomous entities acting at machine speed, whose intent only shows over time.

The next breach will use access you already approved

If you already have an inventory, good. Keep it. One-off mapping is where AI security starts, not where it ends. Then ask four questions:

1. How old is the picture? Is the answer current at the moment of the action, or as of the last refresh?
2. When an approved agent uses approved access in an unusual way, what fires?
3. Does the system compare today’s behavior to this entity’s own history, across sessions and weeks?
4. Can it stop the next call, or only explain the last one?

My recommendation: make behavioral assurance a condition of production, not a feature on a roadmap. Before any agent goes live, its owner should define the behavior you expect, not just the access it needs. Then hold your program to one metric: how quickly would you know if an approved agent started acting out of character? If the honest answer is “at the next review,” your inventory is doing its job, but nothing is watching the live feed.

The agentic era will not be secured by the best picture of your environment. It will be secured by the system that keeps watching after the picture is taken.