We spend most of our time arguing about what an agent is allowed to do. However, this question is quite intimately related to the data that the agent has access to, and where it is retrieving and sending that data. Data “location” turns out to impact a lot of your agent risk. Here we don’t mean “is the data encrypted in transit” (it should be), but rather: where does it physically travel, who processes it along the way, and which of those hops do you actually control? Before you decide how to secure your agent, it’s worth briefly thinking about its data architecture.
An agent is three things, and each can “live” somewhere else
An agent is a harness (that’s just a deterministic application), some tools (APIs, MCP services, etc.), and a model (the LLM creating the plan for the agent; practically non-deterministic). Abstractly, that’s the whole anatomy. The harness is the loop that runs the agent — it executes the model calls and feeds the results in again. However, it doesn’t decide what to do; the model decides, the harness executes. The tools are what it executes with — a database, an API, a shell, a mailbox.
From a security viewpoint, each of these can live inside your environment or outside of it, independently of the others. Here is our experience:
- The harness usually runs on your infrastructure. Usually.
- The tools are mixed — some internal (your production database), some external (a third-party API, a SaaS you don’t operate).
- The model call often runs outside of your infrastructure (often, not always).
A single agent task can touch your data centre, a model vendor, and three SaaS APIs in one run. Every one of those interactions is a place your data goes and a place something can go wrong. The first security artefact you need is a simple inventory: a list of all the functional “blocks” accessible to the agent and their associated (data) risk.
The model call is two risks wearing one coat
The model calls in an agentic architecture are tricky because they serve multiple purposes. The model’s response is content (i.e., generated text) and/or instructions. The content can be a risk by, e.g., exfiltrating PII. The instructions can be a risk by forcing the harness to take dangerous actions. What’s somewhat confusing is that the two “travel” over the same line: the line from harness to model. Interestingly, the line is bi-directional and hence poses two potential risks:
-
Exfiltration — data leaving. In its simplest form, the prompt / context going to the model — if that model is outside of your security boundary — is a data exfiltration event.
-
Injection — text becoming an action. Text inserted anywhere the agent reads — the user’s message, a retrieved document, a web page, the response a tool hands back — can become a prompt injection. The model ingests it as ordinary text and reshapes the plan it writes for the harness accordingly. The harness executes the actions faithfully. Any untrusted text retrieved from any tool usage on the way in can become a malicious action on the way out.
The second one is interesting as it seamlessly bridges the gap between “content” and “instructions” — a mechanism we are not very used to (although in a way, it’s central to Turing’s universal Turing machine, so we should have gotten used to it by now…). In the end, a poisoned document isn’t only a data problem — if you are unlucky, its whole purpose is to make the model propose something destructive. A control that only inspects content sees text and waves it through. A control that only checks the action sees one plausible call. Neither control sees that this action followed that text. The new breach we are seeing is the path between them.
How do we control these data risks?
If we look at the various approaches people are using to secure agents, it is pretty clear that every approach relates directly to the data that is “flowing” through the agent:
| Control | What it watches | Where your data ends up | What it does |
|---|---|---|---|
| RBAC / IAM | Identity and access | Often stays within your perimeter | Dictates who (which agent) can call which tool. |
| Guardrails (content checks) | Input or output contents | If it’s a hosted classifier, your content now goes to that vendor too | Judges content, not actions |
| AI gateway | Model traffic | If it’s SaaS, your model traffic — and the context inside it — now routes through a third party | Sees only model calls and merges content and instructions; blind to tool calls / actual actions |
| Agent Security Kernel (Kyvvu) | The full task/action path | Nowhere new — runs in-process, inside the harness, in your perimeter | Does not read the content of prompts or tool calls — it governs the (classified) actions. |
Gateways are good at routing and cost control. IAM is the right foundation for identity, and you should have it. A guardrail will catch a bad input or output. You will need an ASK to watch the instructions as they are being carried out.
Where the ASK sits
Kyvvu is an Agent Security Kernel (ASK). It runs inside the agent’s process (in the harness) and checks every action — every tool call, resource read, message send — against the full path of the task so far, then allows, warns, or blocks it before it executes the next action. Deterministically. In-process.
The reason it belongs in a post about data flow: it’s the one control on that list that doesn’t add a new data infiltration or exfiltration risk. The enforcement policies come to you; your data doesn’t go to the enforcement. You get path-aware control without putting a vendor in your prompt path, without a hop in your model traffic, and without a third party in your action trace. And the record it produces — the runtime evidence an EU AI Act auditor likely wants — is written by the same mechanism that could have stopped the action, inside your own walls.
So, when building agents, start with the high-level data architecture. Understand where both content and instruction come from and go to. You’ll usually find two things — that you have more external hops than you thought, and that the sequence of actions dictated by the model and executed by the harness is not controlled at all. The first you fix just by knowing. The second is the gap we built Kyvvu to fill.
Kyvvu runs in-process and keeps your data in your environment. See how it works at docs.kyvvu.com.