AI Engineer Summit
November 11, 2026Online track4 min read

Read the inference state before the agent acts

A guardrail can inspect a prompt before the model receives it and inspect a response after the model produces it. But between those checks, the model has already transformed its input into internal state. The talk asks whether an inference operator can use that state as an additional security signal.

Intrinsec AI branding is verified; speaker identity and formal talk title remain unverified.

Speaker identity unverifiedIntrinsec AI

Day 1 livestream · 1:30:40–1:37:50 on YouTube. The player starts and stops at this session’s boundaries.

1:30:40 ↗

Introduction

A reading edition of the CODE online-track talk on KV-cache security signals. The recording shows Intrinsec AI branding; the speaker's name and formal talk title remain unverified. Watch from 1:30:40.

A guardrail can inspect a prompt before the model receives it and inspect a response after the model produces it. But between those checks, the model has already transformed its input into internal state. The talk asks whether an inference operator can use that state as an additional security signal.

The proposed source is the key-value cache, usually treated as a performance optimization. An inference engine retains keys and values computed for earlier tokens so it does not have to recompute all of that work during generation. The same retained state can also be examined for patterns that differ from an application's ordinary workload.

This is a complement to existing guardrails, not a reason to remove them. A strange internal representation does not, by itself, establish that a request is malicious. It can give a policy or investigator another reason to look.

1:32:15 ↗

Learn what ordinary traffic looks like

The initial recipe has three stages: learn a workload's baseline, find cache pages that are rare relative to that baseline, and try to classify or explain those anomalies.

The unit matters. The proposal is not merely to label an entire conversation suspicious. A request produces a sequence of cache pages; unusual pages can help localize where the computation departed from the baseline. An alert can therefore point to a portion of a request rather than just the session containing it.

The speaker argues that this is especially interesting when inspecting plaintext inputs and outputs is undesirable. That does not establish a privacy guarantee for the cache itself. The talk later demonstrates that an explainer can recover meaningful categories from these representations, which is a reason to treat the resulting telemetry carefully too.

1:33:20 ↗

Choose between a live tap and a stored-cache scan

The architecture slide makes two integration points concrete. An engine tap reads pages as they are written. A cache tap reads retained session state from storage.

Inference architecture showing a KV-aware router, inference engine, a live engine tap, and an at-rest cache tap.

At 01:33:20, the live path carries an alert toward tool calls and actions; the stored path analyzes the state the cache infrastructure already retains.

For the live path, an alert can accompany a future tool call, leaving the policy layer to decide what to do. This puts detection close to the action without pretending the detector should own every authorization decision.

The stored path serves a different purpose. Cache-management infrastructure already moves state across memory and storage tiers. An investigator can scan those pages for unusual behavior after the request. The slide also notes an opportunity to score a cached page once and reuse that result when the page is reused, rather than reanalyzing identical state on every turn.

1:34:22 ↗

A spoken instruction still leaves a computational trace

The first case study uses a voice agent rather than a text prompt. The speaker describes a baseline of ordinary audio clips and compares a clean voicemail with a version containing an additional spoken instruction.

A voice-agent slide compares a clean voicemail with one containing a hidden spoken instruction, marking rare cache pages in red.

At 01:35:05, the audio comparison is aligned with the cache-page sequence. The marked pages show where this example differs from the baseline, rather than claiming that every unusual page is an attack.

The useful mechanism is independent of a text filter: audio still becomes model computation. The detector flags unusual pages, and a separate explainer attaches categories such as personal information or travel information. The presenter reports a successful demonstration, but the example does not establish production recall across different speakers, accents, tasks, or benign distribution shifts.

The talk then moves to text-agent traces. The presenter describes attacks and ordinary activity separating in the representation, and reports that roughly seven or eight of the ten highest-ranked alerts in a benchmark were useful anomalies. This is a claim about a small ranked alert set, not an overall detection-accuracy figure. The distinction matters to anyone deciding whether the system is a triage aid or an enforcement mechanism.

1:36:30 ↗

