CSE Roadmap

Core tier · about 5 hours · 5 parts

Part 1 of 5 · 2 min read

Overview

In this module you will

  • State least privilege for an agent and apply it in five places: what a tool can express, what a caller may do, which rows it may touch, how much and how often, and for how long.
  • Explain why "run any SQL" is the wrong tool even on a read-only connection.
  • Put every tool call through a gateway that checks scope, row, limits, quota and approval in code, outside the model.
  • Mint a task-scoped credential instead of handing out a standing key, and say what expires and when.
  • Decide when a person should approve a call, and why a person who approves everything is not a control.
  • Lint a tool list for the design smells that make a tool dangerous.
  • Answer the first half of the Level 6 interview question: how would you secure a server that exposes internal data?

In Level 5 you wrote the loop and the tools. This level connects agents to real systems, and everything changes: a tool is no longer a toy function but a way to change something that someone cares about. The model that picks the tool is also the model that reads untrusted text (a ticket, a web page, an email), and it can be talked into things. You cannot make the model reliably refuse. You can make sure that what it asks for cannot hurt much.

That is the whole idea of this module. The model's choices are requests. Your code decides what is allowed. The smaller the set of things your code would allow, the smaller the worst day.

About the examples

The example is real code against a real SQLite database file (a small support desk with customers, tickets and payments), so the database really refuses writes on the read-only connection and the rows really change or disappear. But the model is a script: when a poisoned ticket tells it to do something, it makes the nearest call its tools allow, and it does not try anything cleverer when blocked. A real attacker, and a real model under attack, will adapt. The numbers show how much each design limits the damage of one fixed set of requests, not how often a real model gets fooled. The "approver" is also a script (one that approves only what was asked for, and one that approves everything). No real model, service or customer data was used.