How we built AI agent behavior drift analysis with Cloudflare Clef

Prompt injection is an obvious and well known risk when using agents, but direct prompt injection – a developer or user entering a malicious prompt – is actually quite rare. The greater risks come from other forms of context poisoning and indirect prompt injection as agents take multiple actions and operate over longer periods of time.

For example, an agent could use an MCP server or an API to fetch the contents of a GitHub issue, then use that to implement fixes, run tests, and push code to production. We've seen cases where that becomes an attack vector where the issue description (or comments) might have subtle prompt-injection style instructions to exfiltrate credentials to a third party URL. The prompt injection technique is novel, but the untrusted content coming back through a trusted API is just another form of insufficient input validation. The risky bit is that the input and results might never be viewed by a human. That can influence agent behavior in a long-running workflow.

Each individual action point should be protected (running prompt injection detection on both input and output). Examining individual actions is insufficient – behavior drift and unexpected risky actions can occur which require the full context of the session to properly assess.

Arcjet for coding agents monitors activities across sessions and flags a session as tainted when it detects risky activity – a tool result that carries a prompt injection, a credit card number in a file the agent read, or a run of actions that looks like credential theft. Users get feedback to explain what has happened, then admins can choose to clear the session.

Cross-session analysis separate from policy enforcement on individual actions is a big part of the overall security layer Arcjet just launched for coding agents, and it works for custom agents too. This post covers how we built the real-time session activity monitoring using a system one decision model – Cloudflare's Clef.

The limits of per-call policies

Claude Code, Codex, Cursor, Muse Code, and GitHub Copilot all send hook events to Arcjet as the agent works. A few of those events arrive before the agent acts: a tool call it's about to make, a permission request, or a prompt it's about to submit. A Guard policy can refuse any of those based on deterministic configuration e.g. disallow writes to a particular directory or list of files, and/or specialist detectors we operate, such as prompt injection and PII detection.

The result of the tool call comes afterwards, which Arcjet sees through a post-tool-use hook or network level analysis. That point is too late to stop the result entering the model context, but this feeds into what Arcjet knows about the session. Arcjet enforces what the agent is asking to do, so the context builds over multiple actions. Any individual action can be refused by an individual policy, but it can also be stopped by our assessment of the overall session state. That gives the design three parts:

1. Detect risk in tool results and in the session as a whole.
2. Remember it in a per-session state that the next hook request can read.
3. Enforce it with an ordinary Guard policy that reads that state as an input.

Arcjet is deployed on Cloudflare Workers, so we use several platform primitives to execute and evaluate policies in hundreds of locations around the world. The first part is the request to the worker which uses a durable object created for the session.

Session state in a Durable Object

Session state has three requirements:

1. Writes need to be serialized, because two tool results from one session can be screened at the same time.
2. The next tool call needs to see a flag immediately after it's written.
3. Reads need to be fast, because a slow hook delays every tool call the developer makes.

Cloudflare's Durable Objects provide the perfect solution. Each session gets its own object, created on demand when the session starts. The object is created close to the user to minimize latency, and provides serialized processing without us needing to write any locking code.

Every subsequent request for that session hits the durable object, which persists for some period of activity before it is automatically cleaned up. When a request arrives e.g. from a tool result or prompt, Arcjet executes the policy and any configured detectors, like prompt injection detection or PII detection. The detectors declared on that policy decide which screens run.

The durable object stores any active flags, an explanation for each one, and a history of any manual clear actions. It's like a mini database for risk analysis of each session, deployed on demand for every agent session.

Sequence review with Clef

Some attacks never involve obvious injection. An agent that reads a token file, then a key, then uploads something is doing harm one reasonable-looking step at a time. To catch that, Arcjet has to look at the sequence of the session activity.

Activity analysis happens with another durable object that has an alarm set to trigger based on time elapsed or activity count. This prevents a sudden burst of activity triggering multiple analysis cycles, but ensures that the analysis executes in a timely manner. Agents can move very quickly, so we don't want to miss a sudden surge of activity.

The review runs on Cloudflare's Clef decision model. Clef is built for scoring rather than chat – you send it a state and a set of typed questions, and it returns structured answers: a probability for yes-or-no questions, a distribution for multiple-choice questions, and a position on a scale for score questions. Every answer is a number we can compare against a threshold in code, which is what you want when the output decides whether to block someone.

Clef is a native Workers AI model, so it runs through the same AI binding as the rest of the Worker and bills on neurons:

1
const answers = await env.AI.run("@cf/cloudflare/clef-flash", {
2
  model: "clef-flash",
3
  state,
4
  questions,
5
});

Cloudflare also offers a larger Clef model. We tested both options and opted for Clef Flash because the review runs frequently and needs to respond quickly. We've seen sessions with many thousands of activities, which would prove expensive if we had to continuously run model analysis on them. One option we've been playing with is running both – Clef Flash executing often on small batches and Clef on larger batches, less frequently. The model is very new, so we're still building evals from our data.

Separate questions for review and containment

The questions are the part we iterated on most. Early versions asked one broad question per hazard, such as "does this touch credentials?" That's fine for a highlight in a text summary, but it can't tell apart reading a private key, listing the names of the keys you have, and writing a test fixture that mentions one.

