Platform-level audit trail for agent tool call proposals and user approval decisions

Ideas Feature Requests
, , ,
1

Feature request for product/service

Chat

Describe the request

Cursor agents propose tool calls (file edits, shell commands, MCP calls, file
deletions) and the user accepts or rejects each one. None of these proposals
or decisions are persisted in any queryable, exportable form.

The Enterprise audit log covers administrative events (logins, role changes,
API keys, team settings) but explicitly excludes agent actions: “We do not log
agent responses or generated code content.” Hooks cover prompts submitted and
code generated — but not tool call proposals, approval/rejection decisions,
timestamps, or which model requested the action.

What should be logged per tool call:

  • Timestamp
  • Agent/model that proposed the call
  • Tool type (Shell, Read, Write, StrReplace, MCP, Delete, etc.)
  • Call parameters (command, file path, MCP server+tool, etc.)
  • User decision: accepted / rejected / auto-approved (via allowlist)
  • Execution result: success / failure / cancelled

Why this matters:

Governments, corporations, and regulated institutions require auditable
decision trails before adopting AI-assisted development tools. SOC 2, GDPR,
NIS2, HIPAA, and ISO 27001 all expect evidence of human oversight over
automated actions — especially actions that modify source code, execute
commands, or access external APIs.

Without a platform-level approval audit trail, organizations cannot answer:
“What did the AI agent do, and did a human authorize it?”

Suggested implementation:

  • Append to existing Enterprise audit log stream (SIEM/S3/webhook)
  • Also persist locally for individual users (JSONL alongside agent
    transcripts) so non-Enterprise users benefit from session review
  • Expose via a hooks event type (e.g. tool_call_proposed,
    tool_call_decided) for custom compliance pipelines

Related: topic #156178
(persist tool calls before execution + crash recovery) covers the write-ahead persistence side. This FR covers the approval decision
audit trail, which is complementary: persistence makes recovery possible;
audit trail makes governance possible.

3

Cursor currently shown when an agent is waiting for approval for shell commands, MCP tools, file edits, and other gates, but that state is not exposed as a hook/event.

Request:

Add hook/event when an agent becomes blocked on user approval.

Why:

Local observability tools need to distinguish:

  • model is working
  • agent is blocked waiting for the user

Thank you :slight_smile:

4

A useful extension would be to bind each approval decision to the exact action that later executes.

The proposed audit trail answers:

- what tool call was proposed;

- whether the user accepted, rejected, or auto-approved it;

- what execution result followed.

But without exact action binding, it may still be impossible to prove that the executed action was precisely the action the user approved.

I would represent the lifecycle as three append-only records:

1. “ActionProposed”

2. “ActionDecided”

3. “ActionCompleted”

All three should share a stable “action_id” and preserve:

- tool identity;

- canonical parameters digest;

- actor or agent identity;

- workspace or resource scope;

- target-state digest where relevant;

- policy or configuration version.

The decision record could additionally include:

- “decision_id”;

- outcome such as “ALLOW | BLOCK | DEFER”;

- approval scope such as once, session, workspace, or global;

- reason code;

- “issued_at”;

- “expires_at”;

- “continuation_id” when approval is deferred.

Immediately before the side effect, the executor should recompute the action binding.

If the tool, arguments, target, scope, policy version, or relevant target state changed after approval, execution should fail closed and require a new decision.

For commands or MCP calls containing secrets, the audit record could store canonical hashes and stable evidence references rather than raw sensitive values.

The key invariant is:

«The audit trail must prove not only that an action was approved and executed, but that the executed action was exactly the action that was approved.»

A small conformance fixture could mutate one field at a time — arguments, tool, scope, target state, or policy version — and require a distinct mismatch reason, zero side effects, and a new approval path.

This would connect the related write-ahead persistence proposal with the governance trail: persistence preserves the frozen action, while exact binding proves that the same f

rozen action was later authorized and executed.