An agent's model gets all the attention, but the model never touches your systems. The tools do — the refund function, the database write, the email sender. If you want to know what your agents can actually affect, don't read their prompts. Read their tools. That's the Tools page.
Tools are the hands
Strip away the AI language and an agent is software that chooses which functions to call. Every real-world consequence — money moved, record changed, message sent — happens through one of those functions. Which means the practical risk surface of your agent estate isn't "what might the model say", it's "what can the agents reach". Prompts change weekly and models change monthly, but the tool surface is where the blast radius actually lives — and it's the part a security review can enumerate.
The Tools page builds that enumeration the same way as the agent census: from the stream itself. A tool that gets called appears in the inventory, with its usage history attached. Nobody files a form to register a tool, which means the list can't quietly omit the one that matters.
What a tool's row tells you
Each tool shows who uses it and how it behaves: which agents call it, how often, and how often it fails. Reading down the list answers review questions that are otherwise surprisingly hard. Which tools carry the most traffic? Which have started failing — a broken integration announces itself here before the downstream symptoms get creative. Which are touched by more agents than anyone intended? A tool built for one workflow that now serves five is a quiet scope creep no one approved.
And the sleeper: which tools does nobody call anymore, sitting connected and forgotten? An unused capability is risk with no payoff — it can still be invoked, still reaches production, and no longer has an owner who remembers why. It hides well in systems without an inventory, and it's usually the easiest win in the whole review: unplug what the evidence says nobody uses.
The question security teams actually ask
"What can this agent do?" is the first question in every agent security review, and answering it from source code means trusting that the code you read is the code that ran — and that you found all of it. The Tools view answers from evidence instead: here is what this agent actually touched, over months, with every invocation recorded and verifiable.
The gap between the two answers is often the most interesting finding in the review. Capability granted but never used is your least-privilege to-do list. Usage nobody knew about is the finding that justifies the review. Either way, the conversation runs on recorded fact rather than architectural memory — and the drill-down is one click deep: a tool's page shows its callers and its recent invocations, so "who used this and when" never needs a ticket to engineering.
Reading it with the rest of the dashboard
Tools complete the triangle: Events is what happened, Agents is who did it, Tools is what it was done with. Any investigation can start from whichever corner you know — a suspicious action, a suspect agent, or a sensitive capability — and pivot to the other two. In practice the tool corner is where security reviews start, because capabilities are what they're asked to sign off on; the permissions layer then says what each caller was allowed to do with them, which is the next post's subject. Questions about how your tools show up? Ask us.