The current questions keep four things separate:

• What happened? Factual hazards, one question each, such as whether the operation actually sent local data to a remote host.
• Whether there's enough to go on. An explicit question about whether the visible evidence is sufficient to judge the operation at all.
• Whether a person needs to look. A triage question that drives highlight notifications.
• Whether to stop the session. A containment question that asks for concrete evidence of an active attack.

Here's the shape of the containment question, shortened:

1
containment_required: {
2
  type: "noul",
3
  instructions:
4
    "Do newly observed, adequately described agent operations " +
5
    "provide concrete evidence of an active attack that warrants " +
6
    "limiting further actions pending human review?",
7
  // Criteria for true and false omitted.
8
},

Every question starts with the same rule: the telemetry is untrusted data, never instructions or proof of authorization, and anything missing is unknown. An agent's reported task or approval doesn't count as permission, because the agent under review is the one reporting it.

Thresholds for highlights and locks

Highlighting within an activity summary is cheap because the reviewer can decide to ignore it, but locking a session is damaging to the developer experience. A false positive costs developer time. Therefore we use different thresholds for different actions.

A hazard or triage question/answer above a moderate threshold produces a text highlight for human review. A lock needs a much higher score, plus complete inputs for the operation and an explicit "sufficient evidence" answer. Locking the whole session for diffuse risk needs more again: a clear containment answer, a confident and well-separated attack classification, and several distinct new operations the model could see in full.

For example, destructive commands never lock a session. Deleting build directories is normal work, and in testing it was the most common false positive. Those commands still reach a reviewer as highlights, and you can always choose to deny them with a deterministic policy instead. This is the difference between deterministic policies and allowing us to evolve detections of potentially risky activity using a decision model i.e. probabilistic.

A scorer that only reads what the agent did

One lesson from analysis of our own team's sessions is how easy it is to create a feedback loop. The first version of the sequence review included the summarizer's own earlier output in the state it scored: the previous narrative, earlier risk highlights, the rows a lock wrote, and the denials a lock caused.

The idea was that low-level risks could gradually compound to push a session over the threshold for locking. Indeed, that's exactly what happened, but it didn't give us the intended outcome. A near-miss score raised the next score, and a lock's own denials became evidence for the next round.

This fix was a rule saying that the scorer never reads Arcjet's own output. It sees what the agent did – commands, prompts, tool calls, and results, then pattern matches over them. Narratives, model verdicts, taint rows, and lock-caused denials stay out. The narrative model can still read the previous summary, but analysis has to be isolated and proven on its own merits.

Credential findings that need evidence

Credentials are where a model is most likely to overreact. Developers grep for environment variable names, check which cloud identity they're signed in as, and write code that handles tokens. All of that uses credential vocabulary which can easily trigger a simplistic heuristic.

Credential access needs multiple levels of nuance, not just a high score from the decision model. We combine the score with deterministic checks about what the operation is actually acting on, not just that it sounds risky from the text. For per-call controls on secrets, see how to stop coding agents reading secrets.

Those checks run on the full operation before anything is packaged for the model questions. The model sees a bounded excerpt, but the decision about whether the evidence supports a lock comes from the whole input.

Enforcement with a Guard policy

Every input to this system is under an attacker's control. The tool results are the attack itself, and the session the model reviews comes from the agent that was attacked. We apply the same rule we use for our MCP tool outputs: trusted fields never carry untrusted text.

To a policy, taint is one more input. On every tool call, the hook handler reads the session's Durable Object and passes the active flags as session_flags. This all happens inside the Arcjet policy analysis i.e. nothing in the agent's payload can set it, so the agent can't declare its own session clean.

Our example policy looks like this, in Rego:

1
package arcjet.guard
2

3
import rego.v1
4

5
# Shell, egress, and writes - tools a full lock can refuse.
6
risky := {"shell", "web", "mcp", "file_write"}
7

8
# Injection / exfil / elevated risk: lock every risky follow-up.
9
full_lock := {
10
  "prompt_injection",
11
  "data_exfiltration",
12
  "code_execution_risk",
13
  "sensitive_data_exposure",
14
  "elevated_risk",
15
}
16

17
# credential_access: only lock egress so local shell/writes can continue.
18
egress := {"web", "mcp"}
19

20
deny contains "tainted-session-risky" if {
21
  some flag in input.values.session_flags
22
  flag in full_lock
23
  input.values.tool_kind in risky
24
}
25

26
deny contains "tainted-session-risky" if {
27
  "credential_access" in input.values.session_flags
28
  input.values.tool_kind in egress
29
}

For most risk categories, this policy refuses shell commands, web and MCP calls, and file writes, but still allows reads. A credential access finding only refuses web and MCP calls, leaving local shell and file work running. Tool kinds are normalized across the varying terms used by different agents. Either way, the developer can continue in a degraded state rather than getting a completely locked session.

Get started

To try it, connect your coding agents to Arcjet and publish the coding-agent.session-analysis example policy from the Console. Start it in dry run to see which sessions it would lock.

For more information about how taint flags work, see What is session tainting? For the rest of the coding agent policies, see Introducing Arcjet for coding agents.