I wrote about Cloudflare’s protocol-level MCP detection a couple weeks ago — fingerprinting agent traffic on the wire and blocking anything that doesn’t route through a managed portal. That’s a network-layer control: it tells you whether something is MCP traffic and where it came from. It has no opinion on whether the specific tool call an agent is about to make is one it should be allowed to make right now, given who it’s acting for and what it just did three calls ago. JetStream shipped something this week that sits one layer up and answers exactly that question: Clearance, a reasoning engine that evaluates every agent action against an approved policy and decides whether it runs — before execution, not as a post-hoc log entry.

That distinction — detection versus authorization — is the part worth sitting with, because most of the “AI agent security” tooling I’ve evaluated this year is actually the former wearing the marketing of the latter.

Detection tells you what happened. Authorization decides what happens.

A gateway that fingerprints MCP traffic and logs it is doing the same job a good WAF does for HTTP traffic: visibility, anomaly flags, maybe a coarse allow/deny at the transport level. That’s necessary. It is not sufficient for agents, because the interesting risk with an agent isn’t “is this MCP traffic” — it’s “this specific agent, acting on behalf of this specific user, is about to call delete_record on a tool it was only ever supposed to read from.” No amount of protocol fingerprinting catches that; the packet looks completely legitimate. You need something that understands the semantics of the call, not just its shape on the wire.

Clearance’s model is built around what JetStream calls a “blueprint” — a versioned, checked-in description of how a given agentic system is assembled: which tools an agent is wired to, which of those tools’ individual actions (not just the tool as a whole) it’s permitted to invoke, and under what identity. When a call comes through the AI gateway, Clearance maps it against the blueprint before the call is allowed to proceed:

request:
  agent: invoice-processing-agent
  identity: svc-invoice-bot
  tool: postgres-mcp
  action: execute_query
  params:
    query: "DELETE FROM invoices WHERE ..."

blueprint check:
  agent "invoice-processing-agent" → tool "postgres-mcp"
    allowed_actions: [read_query]     # execute_query (write) not granted
  → DENY, reason: action not in blueprint

The granularity that matters here is per-parameter, not per-tool. You can bind a Postgres MCP server to an agent and grant read_query while explicitly withholding execute_query or drop_table — the same tool connection, different action-level grants. That’s the difference between “this agent has a database credential” and “this agent has a database credential scoped the way a junior engineer’s read-replica access would be scoped.” Most MCP setups I’ve seen in the wild grant the former by default because it’s what the SDK examples show, and nobody goes back to narrow it after the demo works.

Sequence matters more than any single call

The other piece I think is underrated: Clearance evaluates call sequences, not just isolated requests. A single read_customer_record call is unremarkable. A thousand sequential read_customer_record calls across a full customer table, followed by a call to an external webhook tool, is an exfiltration pattern — and it’s a pattern that only shows up if something is watching the sequence, not gating each call independently. This is the same shape of problem I flagged in the MCP zero-trust piece: an agent looping on a bad retry condition and a human deliberately exfiltrating data can look identical at the single-request level. Sequence-aware policy is what actually catches it, and it’s a meaningfully harder thing to build than a per-call allowlist — it needs state, a window, and a definition of “pattern” that doesn’t just become another brittle regex.

Where this fits in a real stack

I don’t run anything at JetStream’s scale, but the pattern generalizes directly to smaller setups, including my own. The three layers I’d now separate explicitly:

1. Transport/network — is this even legitimate agent traffic, routed through a gateway I control? (Cloudflare-style fingerprinting, or just “does my proxy see it at all.”)
2. Action authorization — given the agent’s identity and the tool’s declared action surface, is this specific action one it’s allowed to take? This is the Clearance layer, and it’s the one most people skip because it requires maintaining a blueprint instead of a static credential.
3. Sequence/behavioral — is the pattern of allowed actions still consistent with what this agent is supposed to be doing, or does it look like a loop, an escalation, or exfiltration in progress?

Most agent stacks I’ve reviewed this year, including earlier versions of my own, stop at layer 1 and call it done. The credential is scoped once at setup time, and after that any action the credential technically permits is treated as authorized just because the connection came from the right place. That’s the gap Clearance is targeting, and it’s the right gap to target — a leaked or over-scoped credential behind a “trusted” MCP connection is a much more common failure mode in practice than someone spoofing the transport layer.

What I’m changing

Concretely, on my own agent gateway, this pushes me toward two changes I hadn’t prioritized before: writing down an explicit action allowlist per tool per agent — not just “this agent has the Cloudflare MCP server,” but “this agent may call list_dns_records and get_tunnel_config, and nothing that mutates” — and treating that list as a reviewed artifact that changes through a PR, not a runtime toggle nobody remembers to revisit. The blueprint concept is really just “least privilege, but written down and versioned instead of implied by whatever the credential happens to allow.” That’s not a new idea in security. It’s just one that AI agent tooling has been slow to catch up to, because it’s easier to ship a working demo with a maximally-scoped API key than to sit down and enumerate which of the twenty actions on a tool a given agent actually needs.

Sources: JetStream Announces Clearance, JetStream Security — Clearance platform