[kfajdsl]

I mean that you should only give the LLM the same privilege as whoever the source of your untrusted input is has. For the support agent example, it should only be able to access records related to user it's talking to, and only be able to do mutations that the user has permissions to do anyways. Though I've hated all the chatbot support "agents" I've interacted with so far, so please don't actually do this unless you have some secret sauce to make it not horrible.

I agree that for most tasks a pre-defined workflow with task specific LLM calls sprinkled in is a much better fit.

However, I really like agents with tool use for personal use (both programming and otherwise). In that case, the agent is either sandboxed or I approve any tools with the potential to do damage.

For the example of the Supabase MCP, it still seems pretty useful when limited to a test environment or read-only access to prod - it's a dev tool. Since it's a dev tool, the user needs to actually know what its doing. If they have no clue but are still running it on prod data, they have no business touching it or frankly any other dev tool. I class this as the same ignorance that leads people to storing passwords in plaintext.

So, I blame the developer for trying to use an MCP server 1) when they have no idea wtf it does and 2) in an environment that can affect real users who aren't aware of the incompetence of the dev whose service they're using. Likewise, in TFA, I blame the dev, not the tool. Unfortunately, no matter how you do it, lowering the barrier of entry for development while still providing access to ample footguns will always result in cases like this.