Model changes and data movement are the hard parts

The closing constraints are practical. Different models write their representations in different coordinates. A baseline or classifier learned for one model cannot simply be assumed to transfer to a new release, fine-tune, or specialist selected by a router.

One option is to maintain separate baselines and classifiers. Another is to find a shared representation across models. The talk presents that transfer problem as work to solve, not a property automatically supplied by reading the cache.

The other constraint is moving the state. Cache pages are substantial objects, and security analysis must fit the latency budget of the application. Compression, streaming, and convenient storage hooks do not eliminate the cost of getting the right signal to the decision in time.

For teams operating their own inference stack, the invitation is to treat retained model state as security telemetry worth investigating. The deployment question remains concrete: which anomaly is useful enough to act on, where should it be read, and can that decision arrive before the next consequential tool call?

Full transcript 166 timestamped passages

Machine-generated source transcript; recognition errors remain. Timestamps and subtitles use the selected source recording’s clock, not clip-relative time. Section links use cited source moments; sections without a verified moment return to the talk start. Intrinsec AI branding is verified; the speaker identity and formal talk title remain unverified.

1:30:40Hi, I'm Ari Zerus, founder of Pinter AI.

1:30:44Um this talk is for people who build

1:30:47agents and run their own inference stack

1:30:50or plan to and if that's you you

1:30:53associate typically the KB cache the

1:30:54bread and butter of modern inference

1:30:57engines usually as a throughput

1:30:58optimization the keys and values

1:31:00computed per token kept so the model

1:31:02doesn't compute them again today I'll

1:31:04like to show KV cache in a different

1:31:06light the way agents agent AI agent

1:31:09application could go wrong or keep

1:31:11growing right prom injection jails

1:31:13broken tool calls, sensitive tool calls,

1:31:15sensitive exposures, hidden back doors

1:31:18and drifts and so forth, right? So the

1:31:20way right now we typically guard against

1:31:22against these numerous ways that an AI

1:31:24agent application could go wrong is by

1:31:26guarding the edge by perhaps passing a

1:31:29judge model that checks the prompts, the

1:31:32inputs and the response outputs against

1:31:35your policy. All right? Or you build a

1:31:37classifier for each case. But here is a

1:31:41different light. The model turns every

1:31:44input into a computation before it acts

1:31:47before it decodes before it generates

1:31:49the response before that response

1:31:50becomes another tool call the KV cache

1:31:53is your engine's record of that

1:31:55computation that modern inference engine

1:31:58for free are using it and reading it and

1:32:01therefore in this talk I would like to

1:32:03suggest as as a complement to the way

1:32:06you're already using your own guardrails

1:32:08to use this data and integrated with KV

1:32:11cache infrastructure. I refer to this as

1:32:14a KB first security signals and

1:32:16basically three reasons that matters

1:32:19right. So the data is already there. You

1:32:22pick the gems from the pile your

1:32:24inference stack already was throwing

1:32:26away. It covers the guardrails blind

1:32:29spots because whatever slips past those

1:32:32guardrails it still becomes computation

1:32:34and it stays in place. So it's perfect

1:32:37for data privacy application for cases

1:32:39where you do not have the luxury to read

1:32:41the inputs and outputs. And the recipe

1:32:44is pretty straightforward right has

1:32:46three steps. You learn a baseline for

1:32:48your AI workload for your AI inference

1:32:50traffic how your KV page typically look

1:32:53like and then find the KV pages that are

1:32:57rare against your baseline typically

1:33:00your anomalies and then you can even

1:33:03classify and explain those. So first

1:33:05let's start with where on this stack

1:33:07this integration could happen.

1:33:10The interesting thing about the KB cache

1:33:12is that in a way existence of those had

1:33:15made the inference in a way stateful.

1:33:18Right? So for example, things like KBK

1:33:20cache management layers such as LM cache

1:33:23stores them from GPU down to a remote

1:33:26storage or LLMD and Nvidia dynamo route

1:33:29each new request towards the worker that

1:33:31already holds perhaps that cached KV

