Governance is often viewed through a prevention lens, focused on stopping a bad action before it happens. Arcade.dev has already proven its capabilities there. CATE evaluates every tool call at runtime, applying prompt injection scanning, PII redaction, and your own policies before an action ever executes.
But prevention is only half of governance. Being able to see exactly what an agent did in production, and on whose behalf, matters just as much.
Arcade.dev now makes that half easy too with Execution Tool Logs: a record of every tool your agents run, who they run it for, and whether it succeeded.
What Execution Tool Logs capture
Arcade has always enforced your policies at runtime, deciding whether a given agent, acting for a given user, can take a given action. Execution Tool Logs cover what happens next.
Every time a tool runs in a project, Arcade captures which tool and toolkit ran, including the version, which end user it ran for, and when it was created, started, and finished. If a run retried, you see each attempt. If it failed, you see the error.
Answering “who did what, on whose behalf?”
The question that comes up most in our customer conversations is, simply, who did what? Someone received an email with an attachment at a certain time, and you need to know which agent sent it and whose identity it used. Execution Tool Logs answer that directly. You can filter by tool name, toolkit, outcome, time range, user, or the text of an error, then open any single execution to see its full timeline.
And because Arcade records runs as they happen, you are looking at current activity, not yesterday’s export.
Debug a tool that isn’t working
When a tool call fails, you can work from the record instead of digging through your agent’s logs. Set the outcome filter to failure and narrow by tool name or the affected user, then open the run to see each attempt, how long it took, and the error it returned. Toggle Show inputs to see the exact arguments the tool received, and Show outputs to see what it returned, including the full error the provider sent back.
From there, the fault usually places itself. If the inputs do not match what you intended, your agent or prompt built the wrong call. If the inputs look right but the output carries a provider error, the problem is upstream, in permissions, or in rate limits. If the inputs are right and the output is wrong or empty, it is the tool’s own logic. And if the run needed authorization, the end user has not yet connected the account it depends on.
One place to trace every agent, across every team
Large organizations rarely run one team’s agents. A single company might have 15 teams building on Arcade at once. Execution Tool Logs pull all of that into one view, so what used to mean chasing logs across teams and systems becomes a single search. You do not have to stand up a pipeline that ships logs into an observability tool just to answer what an agent did last Tuesday. The record already lives in Arcade, where the action ran.
This also makes enforcement more valuable. When Arcade blocks an action, that block becomes something you can find and investigate. You can see which agent tried it, for which user, and go ask why. Stopping a bad action is good. Knowing it happened, and being able to trace it to a root cause, is better.
Built for sensitive data with RBAC
Not every execution detail should be visible to everyone. Inputs and outputs can carry sensitive data, so Arcade keeps them behind role-based access. Project members can see the execution list, status, timing, and errors. Inputs and outputs stay limited to project admins. An error message is not the same as a payload, so a failed run’s error stays visible to the people debugging it without exposing what was in the request.
The same rules apply to the API, which lets you list, count, and pull individual executions programmatically, with admin permission required for payloads.
And the records themselves are encrypted at rest and in transit, so the trail you rely on is protected the same way the rest of your data in Arcade is.
Part of our deeper investment in governance
Execution Tool Logs are one piece of a larger investment. Arcade already gives you enforcement on every action, multi-user authorization, contextual access with runtime hooks, and centralized governance across every agent, tool, and team. Execution Tool Logs now adds the observability layer on top; the record of what actually ran, for whom, and how it turned out.
While this is an important step forward, it’s not the finish line. We are building real depth across governance and observability, and there is more coming in this space.
Execution Tool Logs are available now on Arcade Cloud, with a retention window you control. The full details are in the Arcade docs under Tool Executions.
