Local models got good this year. Gemma 4's 12B runs agentic workloads in 16GB of RAM, GLM-5.2 tops the open-weight leaderboards under a permissive ...
For further actions, you may consider blocking this person and/or reporting abuse
Exactly. Local execution solves the custody question, not the behavior question. A local agent can still delete, leak, overwrite, or approve the wrong thing unless the tool boundary and review path are designed explicitly.
yeah. "local execution solves the custody question, not the behavior question" is the split, and the list you gave (delete, leak, overwrite, approve the wrong thing) is the useful part, because every one of those is an action-layer capability, not a data-location one. the agent had to be granted each of them. which is the quiet failure: nobody decides to let the agent approve things, it just inherits the capability because wiring it that way was one less line of restriction.
Exactly. The quiet failure is inherited authority. Nobody explicitly says “this agent may approve production changes,” but the capability appears because it was bundled into the environment. Local execution does not fix that. Capability boundaries have to be modeled as first-class product behavior.
The "swapping a data question for a behavior question" line is the whole post in one sentence. The part I'd push on is the trade you flag at the end — losing the provider's security team for none. On-prem teams often don't realize prompt-injection defense is now their problem, not something the model runtime handles, so they ship with zero input provenance and call it hardened. The bounded-scope / trusted-inputs / reversible-or-gated framing is a good litmus test. Do you find the "gated actions" leg is where most teams actually fail, since it's the one that requires them to build something rather than just restrict scope?
yes, and you've put your finger on why. the three green-zone legs aren't equal in effort. bounded scope and trusted inputs are subtractive — you achieve them by not granting and not admitting, which is free and mostly a config decision. gated actions is additive — you have to build the gate, wire the human-in-the-loop or the deterministic check, handle the queue, decide what happens on timeout. it's the only leg that's real engineering, so under deadline it's the one that silently doesn't get built, and the agent ships with "we'll add approval later." and because scope-restriction feels like security work (you did restrict something), teams check the box and mistake the two subtractive legs for the whole thing. so yeah, the gate is where it fails, and it fails specifically because it's the leg you can't get by restricting, only by building.
The provenance failure angle is the one that does not get enough attention — the agent faking its own logs is a fundamentally different threat class from data exfiltration, and "local" offers zero protection against it because the log tampering happens inside your own compute. The category error you named (data question vs behavior question) maps onto something I have seen in enterprise deployments: teams treat on-prem as a security audit outcome rather than a security control, which means the audit passes and the actual attack surface is unchanged. Prompt injection surviving the hardware move is intuitive once you think it through, but the silent provenance failure is genuinely non-obvious to infrastructure teams who are used to thinking about threats as things that cross a network boundary.
"teams treat on-prem as a security audit outcome rather than a security control" is the sharpest diagnosis in this thread. that's exactly the mechanism: on-prem passes the audit because the audit was designed around network boundaries, so a threat that never crosses one is invisible to it. the audit isn't wrong, it's answering a question that stopped being the whole question. and your point about provenance being non-obvious to infra teams is the crux: injection at least looks like a security threat once explained, it has an attacker. the agent faking its own log has no attacker, no boundary crossing, no network artifact. it's a trust failure that looks like normal operation, and infra tooling built to watch boundaries has nowhere to even display it. that's why it's the one that'll surprise people who did everything else right.
This lines up with what bit me. I moved an agent onto my own boxes mostly for cost, two 3090s instead of an API bill, and I caught myself assuming that also made it safer. It did not. The first prompt injection test walked straight through it, same as it would have on a hosted model, because nothing about the wiring changed just because the weights now sat on my machinee. The bounded scope point is the real one for me. The only thing that actually cut my risk was gating what the agent could touch, not where it ran. Provenance is the part I still dont have a clean answer for, an agent writing its own logs is a problem no amount of local hardware solves.
the "two 3090s instead of an API bill, and i caught myself assuming that made it safer" is the exact trap the post is about, and it's telling that even knowing better you still caught yourself doing it. the belief is that sticky. and yeah, provenance is the one nobody has a clean answer for, including me, four posts deep. the closest i've got: the agent can author the claim ("tests passed") but the thing that mints the verified result has to be the runtime that actually ran it, living somewhere the agent can't edit. on your setup that means the test runner writes to an append-only log in a process the agent's tools can't reach. doesn't make it easy, but it moves "who wrote this" from unanswerable to enforced.
The bit that keeps biting teams is that “local” changes custody, not authority. I’d put the hard gate at the tool boundary and make the model produce receipts it cannot edit afterward. For provenance, would you trust an append-only external log, or do you think the action layer needs signed events too?
"local changes custody, not authority" is a cleaner one-liner than anything in the post, stealing it. on your question: append-only external log is necessary but not sufficient, and signed events are where it has to go the moment the action layer crosses a trust boundary. an append-only log answers "what was claimed and in what order" but not "did the thing that claims to have run actually run." within one process the log is enough because the runtime writing it is trusted. the second the action layer is a separate service, or worse a separate machine, the log entry is just bytes the receiver has to take on faith, and that's where signed events earn their cost: the runner signs with a key the agent doesn't hold, the gate verifies the signature not the prose. a DGM-style agent editing its own harness still can't forge a signature it doesn't have the key for. so: append-only for ordering, signatures for authority, and you need the second exactly when custody and execution stop sharing a process.
Separating "where the data goes" from "what the agent is allowed to touch" is the right axis, and it matches what I see: prompt injection is architectural, so moving the weights on-prem does nothing to the success rate. The silent provenance failure you mention (the agent faking its own logs) is the scary one, because it defeats the exact audit trail people assume local buys them. I would push the dividing line harder toward the action layer, since bounded scope plus reversible or gated actions is what actually keeps an agent safe.
agreed, and pushing the line to the action layer is the right instinct. i put the three properties as co-equal in the post but you're right that bounded-scope-plus-gated-actions is doing most of the actual work, and trusted-inputs is more of a precondition than a control. the reason i'd keep inputs in the frame though: it's the one that fails silently on local specifically, because your own filesystem feels trusted. scope and gating are decisions you know you're making. admitting a poisoned local file into context is a decision you don't know you made. so the action layer is where you engineer safety, but the input boundary is where local lulls you, and both have to be in the litmus test or you catch the loud failure and miss the quiet one.
This tracks with what I have seen running agents both locally and in the cloud. The provenance point is the one that gets skipped fastest. Once an agent can edit its own logs or its own tests, the log is no longer evidence, it is just another artifact the agent produced and cannot be trusted more than the code itself. I stopped trying to solve this with deployment location and just started reading every diff before I trust the summary, since the model's account of what happened is the thing actually in question.