<?xml version="1.0" encoding="UTF-8"?><rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Chad Norman: notes</title><description>Short notes and links from Chad Norman.</description><link>https://chadnorman.fyi/</link><language>en-gb</language><atom:link href="https://chadnorman.fyi/notes/rss.xml" rel="self" type="application/rss+xml"/><item><title>Your coding agent can hold the lethal trifecta too</title><link>https://chadnorman.fyi/notes/lethal-trifecta/</link><guid isPermaLink="true">https://chadnorman.fyi/notes/lethal-trifecta/</guid><description>Simon Willison&apos;s lethal trifecta applies to the agent on your laptop. Three questions to ask before you add the next MCP server.</description><pubDate>Fri, 25 Sep 2026 00:00:00 GMT</pubDate><content:encoded>&lt;p&gt;Link: &lt;a href=&quot;https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/&quot;&gt;https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/&lt;/a&gt;&lt;/p&gt;&lt;p&gt;Simon Willison’s &lt;a href=&quot;https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/&quot;&gt;lethal trifecta&lt;/a&gt; is the best one-line test I know for an AI agent. An agent is exposed when it has all three of: access to private data, exposure to untrusted content, and a way to communicate externally. With all three, anyone who can put text in front of the model can ask it to send your data out, and it may well do it.&lt;/p&gt;
&lt;p&gt;I used it for business workflows in &lt;a href=&quot;https://chadnorman.fyi/writing/least-autonomy-ai-workflows/&quot;&gt;the least-autonomy post&lt;/a&gt;. The same test applies to the coding agent on your own machine, and that’s where it’s easiest to miss.&lt;/p&gt;
&lt;p&gt;A coding agent already reads your repos, your &lt;code&gt;.env&lt;/code&gt; files and whatever your shell can reach. That’s the first leg. Add an MCP server that reads GitHub issues, web pages or email, and you have the second: anyone can file an issue. Add web fetch, a tool that opens pull requests, or plain &lt;code&gt;curl&lt;/code&gt;, and you have the third. Willison’s post cites a real case: the GitHub MCP server read a malicious public issue and leaked private repo data through a pull request.&lt;/p&gt;
&lt;p&gt;Before you add the next MCP server, ask three questions:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;What private data can this session reach?&lt;/li&gt;
&lt;li&gt;What text in this session did someone else write?&lt;/li&gt;
&lt;li&gt;What can this session send, post or fetch?&lt;/li&gt;
&lt;/ol&gt;
&lt;p&gt;If all three have answers, take one away. Use a separate session for untrusted content, give it no secrets, or block outbound requests. Guardrail products that promise to catch “95% of attacks” don’t fix this. As Willison puts it, in web application security 95% is a failing grade.&lt;/p&gt;
</content:encoded><category>LLM security</category><category>AI agents</category></item></channel></rss>