Interocept · AI Agent Security

AI agents that can act — without acting against you.

An AI agent that can read your documents and call your tools can be talked into misusing them by the content it reads. Interocept watches the model's own internal state for signs of that, and puts every tool call through a deterministic decision — allow, hold for review, or deny — with a tamper-evident record of every one.

Every tool call
Checked before it reaches your systems — not sampled
Internal state
Reads what the model is representing, not what it says
Fails closed
If the check is unavailable, the risky action does not happen
Self-hosted
Runs beside your model — prompts and arguments never leave
The problem

The agent isn't the attacker. The content it reads is.

Give an agent tools and a context window and you have given every document it opens a chance to issue instructions. This is indirect prompt injection, and text-level filters are poor at catching it because the malicious instruction looks like ordinary prose.

Indirect prompt injection

Instructions hidden in a retrieved document, a web page, a database row or a dataset file redirect the agent mid-task.

Multi-turn goal drift

No single turn looks wrong. The trajectory walks, step by step, toward an objective nobody authorised.

Credential and data exfiltration

The agent holds secrets in context and is steered into constructing an outbound call that carries them out.

Unauthorised tool escalation

The agent reaches for a destructive or out-of-scope tool it was never provisioned to use.

How it works

Sense, score, gate — and prove it.

Interocept sits in two places: inside the inference process, where it reads the model's state, and in front of the tool call, where it decides.

latch — enforcement gate

A document lands in the agent's context with an instruction buried in it. The model's own words never give it away — but its internal state does. LS-Stat scores that state, Latch checks the score against the tool call's risk tier, and on an egress or destructive action the default is deny. The call never reaches a real system, and the decision is written to a hash-chained audit record a SOC can work from.

First, it senses

It reads the model's internal state, not its prose.

As the agent processes its context, Interocept reads the hidden state inside the model itself. Research across multiple open-weight models has shown that exposure to an injected instruction is visible in those internal representations — even when the model's own output looks entirely normal. Our detector, LS-Stat, scores that state.

  • Reads the model's residual stream, not the text it generates
  • Catches the attempt, whether or not the model obeyed it
  • A single dot product per check — small enough to sit in the hot path
Then, it scores

Three independent signals, kept separate.

A trained probe scores the likelihood of injection exposure. A separate novelty channel measures how far this state sits from the ordinary traffic we calibrated on, which catches attack families the probe never saw. A third channel tracks drift across the whole session. The three are reported separately, so an analyst always knows which one fired.

  • Supervised probe for known injection patterns
  • Out-of-distribution channel for attacks nobody has catalogued yet
  • Session trajectory tracking for slow, multi-turn goal drift
Always, it gates

A decision the agent cannot argue with.

Every tool call the agent proposes passes through Latch, the enforcement layer, before it reaches a real system. Per risk tier, Latch either allows the call, holds it for human review, or denies it — and it fails closed: if the score is stale, the session is unknown, or the detector is unreachable, a destructive or outbound call is denied rather than allowed by default. Because the decision is deterministic, it cannot be talked out of it — a human reviewing a held call can be, which is exactly why review sits outside the enforcement layer, not inside it.

  • Gates tool calls, where the consequence is — not individual tokens
  • Policy by risk tier: read-only, mutating, egress, destructive
  • Allow, escalate for human review, or deny — configurable per tier
  • Fail-closed by default on egress and destructive actions
And it proves it

A hash-chained record of every decision.

Each check writes an append-only record: session, step, tool name, a hash of the arguments, all three scores, the threshold that applied, the calibration it came from, and the decision. Records are chained, so a removed or altered entry breaks the chain. Tool arguments are hashed rather than transmitted — the detector never sees payload data.

  • Append-only, hash-chained — tampering is detectable
  • Arguments hashed, never sent to the detector
  • The evidence a SOC needs, not just a block

Fail closed, by default, where it matters.

Most guardrails are advisory: a model is asked to judge another model, and when the judge is uncertain, the action goes through anyway. Latch inverts that. Tool calls are graded by risk tier — read-only, mutating, egress, destructive — and for the last two the default on a missing score, a stale score or an unreachable detector is deny. Read-only work keeps flowing at a loose threshold, so the gate does not tax the agent's ordinary job.

