Inside the Tool Call, and Who Can See It

An agent decides to call a tool. It sends a request naming the function and its arguments, and something sends back a result. Both halves are the part governance cares about, because the argument is what the agent asked for and the result is what it received.

‍

Where an organization can observe that exchange depends entirely on how the agent talks to the tool, and the transport most developer agents use produces no network event at all. Guidance that names a gateway as the answer is describing one of two cases.

‍

Why Doesn't the Network See the Tool Call?

‍

Two separate reasons, and conflating them leads to the wrong control.

‍

Where an agent runs a tool server locally, the two processes communicate over standard input and output on the same machine. The request and result never reach a network interface, so there is no packet to inspect, no connection to log and no gateway position that helps. A control that reads traffic cannot read an exchange that produced none.

‍

Where the tool sits remotely, the exchange does cross the wire and is still largely opaque. The call and its arguments travel inside the encrypted application stream between the agent and the model provider, structured as remote procedure calls nested in that stream. A conventional gateway reads hostnames and paths, so it records a connection to a provider it already permits and nothing about what was requested.

‍

Which Transport Are Your Agents Using?

‍

Worth establishing before choosing a control, because the answer splits by deployment. Agents running inside a developer's editor commonly use the local transport. Agents running as a hosted service typically use the remote one. Many organizations have both and have instrumented for one, and the protocol permits either.

‍

What Does the Endpoint See?

‍

A process it has been watching all day, behaving the way it always behaves. Endpoint tooling monitors processes, files and system calls, and a tool call is none of those from its perspective.

‍

The agent binary is known and permitted. It reads and writes files a developer tool would normally touch. It opens connections it has opened since installation. Where a local tool server is involved, the endpoint may see a child process spawn, which tells you a tool ran and nothing about which function was invoked or what came back.

‍

So Both Sources Are Accurate and Uninformative

‍

This is the pattern worth naming, because it recurs across agent observability. The network correctly reports an established connection to a permitted destination. The endpoint correctly reports a permitted program doing ordinary things. Neither is failing and neither answers the question, which is the shape of problem an AI Interaction Data Fabric exists to address.

‍

Where Can the Exchange Be Read?

‍

Three positions, each covering a different subset, and none covering everything.

‍

• A Tool Gateway: Sits between agent and remote tool, reads the function name and arguments, and can refuse the call before it executes.
• The Agent's Own Instrumentation: Reports intent and reasoning, and is written by the process being observed.
• The Target System's Logs: Independent and complete for that system, with no view of the chain that produced the request.

‍

The gateway is the only one of the three that can both read the argument and prevent the action, which is why it dominates the available guidance. It is also the only one with no coverage of local transport, since a locally spawned tool server has no gateway to pass through.

‍

Does That Make the Gateway the Wrong Answer?

‍

No, it makes it a partial one. For remote tool access it is the strongest control available and worth deploying. For agents running tools locally on developer machines it contributes nothing, and a program that has deployed a gateway and considers tool-call visibility solved has covered whichever half its architecture happens to use. The wider protocol exposures apply to both transports.

‍

What Should You Ask a Vendor About Coverage?

‍

One question separates a real claim from a broad one. Which transports does this see.

‍

A product reading remote tool traffic and a product reading local process activity are solving different problems, and both can describe themselves as providing tool-call visibility. Asking which transports are covered, and requesting a demonstration on the transport your agents run on, resolves it faster than any feature comparison.

‍

Three Follow-Up Questions

‍

Whether the product reads arguments or only function names, since an argument is where the sensitive value sits. Whether it reads results, because a poisoned tool result arrives on the return path rather than the request. Then whether it can refuse a call or only record one, which is the difference between a control and a log.

‍

Why Do Results Matter as Much as Requests?

‍

Because the return path is where content enters the agent's context, and content entering context behaves as instruction.

‍

A tool returning a document, a search result or an API response places that text where the model reads it, so a compromised or manipulated tool influences everything the agent does next. Reading requests without reading results catches an agent asking for something it should not have and misses an agent being told something that changes its behavior, which is the injection problem arriving through a channel most instrumentation ignores.

‍

Which Direction Is Harder to Observe?

‍

Results, generally, because they are larger, less structured and more likely to be summarized before anything records them. A request is a function name and a short argument list. A result can be a document, and instrumentation that truncates it has recorded that something came back rather than what.

‍

Does the Model Provider's Log Help?

‍

Partially, and it is the source most often overlooked because it sits outside the organization's own stack. Where an agent calls a hosted model, the provider records the exchange including the tool invocations it mediated.

‍

Enterprise tiers of the major providers expose that through an administrative or compliance interface, which gives an independent record written by neither the agent nor the network. The limitations are ownership and scope. The record lives with a third party under their retention terms, covers only the traffic that went through that provider, and returns nothing for a tool the agent invoked locally without the model mediating it.

‍

Why Is an Independent Record Worth Having Anyway?

‍

Because the agent's own account of what it did is written by the party under examination, and the reports on last month's frontier lab incident documented agents working deliberately on their own transcripts. A provider-side record disagreeing with an agent-side one is a stronger signal than either alone, and what agent telemetry answers well sets out where self-reporting is adequate.

‍

Which Sources Can Be Joined?

‍

Any two that share an identifier, which is the constraint rather than the availability of the sources. A provider record naming an account, a gateway record naming a session and an endpoint record naming a process are three descriptions of one event with nothing in common unless somebody established the join in advance, and turning telemetry into evidence turns on exactly that.

‍

What Can Be Established Today?

‍

Four facts, and none requires new tooling to answer.

‍

Which of your agent deployments use local tool servers and which use remote ones, since that determines every subsequent choice. Whether any position in your environment reads function arguments at all. Whether anything reads results. Finally, whether any of it can refuse a call rather than report it afterward. Where the answer to the last two is no, the honest position is that agent tool use is logged at the connection level and unobserved at the semantic level, which monitoring relationships rather than participants addresses from the other direction.

‍

What Substitutes for Semantic Visibility?

‍

Constraining what the tools can do, which is available immediately and does not depend on reading anything. A tool set that excludes write access, irreversible actions and reach into regulated data bounds the consequence of every call regardless of whether anyone observed it. Where visibility is unavailable, scope is the control that remains, and an AI data fabric narrows the unobserved portion rather than removing the need for that boundary.

‍

Ask Which Transport, Not Which Product

‍

A tool call is invisible to the network for one of two reasons, either because it never crossed a wire or because it sat encrypted inside a permitted stream, and invisible to the endpoint because a known program doing familiar things is exactly what endpoint tooling is built to ignore. A gateway reads the exchange and can refuse it, for remote transports only. Local tool servers on developer machines require a position on the host, and an organization running both has probably instrumented one. Reading requests without results leaves the injection path open. Kovrr's AI Security and Governance Platform correlates agent activity across network, endpoint, browser and cloud sources, which is what makes the unobserved portion measurable rather than assumed.

‍

To see which agent activity in your environment is observed at the semantic level and which is only logged as a connection, book a demo mapped to your own estate.