The Boundary a Local AI Model Won’t Give You

There’s a belief in the self-hosted AI world that if the model runs on your own hardware, your data is safe. Your prompts never leave the building, so the exposure is closed.

The prompts, yes. The credentials, no. And once an agent is touching real accounts and real money, the credentials are the part that matters.

I ran into this designing a workflow that lets an agent log into utility portals, download the bills, and post them to QuickBooks — the kind of dull, repetitive month-end work that’s the whole point of having an agent. The model behind it is self-hosted. Nothing about the reasoning leaves the network. And none of that helped with the question that actually kept me up: what stops a compromised agent session from reading the credential store directly, with no human anywhere in the loop?

Local inference controls what flows into the model. It says nothing about what the agent does with the result. When an agent authenticates to a portal, moves a payment, or reads a secret, those actions travel outbound to systems you don’t control — regardless of where the model did its thinking. An ungoverned agent against a local model has the same credential exposure as one against a cloud API, because the risk lives in the action layer, not the inference layer.

That’s the part the “we run it locally” reassurance skips.

Here’s the shape of the problem. A self-hosted agent typically ends up holding four ordinary capabilities: a way to read stored credentials, a browser it can drive, network access to financial portals, and a memory that persists across sessions. Individually, none of them is alarming. Together, with no boundary between them, you have something that can authenticate to a bank-adjacent account, execute a transaction, and remember it did — with no human present at any step. And if that session is ever compromised — a bad tool call, a prompt injection buried in portal content, a poisoned dependency — whoever inherits the session inherits everything the agent could reach. If the agent could reach the credential store without a scoped boundary, so can they.

The uncomfortable version: when the human operator and the agent share the same access surface, a credential audit can’t even tell you which one read a secret, or when, or why. For a practice holding clients’ financial credentials, that ambiguity isn’t a technicality. It’s the liability.

None of this is exotic. It’s the default state of most agent deployments, because the tools ship with strong process isolation — sandboxed filesystem, dropped privileges, no telemetry — and no access governance. Those are different problems. Process isolation keeps the agent tidy inside its box. It says nothing about whether the agent should be able to reach the box marked human only.

The fix I landed on is almost aggressively unclever: a physical key.

Most governance frameworks already talk about keeping a human “above the loop” — the agent proposes, a human approves, the agent executes. The trouble is that when that boundary is purely logical — a flag, a role, a policy file — a compromised session can often reach the thing that sets the flag. A hardware key makes the boundary physical instead. The credentials that let a human change scope, rewrite the workflow, or edit the policy that constrains the agent all sit behind something you have to physically touch. The agent gets scoped, read-only, logged access to exactly what it needs. Everything a human should own — widening that scope, changing the rules, escalating access — requires the key in hand.

It doesn’t restrict what the agent does inside its authorized lane. It makes the edges of the lane unmovable without a person physically present. A compromised agent can still misbehave within its scope — that’s a separate control — but it can’t quietly promote itself to human-tier access, because that access doesn’t exist without the hardware.

Two things this bought that I didn’t fully expect. The audit trail gets honest: every human-tier action carries proof of physical presence, so “was this a person or the agent?” stops being a guess. And the boundary composes — because the key gates the access, not the agent, the same protection covers whatever agent you run next without rebuilding it.

I want to be careful not to oversell it. A hardware key is one control, not a security program. It doesn’t stop a scoped agent from doing something dumb within its scope, it doesn’t fix a bad policy, and there’s a real operational tax — you need a second key enrolled and stored offline, and a documented way in when the primary fails, or you’ve built a very secure way to lock yourself out. Those are the honest costs.

But for a self-hosted agent operating against real financial accounts, a physical boundary between what the agent executes and what only a human should change isn’t a nice-to-have. Running the model locally was never the thing protecting you there. This is.

There’s no undo button for a breach. The boundary has to exist before the session runs, not after.

The physical key is one control inside a larger trust layer — the append-only log, the policy gate, the approval step that all sit under an AI that touches money. I wrote about that whole architecture separately.

This is part of how we think about governing AI that touches money — the layer beneath our method.