Tracked Capabilities for Safer Agents - by Martin Odersky
Language and Code
SubscribeSign in
Tracked Capabilities for Safer Agents
Martin Odersky<br>Jul 27, 2026
Share
This post describes the ideas behind our paper “Securing Agents with Tracked Capabilities”<br>and the tooling we are developing based on these ideas. The paper, written jointly with Yaoyu Zhao, Yichen Xu, Oliver Bracevac, and Nguyen Pham, received the best paper award at the inaugural ACM Conference on AI and Agentic Systems (CAIS 2026).<br>A new class of risk
AI agents are changing how we build software and run business processes. The recipe is by now familiar: take a large language model, give it access to a set of tools, and let it pursue a goal on its own. The tools are made available through protocols such as MCP or through skills, and increasingly through code execution. Instead of calling one tool at a time, the agent writes a small program that calls the tools for it. This turns out to save a lot of tokens, and it is also believed to be safer. In our work we assume this style of tool use.<br>Thanks for reading Language and Code! Subscribe for free to receive new posts and support my work.
Subscribe
But there is a fundamental problem: an agent might use its tools inappropriately. For instance. it might delete data it should not touch, or leak private information to the outside world, or hack into a protected system. This can happen for a large number of reasons, such as an indirect prompt injection hidden in some document the agent reads, or a hallucination, or agent misalignment, or simply an ordinary mistake. The critical point is that the tool call usually happens automatically, with no human in the loop to catch problematic behavior.<br>This is a genuinely new kind of threat, and it comes precisely from the combination of the two technologies. Without tools, an LLM can only produce text or images, nothing that reaches out into the world. Without the LLM, we are back to ordinary software, with the ordinary defenses of code review, testing, and verification. Put the two together and you get AI-generated plans that invoke real tools with real effects, none of it vetted beforehand by a human. As agents become more capable, both what they can do for us and what they can do to us grows with every generation of models.<br>The usual answers are not enough. Model alignment can be broken, and it forces an uncomfortable trade-off between safety and usefulness. Sandboxing helps, but it needs fine-grained permissions that neither an untrusted agent nor a busy human operator can be trusted to get right. And asking a human to confirm every sensitive action leads quickly to confirmation fatigue, which is just another way of saying that the oversight stops working.<br>Don’t bet on the model
The central idea of our paper is this: agent safety should be a property of the infrastructure, not a bet on how the model behaves. We want to put the agent in a safety harness that permits a rich range of useful behavior while ruling out the dangerous parts, and we want the guarantee to hold no matter what the model does, even if the model is actively adversarial.<br>The tool we reach for is an old one from systems security: capabilities. In the object-capability model, first described by Dennis and Van Horn in 1966, an object can only act on another object if it holds an unforgeable reference (a capability) to it. No ambient authority, no acting at a distance. If you were never handed the key, you cannot open the door.<br>Object capabilities have traditionally been a purely runtime affair. Our contribution is to track capabilities in static types, building on a line of work on capture checking that has been developing in Scala over the last several years. This sounds like a small technical shift, but it fundamentally changes what is possible. Static tracking lets us express something that runtime checks cannot easily express: enforce that a particular object or function holds only capabilities in an allowed set. At the limit, this allows to enforce that the object or function is pure, i.e. that it holds no capabilities at all, and therefore cannot leak anything or affect anything outside itself.<br>Another reason for using types to track capabilities is good ergonomics. Types catch errors before the code ever runs. They impose no runtime overhead. They hold for all possible inputs, not just the ones you happened to test. And they are modular, so you can assemble a safe system out of reusable, separately-checked parts.<br>A concrete scenario
Suppose we ask an agent to compare a set of contracts and write a short summary of what changed between them. The contracts are confidential. The agent must produce its summary, but it must not be able to reveal the contents anywhere else: not to another tool, not by sending them over the network, and not by quietly carrying them over into its answer to some later, unrelated prompt. On top of that, the language of the contracts should not be...