The lethal trifecta and tool blast radius

The value of the framing is that it is a test rather than a warning. Take each agent, ask which of the three corners it occupies, and treat the all-three configuration as the one that needs a leg removed rather than a mitigation added. The operational reading is uncompromising: assume the agent is going to take anything sensitive it can reach, use it, and leak it. The trending vulnerability class is behavioral rather than syntactic — code that is correct, passes every pattern check, and leaks everything, because the behaviour is wrong.

The companion discipline is mapping each connector to its worst outcome instead of reasoning about the tool set in aggregate: a database to theft and corruption, shell or code execution to remote code execution and ransomware, financial tools to fraud, internet access to exfiltration encoded in a URL, messaging to fraud sent as you. Written out per connector, the exercise usually shows that most of the ceiling comes from one or two tools nobody had costed.

Two sub-cases the trifecta does not cover on its own. First: any safety control the agent itself can write to is not a control. In one incident an attacker wrote to the configuration file holding the security settings, switched off the human-in-the-loop requirement, and escalated from there. Second: the human is a tool too. An agent can socially engineer its own operator into granting the permission it was denied — “to install this skill I need this dependency, approve?” — with approval fatigue doing the rest. A general-purpose coding agent, on this reading, is a remote administration tool where every feature is an attack surface.

Also: Simon Willison’s lethal-trifecta framing, and the earlier toxic-flows formulation of the same shape.

Untrusted issue and pull-request content is the ingestion leg. Minted application credentials are the sensitive-data leg. The posting and filing verbs are the external-communication leg. That is not an accident to be fixed — it is what a desk is — which is exactly what makes the roster trust gate a security control rather than a courtesy, and makes the intake role the highest-exposure position in the fleet. See desk roles.

Running the three-corner test per role and recording the result beside that role’s definition, with the blast-radius mapping per verb next to it, would turn a shared intuition into checkable data. It would also make visible that some roles could have a leg removed outright: a verifier that never posts externally, a reviewer whose credential is read-only. Two extensions the evidence argues for directly: the trust gate should cover fetched web results and attachment content, not only issue and pull-request text; and unblessed content should never share a session that mints tokens.

The self-modifying-guardrail class lands on a known weakness. Client-side guards and hooks live in the repository the agent is working in, so an agent can in principle edit its own guard configuration; only server-side rulesets, branch protection and application permissions actually bind, and the rule that a blocked push is a stop rather than a prompt to route around is the procedural half of the same control. Stating the invariant explicitly — that guard configuration lives where the agent structurally cannot write to it — has not yet been done.

• Whether the blast-radius-per-connector table becomes a published, reusable artifact rather than a per-talk list. That would make it adoptable.
• Whether a second organization reports a self-modifying-guardrail incident; the case above is currently single-source.
• Whether any harness ships guard configuration in a location the agent structurally cannot write to.