Auditing what your agents did.

Agents break the old assumption

Every audit system you already have assumes a person is behind each action. A user id in the application log, a commit author, a session in the admin panel. An agent breaks that assumption twice over: the actor is software acting on someone's behalf, and the action was assembled from a prompt nobody will remember writing. When agents share credentials with people, or with each other, attribution collapses entirely.

What the trail has to record

Reconstructing an agent action needs four things, recorded at the moment of the call:

• The caller. Which surface, which credential, on whose behalf. An agent in a Slack channel and an editor connected over MCP are different callers even when they hit the same tool.
• The exact tool. Not "used Stripe" but the operation: list_customers is a different event than a subscription change. Tool-level naming is what makes the log answer questions.
• The capability class. Whether the call could mutate anything. A log you can filter to writes-only is the difference between an afternoon and a week when something goes wrong.
• The gate it passed. If a human approved the action, the approval is part of the record. Held, approved by whom, then run.

Approvals are audit events, not friction

The approval step on writes is usually sold as safety. Its second job matters just as much: it converts the riskiest actions into records with a named human attached. "The agent sent it" becomes "the agent drafted it, and Dana approved the send at 4:12." That sentence survives a customer escalation. See the permission model for how tools get classified into needing this in the first place.

Credentials you can trace

Attribution also depends on token design. A credential that appears in logs as an opaque blob cannot be traced or safely searched for. The pattern that works: tokens carry an identifiable prefix stored in the clear, with only the secret half hashed. A leaked token is then greppable in logs and identifiable in a dashboard without the secret ever being stored, and it can be revoked individually instead of rotating everything.

How Notara does it

Every connector call that executes through Notara is logged with the endpoint, the connector, the tool name and its capability. In Slack, an approved write and its approval sit together in the trail. MCP endpoints expose read-only context, resources, and skill prompts, so write and destructive tools are not projected there. MCP tokens use the ntr_mcp prefix scheme described above: issued per group, identifiable in the dashboard, revocable one at a time.

The per-tool capability tags that drive all of this are public: every page under the connector index lists its tools with their read, write or destructive class, for example Slack or HubSpot.