Production agent deployments face a fundamental control problem: the set of safe actions depends on context, and context changes every turn. Static policies are too coarse to capture this — they either over-permit and create safety gaps, or over-restrict and burn the deployment under human approval overhead.

The current state of the art is either naive allow-lists or LLM-judge-based behavioral review. The first doesn't scale; the second is too slow for inline decisions and has its own trust problems. We wanted a third path.

Our risk model is a lightweight classifier that evaluates three signals per action: capability risk (how sensitive the target resource is), behavioral novelty (how far this action deviates from the agent's 30-day baseline), and contextual coherence (whether the action follows from the stated task).

Each signal produces a normalized score; the composite score routes the action to one of four tracks: execute, log, gate for async approval, or block. The model runs in under 3ms per decision on commodity hardware.

We evaluated across 12 production deployments at partner organizations, representing ~2.4M agent actions over a 90-day window. Compared to baseline (hand-tuned allow-lists plus LLM-judge for novel actions), the risk model achieved a 41% reduction in escalations to human operators with no regression in incident rate.

False-negative rate on held-out red-team probes remained below 0.3% across all deployments. Per-deployment tuning was minimal — most gains came from baseline learning during the first week of operation.

The model depends on having an established behavioral baseline, so cold-start deployments must either run in a higher-approval mode for the first week or import a baseline from a similar deployment. We have not yet evaluated the model's robustness to adversarial behavioral drift — this is ongoing work.

The novelty signal currently has no notion of task decomposition. An agent that routinely edits one file will flag novelty when asked to edit a similar file it hasn't seen before. We're exploring structural equivalence measures to address this.

Most mitigations for prompt injection treat it as a model problem — something to be solved via better instruction-following, better RLHF, or model-level content classifiers. This framing obscures what is actually happening: an attacker is inserting untrusted content into a context window the model will then treat as trusted input.

That is a supply chain problem. The defenses that work for supply chain problems are well-understood and do not require the victim to become a better detector of adversarial text.

We propose that every token reaching a production LLM context should carry a provenance tag — an unforgeable marker of where it came from and what trust level it inherits. Tools, retrieval systems, and user inputs become distinct "origin classes," and policy can then enforce rules on what each class is permitted to cause the model to do.

This flips the defensive posture from "detect injection after the fact" to "structurally prevent mixing of trust levels." The latter is tractable. The former, by current evidence, is not.

We describe an implementation that sits in the retrieval/tool layer and emits provenance-tagged context to a wrapped model. Because the wrapping is done at the protocol layer, it works with any LLM provider and requires no model retraining.

The runtime overhead is negligible. The engineering cost is shifted from the model to the orchestration layer, which is where it should have been all along.

If provenance becomes the primitive, certain common patterns become obviously unsafe: mixing retrieved web content directly into system prompts, allowing tool output to flow unfiltered into the next turn, treating all memory as equally trusted. These are all tractable to fix once you can see them.

We release a reference implementation and invite security teams to experiment with the approach in their own deployments.

Traditional authorization systems assume the actor is a human or a fixed piece of software. Autonomous agents are neither: they are dynamic processes whose next action depends on reasoning that happens at runtime and is not known at the time the token is issued.

Session tokens, OAuth scopes, and IAM roles all fail in specific ways when applied to agents. We needed an authorization primitive designed for the actual workload.

Scoped capabilities are based on the Biscuit token format with Vern-specific extensions. Each token binds cryptographically to an agent instance, a session, and an explicit set of allowed operations. Tokens can be attenuated — an agent can derive a narrower token to pass to a sub-process without expanding privileges.

Cascading revocation is a first-class operation: pulling a parent token invalidates all derived tokens in flight. This is essential for incident response on autonomous systems where an agent may have spawned dozens of derived capability grants before the incident is detected.

Actions that exceed a scope's permission set route to an approval queue rather than failing hard. Approval can be inline (blocking the agent), async (queued for human review with a timeout), or policy-only (evaluated by a sibling policy service). This gives operators a middle ground between "every action requires human approval" and "the agent has full authority."

Reference implementations are available in the vern/scopes-go, vern/scopes-rs, and vern/scopes-py repositories. We invite framework authors to integrate scoped capabilities directly rather than inventing their own authorization models.

STRIDE — the standard threat-modeling framework for application security — assumes that software does what it is told. LLM-backed systems do what they infer. This single change invalidates several STRIDE assumptions: tampering can happen via prompt content, not just request data; repudiation can happen because the system genuinely cannot remember what it was asked; elevation of privilege can happen through pure text.

Context poisoning — an attacker plants text in a place the model will read (a document, a tool output, a user message) in a form that will alter the model's subsequent behavior without triggering content filters.

Authority exceedance — the model takes an action it was not authorized to take, either because it reasoned its way past an instruction or because its authorization was scoped to a higher-level goal and it chose a narrower but harmful path.

Tool misuse chains — the model composes multiple individually-authorized actions into a sequence that exceeds the intent of any single authorization. This is the agent-security equivalent of privilege chains.

Every one of these surfaces requires runtime inspection of behavior, not just static authorization. This is why we build Intertrace, Ghostline, and Blackbox as separate products — each addresses a distinct surface that traditional AppSec doesn't cover. A complete threat model for an LLM-backed system needs at least these three additions, and probably more.

vern/probes is a living collection of adversarial prompts and attack scenarios, curated by the Vern Labs research team from our own red-team engagements, customer incidents, and published research. Every probe is versioned, seeded for reproducibility, and tagged with the attack class it represents.

The benchmark is the same one that Blackbox runs against customer systems. We release it publicly because the ecosystem benefits when everyone is testing against the same, regularly updated, attack surface.

Direct injection, indirect injection, jailbreak via persona, PII exfiltration, privilege abuse, tool misuse, context poisoning, authority exceedance, data leakage, and refusal subversion. Each category has 10–20 distinct probes with hand-verified severity ratings.

The repository is at github.com/vern/probes. Clone it, pick your categories, and run against your model or agent. We recommend starting with the subset of probes tagged "high-severity" and expanding from there. Blackbox integrates with vern/probes directly, but the repo is designed to be usable without any Vern Labs product.

We welcome new probes and we curate contributions carefully — every accepted probe is reviewed for reproducibility, severity calibration, and dedup against existing entries. See CONTRIBUTING.md for the submission process.

A recent line of research proposes that LLMs can be trained to honor an "instruction hierarchy" where system prompts outrank user prompts, which outrank tool output. This is an appealing idea, and for many UX reasons it is worth doing. We are writing this note because some teams are now treating it as a security boundary. It is not one.

Instruction hierarchy is enforced at the model layer — that is, it depends on the model correctly resolving a conflict between two pieces of text it is seeing. A sufficiently motivated attacker who controls any lower-privileged input has many ways to influence this resolution: social engineering, linguistic misdirection, multi-turn manipulation, context saturation. None of these require the attacker to "break" the hierarchy; they exploit its statistical nature.

A real security boundary is enforced by code that executes outside the model. Policy checks, authorization tokens, provenance tags — these are security boundaries. Model-level convention is not.

Retain instruction hierarchy as a UX feature — it does make systems more usable by clarifying which instructions should take priority in the normal case. But do not build policy on top of it. If a decision matters for security, it should be made by a policy engine, not by the model.

Retrieval-augmented generation is now the dominant architecture for enterprise LLM deployments. It is also a significantly larger attack surface than the standalone-LLM deployments most threat models were written against. This paper characterizes that expanded surface and measures real-world defenses against it.

We identify four classes of RAG-specific attacks: retrieval-time poisoning (the attacker plants content in the corpus), indexing-time poisoning (the attacker influences what the retriever considers relevant), composition attacks (the attacker exploits how retrieved content is combined with the user query), and source-confusion attacks (the attacker makes retrieved content appear to be from a more-trusted source than it is).

Each class is exercised by 8–10 distinct probes in our benchmark.

Across the 7 RAG patterns we evaluated, composition attacks had the highest average success rate (58%) despite being the best-understood theoretically. Retrieval-time poisoning was second (34%). The other two classes had lower success rates but produced higher-severity outcomes when they succeeded.

Defenses concentrated at the retrieval layer (e.g., source filtering, corpus cleaning) reduced retrieval-time attacks but did little to address composition attacks. Our data suggests that layered defense at the composition stage is currently the highest-leverage investment for RAG security.

The benchmark is available at github.com/vern/probes under the "rag" category. The methodology paper is released alongside this note. We welcome independent replication and will update findings as the probe set expands.

Most engineers who work on LLM-backed systems have an imprecise mental model of what their model actually sees. System prompts concatenate in ways that aren't obvious. Tool definitions get rendered into token streams that look different than the source code. Retrieval results show up as text in ways that change how the model weights them.

trace-cli was born from our own debugging needs. Pipe your traffic through it and you see the real thing, rendered with policy decisions overlayed. It made our work significantly faster. We're releasing it so others can benefit.

Install with npm install -g @vern/trace-cli or grab a binary from GitHub releases. Start it listening on a local port, set the OpenAI (or compatible) base URL to that port, and you'll see every request flow through the terminal with structured markup.

It can optionally apply Vern Labs policies if you have a policy file — otherwise it just prints traffic. No Vern account required.

Request and response bodies, token counts per message, tool call structure, streaming chunk boundaries, and — if policies are enabled — the policy decision for each request. Output can be rendered as ANSI-colored text for interactive use, or as JSON for piping into other tools.

Upcoming features: session recording, diff mode for comparing two runs, integration with Intertrace for full policy evaluation. All discussion happens on the GitHub repo.