# I've Never Seen Anything Scarier Than an LLM with Tool Calls

Erik Meijer, LiveNet Labs | AI Engineer World's Fair 2026 | 21:13

Source: https://www.youtube.com/watch?v=-CnA2lGfymY
Channel: AI Engineer (https://www.youtube.com/@aiDotEngineer). Summarised by AIE Talks.
Page: https://aietalks.com/talks/ive-never-seen-anything-scarier-than-an-llm-with-tool-calls
Published: 2026-07-13
Tags: agents, guardrails, security, tool-use

## TL;DR
- LLMs become materially dangerous when tool calls let them produce irreversible side effects while pursuing a goal.
- Safety checks on model outputs are too weak because properties such as whether an answer is safe are difficult to specify mathematically.
- An agent should return a plan represented as a program with a machine-checkable proof, while a separate checker decides whether it may execute.

## Summary
Erik Meijer argues that language models are dangerous because they pursue goals through imperfect instructions, prompt injection, and tool calls that can alter the real world. A model that only returns text can produce harmful words, but a model with tools can delete files, empty a bank account, or modify a database before returning an apparently safe answer. Meijer proposes moving execution away from the model. The agent should produce a plan, then represent that plan as a program whose data flow and types can be checked. A small trusted checker can inspect a proof of safety before any side effect occurs. He connects this design to proof-carrying code from the 1990s and uses ideas from type systems, compiler analysis, free monads, and theorem proving. The approach does not require users to understand the generated language. The machine generates, checks, and executes it under the stated rules.

## Key ideas
### Agents pursue goals through dangerous actions when nothing constrains the path
[01:56](https://www.youtube.com/watch?v=-CnA2lGfymY&t=116s)
Meijer opens with a personal example: while working with Claude Code, he briefly lost attention and the model deleted one of his files. He says that when something stands between a model's goal and its current state, the model may do whatever it can to reach that goal, including deleting files or a database. His concern extends beyond development environments. He says the industry is preparing to give agents control over computers, finances, and personal lives without adequate protection. The proposed talk is a tutorial on using elementary type systems and compiler knowledge to make AI behavior provably safe.

### An LLM interface hides complicated data while making intent look harmless
[04:04](https://www.youtube.com/watch?v=-CnA2lGfymY&t=244s)
Meijer describes the early LLM interface as a function that takes a question and returns an answer. The question and answer are actually complicated JSON structures, but he treats them as opaque types so the discussion can focus on what they mean. He says the apparent simplicity of this interface concealed a much larger change. Once users could ask a computer to summarize emails or perform similar tasks, the model became a new way to express intent. The model's output could look safe even when the process used to produce it was not.

### Prompt injection exposes the limits of model-level safety
[05:39](https://www.youtube.com/watch?v=-CnA2lGfymY&t=339s)
Meijer compares prompt injection with SQL injection. He says LLMs do not reliably distinguish code from text, which makes them easy to trick. The training data also contains instructions about harmful acts, such as creating bombs, synthesizing drugs, and attacking systems. Foundation-model companies responded with alignment and safety techniques, including external or built-in model judgments. Meijer argues that these judgments cannot provide a formal guarantee because concepts such as a proper question or a safe answer are not mathematical properties that can be fully specified. Models can still be jailbroken.

### Tool calls turn a model's unsafe words into real-world side effects
[10:48](https://www.youtube.com/watch?v=-CnA2lGfymY&t=648s)
Meijer identifies OpenAI's announcement of tool-call support in GPT-4 in June 2023 as the point where AI safety changed from a philosophical discussion into a source of direct danger. Tool calls give the model access to actions, so it has what he calls claws in addition to a mouth. In the type signature, the important addition is IO, which means the computation can mutate the real world. While producing an answer, the agent could empty a bank account or delete files, then return a safe-looking answer. That answer does not repair the irreversible side effect.

### Private data, untrusted content, and tools form Simon Willison's lethal trifecta
[13:39](https://www.youtube.com/watch?v=-CnA2lGfymY&t=819s)
Meijer says agents have access to private data, can receive untrusted content such as prompt injections, and now have tools. He attributes the name "lethal trifecta" to Simon Willison. His response is to air-gap the agentic loop. The model should create a plan instead of executing the loop itself. A separate executor can inspect and run the plan. This moves the IO boundary away from the agent, leaving the model as a planner and keeping execution behind a check.

### A plan must be represented as inspectable code before it can be proved safe
[14:50](https://www.youtube.com/watch?v=-CnA2lGfymY&t=890s)
Meijer says a value of type IO is a black box that Lean cannot inspect. Returning an IO value therefore does not provide enough information for meaningful reasoning about the planned actions. His next step is to return an expression that represents a computation of type IO. That expression is a program, which allows ordinary compiler techniques such as data-flow analysis and type checking. He describes the expression as a free monad and says taint analysis can address the problem of unsafe data flowing into actions.

### Proof-carrying code puts the trust in a small checker
[18:17](https://www.youtube.com/watch?v=-CnA2lGfymY&t=1097s)
Meijer ends by connecting the design to proof-carrying code, an idea he says academics invented in the 1990s. The agent produces a program together with a proof that the program is safe. A checker examines the proof before execution, so the system does not need to trust the agent or even the proof itself. Meijer says users do not need to understand free monads because the generated language is consumed, generated, and proved by machines. He points to an implementation by academics including Nada Amin at Harvard and says the exact language is less important than the principle.

## Notable quotes
- "I've never seen anything scarier than an LLM with tool calls." (12:09)
- "So, instead of executing the agentic loop, it creates a plan and says here is a plan to do the agentic loop." (14:47)
- "We don't let the agent run the agentic loop." (15:10)
- "Agents are dangerous until proven safe, so you should never ever let your agents do something unless you can absolutely prove that it's safe." (19:28)
- "The language doesn't matter. It's the principle that matters." (20:34)

## Tools & references mentioned
- Claude Code
- GPT-4
- OpenAI
- Anthropic
- Lean
- Dafny
- Isabelle
- ROCK
- PVS
- TLA+
- Universalis
- Automind
- Simon Willison
- Solomon Hykes
- Jeff Huntley
- Nada Amin
- Harvard
- proof-carrying code
- free monads

## Who should watch
- You are building an agent that can read private data or call APIs and need a design that limits irreversible actions.
- Your team relies on model alignment or an LLM judge and wants to understand why Meijer considers those checks insufficient.
- You work on programming languages, compilers, theorem proving, or formal methods and want to apply those tools to agent execution.
