Unit 03.01: Giving an agent the narrowest tool that works

A broad tool cannot be made safe by instructions, because the tool executes whatever arrives.

One lookup versus arbitrary access

A general query tool can read anything. A specific lookup takes one id and does one thing.

The example below runs both, including one hostile input.

BROAD TOOL: "run this query"
  input        SELECT * FROM salaries
  result       executes it
  restriction  only whatever the instructions asked for

NARROW TOOL: "get invoice by id"
  input        INV-1187                  ->  the invoice record
  input        1187                      ->  REFUSED: id must start with INV-
  input        SELECT * FROM salaries    ->  REFUSED: id must start with INV-

  The narrow tool cannot reach the salaries table. Not because it was told
  not to -- because it takes an invoice id and looks up one invoice.

The narrow tool refuses a SQL string because it is not an invoice id. Not because it was told not to execute SQL - because it takes an invoice id and looks up an invoice.

That is a guarantee you can state to an auditor. "The agent is instructed not to read the salaries table" is a probability; "the agent has no tool that reads tables" is a fact about the configuration.

The mistake this prevents

The mistake is building one flexible tool because it saves writing five specific ones. The flexible tool is quicker to build and moves every restriction from code into prose, where it cannot be tested and does not hold.

Takeaway

Give the agent the narrowest tool that does the job. A capability the tool does not have is a guarantee; a capability it is told not to use is a hope.

Mark complete