Tool-calling agents and enterprise permissions

The risk

Models will call whatever tools you expose when the prompt drifts or the input is adversarial.

Enterprise design starts from: which roles may write, which systems, which fields, and what requires dual control.

Patterns that hold up

Allow-listed tools per agent role. No "generic HTTP" tool in production cases that touch money or identity.

Idempotent writes and dry-run modes for high-impact actions.

Human approval gates before irreversible side effects.

Tool design

Prefer narrow tools: "create_review_task" over "http_request". Narrow tools are easier to permission, test, and audit.

Document side effects. If a tool can charge a card or file a SAR, that belongs in the security review of the agent, not a footnote.

Testing tool sequences

Eval cases should assert the correct tools were called in order with valid arguments—not only that the final prose looked right.

In practice

Map the workflow on a whiteboard before you open a framework: inputs, systems of record, humans, and irreversible writes. If that map is fuzzy, the agent will encode the fuzz.

Pick ten to fifty real historical cases as an eval set. Include the ugly ones. Run the agent offline against them until critical fields and hard rules are acceptable. Only then connect write tools.

Ship with a pause switch, a human queue, and a weekly review of override reasons. Promote repeated overrides into rules. That loop is how production systems improve—not another prompt brainstorm.

Common failure modes

  • Treating a demo on clean samples as readiness for production volume.
  • One shared service account with broad write access across systems.
  • No owner for the exception queue, so failures pile up as noise.
  • Changing prompts and models without regression gates on real cases.
  • Measuring only model latency or thumbs-up, not completed-case cost and audit completeness.

What good looks like after ninety days

The first workflow is boring: stable override rate, known failure modes, operators who trust the queue. Config changes go through review. Traces answer "what happened to this case?" without archaeology.

At that point you can add a second document type or a second agent role. Expanding before the first path is boring is how programs stall with five half-built pilots.

AI agent systems

常见问题

Should every agent have the same tools?

No. Split agents or policies by tool set so a summarizer cannot update core systems.

How do we test tool use?

Fixed fixtures, contract tests on tools, and eval cases that require the correct tool sequence—not only golden answers.