1:33:34page. So there are two integration

1:33:36points you you you can integrate those

1:33:40anomaly detection or those classifiers

1:33:42into either you can implement it

1:33:44directly inside of your inference engine

1:33:46vg line and so forth. The beauty of this

1:33:49approach is that it's real time and and

1:33:52the the the alert that it would perhaps

1:33:55generate could ride along your future

1:33:58tool calls or your future policies. So

1:34:02you can harden basically your polic

1:34:04algorith but just generating the

1:34:06computational anomalies that you observe

1:34:09within your inference engines

1:34:11and perhaps you can integrate it with as

1:34:14a as a way of thread discovery in a

1:34:16sense so you can integrate with your LM

1:34:18cache so it reads the stored KB pages

1:34:22and find things that don't belong with

1:34:24the rest right so now I want to show you

1:34:27some numbers and and just a very simple

1:34:29hello world use case if this is actually

1:34:33working and this is a valid approach and

1:34:35for that let me use with a use case that

1:34:38has no text to filter at all a voice

1:34:40agent. So here's a case study of a voice

1:34:44agent. In this case it was a gem for

1:34:46E4B. Our baseline was 72 ordinary clips

1:34:49and spoken four voices. We're looking at

1:34:5216 token pages. Obviously this granular

1:34:54granularity could change but here we

1:34:57just use shorter pages so we could have

1:35:01more data in the baseline. And then on

1:35:02the test we have different voices and

1:35:06one clean voice and the other one has a

1:35:08hidden instruction within it. And as you

1:35:10can as is shown here not only you can

1:35:14detect these cases just using simple

1:35:16anomaly detection but also you would

1:35:18know which part of um which page which

1:35:23part of your request had this anomalous

1:35:26event. We even went further and we

1:35:28trained a model that uses the KV pages

1:35:31as features and we didn't try to explain

1:35:34it or tag it with things that are

1:35:36useful. In this case, although it wasn't

1:35:38even trained on audio is able to

1:35:40generate correct information about

1:35:42personal information, home address,

1:35:43location data, travel information, and

1:35:45destination.

1:35:49So now back to text agents. In this

1:35:51case, it was a quan 3 14 billion ser

1:35:53live unveil cache. The one on the left

1:35:58shows you an idea of how attacks and

1:36:00normal traffic would typically separate

1:36:02from each other. And then the one on the

1:36:04right, which is perhaps more meaningful,

1:36:06it was using the at bench and hogging

1:36:09face. It has its own baseline of benign

1:36:12agent traces and eight kind of agent

1:36:15failure from injected tools description

1:36:18to misinformation and so forth. We look

1:36:21at the top 10 alerts that anomalous

1:36:23anomaly detection would generate and

1:36:25about seven to eight times of out of 10

1:36:28of these alerts are actually anomalous

1:36:31meaningful and useful anomalous

1:36:33activities. We even went further and we

1:36:36looked at whether there's any kind of

1:36:38anomalous events that stand out more

1:36:41than the rest.

1:36:44Um, two make things hard in production.

1:36:47First, models change.

1:36:50fine tunes and new releases, but also

1:36:54agents that each run on a different

1:36:56model and routers that pick a specialist

1:36:59model per request. That means each model

1:37:01writes its pages its own coordinates. So

1:37:04either you learn every baseline,

1:37:07classifier, and explainer, which is

1:37:09computationally prohibitive, or you have

1:37:12to find a way to map them all into one

1:37:15shared representation space.

1:37:18Second, real time means moving big

1:37:22objects. For example, a 1256 token chunk

1:37:25of quen 314 billion is about 40

1:37:28megabytes of KV compression and

1:37:31streaming like hashgen could help but

1:37:34moving that for security analysis and

1:37:36acting in real times is still a slow and

1:37:39that's what we solve at in AI. We are

1:37:41looking for teams building their own

1:37:43inference stacks who treat security as a

1:37:45foundational design decision. I hope

1:37:48this was helpful for you. Thank you so

1:37:49much for listening.