Dev.to post blames Korean bank breaches on missing agent controls, including no isolation and session-wide approval

The post labels its reconstruction as inference. It introduces the three attack phases with "Here's what the plumbing likely looked like" ^[1], and the lateral-movement section says audit logs "(if present)" did not trigger alerts ^[2]. The CrowdStrike finding is secondhand: the post relays it, and the excerpt we read does not link a CrowdStrike report. The "first documented case" label is the author's own ^[14].

Here is what the post's sample class does when called. `log_tool_call` adds one to a counter, appends the tool name to a list if `is_privileged` is true, writes a structured log line, then checks the list length ^[3]. When the list holds more than five entries it logs a warning and raises an exception, with a comment saying to pause the agent and require human approval ^[4]. The sixth privileged call is the one that trips it ^[8]. The caller supplies `is_privileged`, and it defaults to False ^[5].

In our view this is a logging aid with a brake attached, and the brake sits inside the thing it is meant to stop. The agent loop reports its own privilege level. The post says tool execution happened in the same security context as the host ^[16]. A process an adversary controls can pass False, skip the call or catch the exception. In this incident, per the post, the session histories were on the attacker's infrastructure ^[11], so the attacker would have been the one deciding whether to install the guard.

The counters are instance attributes set to zero in the constructor, one object per agent and session ^[3]. A fresh session starts clean. We would put the limit where the agent cannot edit it: a credential broker that issues a short-lived credential per call and refuses the sixth one, whatever the agent reports. That costs a service to run and a policy to maintain.