The tool is the control surface

By Nitin Tyagi, CISA, CISSP, CIPT · Founder, NexNith · Published 2026-08-18

For twenty years the assessment of an information system has begun by asking what the system does and then testing the controls around the doing. With an AI agent that instinct sends the reviewer to the wrong layer, because the component that looks new is not the component that carries the exposure. A review scoped to the model examines its accuracy, its bias, its training data, and its rate of confident error, and produces a report about model risk for a system whose exposure is set somewhere else entirely.

An agent is a model, a set of tools, and a loop that runs between them. The model produces text, and text by itself changes nothing in a member’s account. What makes an agent consequential is that some of the text it produces is interpreted by the surrounding software as a function call. That function then acts in a system of record, where it reads a balance, moves money, sends a message, opens a case, or places a hold. The blast radius of an agent is the union of what its tools can do, and nothing beyond it. That union is the agent’s tool surface, and it is the control boundary, because every path from the model to a system of record runs through one of those functions.

That has an immediate consequence for how an assessment is scoped. Where the tools can be enumerated, and each one’s technical capability and its bound established, the system has been bounded, because no path exists from the model to a system of record that does not pass through a tool. The contrast between two deployments makes the consequence concrete, because the same model behaviour produces a different class of problem in each. A model that produces confident errors at a high rate while holding one tool that reads a public FAQ is a quality problem, because the worst outcome is a wrong answer. A model that is accurate on 99.7% of requests while holding an unbounded refund function is a financial control problem, and the 0.3% is not the part that matters. The part that matters is that the 99.7% is also unconstrained, so anyone able to influence the model’s input can direct the money.

What a tool consists of

A tool is more than the function name in a manifest. Enumerating the control surface means establishing five things for each tool, and they are listed in this order because each is found in a different place.

1. The capability. What the function can technically do, taken from the API specification rather than from the description written for the model. The two differ, because the description is written to guide the model’s choice and the specification is what the target system will actually accept.

1. The scope. Which subset of data or accounts the function can reach. Scope is inherited from the service identity the call authenticates as, so it is set by that identity’s effective permissions rather than by the use case the tool was built for.

1. The control point. The location in the architecture where a stated limit is actually applied, which Module 0 numbers from one to six. Three of the six can hold a limit on a single tool: the system instructions, the harness, and the target system. A limit in the system instructions is advisory, because the model reads it and nothing rejects an action that exceeds it. A limit in the harness or the target system is preventive, because the call is refused. These are different assurance positions and the same sentence describes all three.

1. The trigger condition. Whether a person sees the call before it executes, and whether that person is shown enough to refuse it. An approval step that presents a conclusion without the evidence behind it records a decision without informing one.

1. The authorization. Which governance body agreed that the system should hold this capability, and against what documented use case. Where no body agreed, the capability is present without an owner, which is a finding about the absence of a decision rather than about the capability itself.

The fifth is the one an assurance function is positioned to ask, because it is a question about a decision rather than about a system. Engineering can say what the tool does and product can say what it is for, and neither is accountable for whether the capability was approved.

Why the model-first instinct persists

Two forces sustain the model-first instinct, and neither is a mistake on the part of the people holding it. Platform vendors publish evaluation dashboards and safety benchmarks, because those are properties of the model they supply, and the permissions attached to a tool are configured by the customer and are therefore outside what a vendor can present. And model behaviour is the part of the system that is genuinely unfamiliar, while the tool layer resembles ordinary integration work.

The resemblance is real, and it is the useful part rather than the objection. The tool layer is assessed with the apparatus that already exists: least privilege, meaning an identity holds only the permissions its task requires; segregation of duties; transaction limits; change control; and logging. What differs is that the caller is non-deterministic and can be influenced by whoever controls its input, so a control that relies on the caller behaving predictably no longer holds.

The posture that follows is not that AI requires a new method. It is that the model determines how likely the agent is to attempt something, and the tools determine what happens when it does. Both are assessed, and the second is never allowed to be crowded out by the first, because only the second has a ceiling that can be established from configuration and evidenced.