The Session Is the Tell
BYOK told you whose key runs the model. This is the question for what ends up on the machine where the agent runs.
A while back I wrote that one 30-second question sorts AI vendors faster than any demo: do you mark up my LLM tokens? BYOK is the tell — it shows you whether a vendor’s economics are aligned with your bill or against it.
Agents need a second key question, and it’s sharper, because this one isn’t about your invoice. It’s about what the vendor leaves on your machine.
Here’s the setup. An agent only earns its keep when it runs where the work actually lives — behind the firewall, in the VPC, on the operator’s laptop with the logged-in sessions. I argued the case for that in the companion to this piece. But the moment an agent runs there, something has to authenticate it to your systems. So ask the vendor one question:
“When your agent runs on my machine, what credential sits on the box — how long does it live, how tightly is it scoped, and can you revoke this one agent without breaking the rest?”
One question. Three answer shapes. Each tells you something different.
Answer one: “There’s an API key — a service account — on the machine.”
A long-lived credential, broadly scoped, sitting in the agent’s environment. It works flawlessly on day one. It is also a time bomb. One prompt-injected ticket, one copied disk image, one leaked environment file, and whoever has it holds the keys to everything that credential can reach. Worse, it’s usually a shared key: the vendor can’t revoke this one agent without rotating the credential for every agent at once. A key that lives long, scopes wide, and can’t be killed individually is a vendor telling you they couldn’t work out how to govern the agent — so they trusted your machine instead.
Answer two: “It’s stored encrypted, in a secure vault on the device.”
The softer form of answer one, and the more common one, because it sounds responsible. But encryption at rest is not revocability, and it is not scope. The agent still decrypts that key to use it, which means at runtime the keys to everything are live in the process — exactly where a compromised agent can reach them. You’ve put a lock on the god-key and left the god-key on the box. The encryption protects you from a stolen hard drive. It does nothing about the thing you actually fear: the agent itself being turned.
Answer three: “The machine only holds the agent’s own session. The real keys stay in our control plane.”
Now the shape is different. The device holds a session, not a credential to your systems: a short-lived access token measured in minutes, a rotating refresh token, scoped to less than the person who switched the agent on, and revocable for that one agent in a single click. The credentials that actually touch your CRM, your inbox, your spreadsheets never leave the control plane. The agent doesn’t hold them — it asks the plane to act, and the plane holds the keys and the gate.
This is the same pattern your phone already uses. It doesn’t store your password; it holds a token that expires and can be revoked from one device without locking you out of the others. We’ve known how to do this for authentication for a decade. Agents are where it suddenly matters again.
Why the session is the substantive litmus
Three reasons.
One. It bounds the blast radius. A long-lived broad credential on the device makes the worst case unbounded — one bad input and the agent is acting with the keys to everything. A short-lived scoped session makes the worst case small and self-healing: the token expires on its own, and it could never do more than the one human it stands in for.
Two. It tests revocability that’s real. “We can revoke access” means nothing if revoking means rotating a shared key and logging out every agent you run. Per-agent revocation — kill this one, the rest keep working — only exists if each agent carries its own session. Revocability that isn’t per-agent isn’t revocability; it’s a fire alarm wired to the whole building.
Three. It reveals where governance lives. If the keys sit on the device, the agent acts unilaterally and you are trusting the box. If the keys stay in the plane and the agent has to ask, every consequential action routes through a place that can check policy, require approval, and write an immutable log. The session is how the companion piece’s claim — trust the device, govern the surface — actually holds: the device earns trust precisely because it holds nothing worth stealing.
What to ask, and what each answer means
Use this in your next agent-vendor call. 30-second exchange.
You: When your agent runs on my machine, what credential is on the box — how long does it live, what’s its scope, and can you revoke this one agent without affecting the others?
If they say “a short-lived, scoped session; the real keys stay in our plane; yes, one click”: governed by design. Continue on substance.
If they say “an API key, but it’s encrypted at rest”: a god-key on your box with a lock on it. Note it, and treat the agent as ungoverned.
If they say “it depends” or “let me check with engineering”: they don’t know what’s sitting on your machine. That is the answer.
If they pivot to “but we’re SOC 2 / we encrypt everything”: note the deflection. Ask again — what credential, how long, what scope, revoke per agent?
Why I’m writing this
JieGou’s agents hold only a session. An operator enrols one with a single-use code; the machine gets a short-lived access token plus a rotating refresh token in the OS keychain, scoped below the person who turned it on, revocable for that one agent in a click. The credentials that touch your systems stay in our control plane — the agent asks the plane to act, and the plane holds the keys and the gate.
That is more work than dropping a service-account key on the box, and it gives up the easy demo where the agent “just works” because it’s holding everything. We think it’s the only shape that lets an agent run where your work lives without becoming the thing your security team has nightmares about. The framing — the session is the tell — holds whether or not you ever buy from us.
BYOK told you whose key runs the model. The session tells you whether a vendor can be trusted to run on your machine at all. Don’t ask whether the credential on the box is encrypted. Ask whether it’s even there.