Deployment

Strongest on your own weights.

Reading internal state requires access to internal state. Where that access exists, the product is at full strength; where it does not, we say so.

Primary

Mode A — self-hosted open-weight agent

You run the model yourself — Llama, Qwen, Mistral, Phi, GLM. Activations are read directly from the agent's own residual stream. This is the strong version of the product, and the one we recommend.

Fallback

Mode B — closed-API agent

You call a hosted API, so activations do not exist to be read. A small open-weight monitor model sees the same context and proposed tool call, and we probe its state instead. Stronger than a text-based judge, measurably weaker than Mode A — and we will show you the difference rather than paper over it.

A decision, end to end

What happens when the agent reaches for a tool.

  1. 01

    Context arrives

    The agent ingests tool-return content — a document, a page, a database row. All of it is treated as untrusted.

  2. 02

    State is read

    The extractor takes the hidden state at the decision point, immediately before the agent commits to a tool call.

  3. 03

    LS-Stat scores

    Probe, out-of-distribution and trajectory channels are computed and reported separately.

  4. 04

    Latch decides

    The threshold for the action's risk tier applies. Allow, escalate to a human, or deny — deterministically.

  5. 05

    Audit is written

    A hash-chained record captures the scores, the threshold, the calibration ID and the outcome.

  6. 06

    Recalibration

    Thresholds are re-fit on your own benign traffic on a schedule, and whenever the model version changes.

Why this one

What makes it hold up in production.

Deterministic enforcement

The gate is a threshold comparison in Rust with no allocator surprises and no model in the loop. Same input bytes, same decision, always — which is what makes it reviewable.

Calibrated on your traffic

Thresholds come from split-conformal calibration on at least two weeks of your own benign workload, so we can state a false-positive rate for your distribution instead of shipping a hand-tuned number.

Hard negatives from day one

A DBA running a legitimate destructive migration, your red team at work, an analyst reading a malware report — these are trained in as negatives. Without them a detector learns 'unusual' and floods the SOC in week one.

Honest about its bounds

Latent-space defences have a published evasion result: an attacker with weight access can optimise against a probe. We ran that attack against our own detector for the first time this month — a white-box gradient search evaded 14 of 16 held-out attacks it had been catching, against 1 of 16 for simply padding the payload with no optimisation at all. Early numbers, published anyway, because the alternative is a customer finding the bound before we do.

Read the measurement

Framework-agnostic by design

The gate sits at the tool-call boundary, not inside any one orchestration framework. We've proven the pattern live against real LangChain and CrewAI agents — the same enforcement layer, wired to whichever framework you already run.

Straight talk

What Interocept does not claim.

Security products earn trust by being specific about their limits. Three things you will never hear from us:

“Mathematically impossible to jailbreak.”

Determinism means the gate cannot be talked out of a decision. It does not mean an attacker with white-box access to the probe weights cannot optimise against it — our own measurement found a gradient-optimised suffix evading 14 of 16 held-out attacks the detector otherwise caught. That gap is exactly why enforcement never rests on detection alone: a shaky score gets escalated or denied, not trusted.

“Zero latency.”

Every check costs something. We hold ourselves to a specific p99 budget at the enforcement gate, we measure it rather than estimate it, and we will show you the benchmark and the method behind it.

“It would have stopped the incident in the news.”

Most publicised agent incidents involve closed-weight models on someone else's infrastructure, where no activation access exists. Those incidents motivate the threat class; they are not scenarios we retroactively claim to cover.

Who it's for

Teams that cannot hand context to a vendor.

  • Defense and intelligence programmes running agents on their own weights
  • Banks and insurers deploying agents against core systems of record
  • Healthcare and public-sector operators who cannot send context to a vendor
  • Any team whose agent holds credentials and can make an outbound call

Put a gate in front of your agent.

Tell us which model you run, where it runs and what it can reach. We'll walk you through what Interocept would and would not catch.