Agents

An agent is a model with tools and a loop. The tools are the part that matters: an agent without tools produces text, and an agent with tools produces consequences.

Blast radius, written down

The most useful artifact for any agent is a short document listing what it can reach:

• Tools, with the operations each one permits. Not “database access” but “read from these tables”.
• Identity, meaning what it acts as and what that identity is allowed to do everywhere, not just here.
• Data, meaning what it can read at all, including anything reachable through its tools.
• Network egress, meaning where it can send bytes.
• Cost ceiling, meaning what it can spend before something stops it.

Most organizations have never written this down for any agent, and the exercise is uncomfortable in a useful way. The common discovery is that an agent built to do one narrow thing runs with credentials that permit a great deal more, because scoping precisely was more work than the task seemed to justify.

Untrusted input is the whole problem

The security model of a normal application assumes instructions come from code and data comes from users. An agent reads data and treats it as instructions, which collapses the distinction.

Every document, ticket, email, web page, and search result an agent reads is a potential instruction to it. This is not theoretical.

The practical consequences:

Separate the reading from the acting. A component with broad read access should not also hold broad write access. If it must, the writes should go through a broker that validates them independently of the model’s reasoning.

Constrain the tools rather than the prompts. Instructions telling a model to ignore malicious content are a mitigation, not a control. What actually bounds the damage is that the tool cannot do the dangerous thing.

Treat egress as a security boundary. Exfiltration needs a path out. An agent that can only reach a fixed set of hosts cannot send your data to an arbitrary one, regardless of what it was persuaded to do.

Audit trails an auditor would accept

The trace is the raw material. The audit trail is what you can hand someone: for a given action, who or what did it, on whose behalf, when, with what authorization, and what changed.

Two properties make the difference. It has to be tamper-evident, meaning the agent cannot edit its own record. And it has to be queryable by subject, meaning you can ask what happened to this customer’s record rather than only what happened in this session.

Most agent frameworks produce logs. Logs are not an audit trail until someone can answer those questions from them without writing a script.

Human oversight that scales

“Human in the loop” as a phrase covers three different things, and it is worth naming which you mean:

• Approval before action. Strong, expensive, only viable on a small set of actions.
• Review after action. Sampled, cheap, catches systematic problems rather than individual ones. Underused.
• Interrupt during action. A person can stop a running agent. Requires that stopping actually stops it, which is a runtime property.

Most organizations implement the first, on too many actions, and neither of the others. Sampled review after the fact is the highest-value thing most teams are not doing.