This is a real problem — I blew past $300 in a week before I even noticed. The lack of visibility is genuinely alarming when you're letting an agent run autonomously.
Few questions that'd help me understand the scope better:
The risk level tagging (read/write/exec) — is that purely for logging, or are you planning any threshold-based alerting? Like "pause and ask me before you rack up another $50 in exec calls"?
Also curious about the append-only guarantee. What's preventing a compromised agent from tampering with the ledger before your audit? Is that a threat model you've considered or intentionally out of scope?
The Cursor billing pull is clever — did cursor.com's API require any reverse engineering or is that documented somewhere?
Rust was the right call for something sitting in that critical path. Nice work shipping something you actually needed. This fills a gap that the agent tools themselves are weirdly uninterested in solving.
$300 in a week, yeah. That's what pushed me to build this.
Risk alerting - logging only for now. The data's all there (cost, risk, timing per event) so threshold alerts are straightforward to add. I wanted to nail visibility before touching enforcement. It's next.
Ledger tamper resistance - out of scope for v1, intentionally. You're right that a compromised agent with fs access could modify it. The real fix is a hash chain so tampering is detectable after the fact. I didn't want to over-engineer before validating the basic use case, but it's the right next step on the integrity side.
Cursor billing - Cursor stores per-request token usage in a local SQLite db at ~/.cursor-server/data/state.vscdb. That's your data on your machine, vigilo just reads it. The cursor.com billing endpoint wasn't documented but wasn't hard to find by watching network traffic. Worth noting: the cursor-usage command is purely additive — if Cursor changes their schema it degrades gracefully, but the core audit trail (MCP + hooks) has zero dependency on it.
On tool coverage - Claude Code is fully covered via matcher: ".*" on PostToolUse, every built-in tool fires through it. Cursor coverage was partial by default (Bash and Edit only) - pushed a fix today that adds beforeReadFile and beforeMCPExecution to the default setup.
This is a real problem — I blew past $300 in a week before I even noticed. The lack of visibility is genuinely alarming when you're letting an agent run autonomously.
Few questions that'd help me understand the scope better:
The risk level tagging (read/write/exec) — is that purely for logging, or are you planning any threshold-based alerting? Like "pause and ask me before you rack up another $50 in exec calls"?
Also curious about the append-only guarantee. What's preventing a compromised agent from tampering with the ledger before your audit? Is that a threat model you've considered or intentionally out of scope?
The Cursor billing pull is clever — did cursor.com's API require any reverse engineering or is that documented somewhere?
Rust was the right call for something sitting in that critical path. Nice work shipping something you actually needed. This fills a gap that the agent tools themselves are weirdly uninterested in solving.
$300 in a week, yeah. That's what pushed me to build this.
Risk alerting - logging only for now. The data's all there (cost, risk, timing per event) so threshold alerts are straightforward to add. I wanted to nail visibility before touching enforcement. It's next.
Ledger tamper resistance - out of scope for v1, intentionally. You're right that a compromised agent with fs access could modify it. The real fix is a hash chain so tampering is detectable after the fact. I didn't want to over-engineer before validating the basic use case, but it's the right next step on the integrity side.
Cursor billing - Cursor stores per-request token usage in a local SQLite db at ~/.cursor-server/data/state.vscdb. That's your data on your machine, vigilo just reads it. The cursor.com billing endpoint wasn't documented but wasn't hard to find by watching network traffic. Worth noting: the cursor-usage command is purely additive — if Cursor changes their schema it degrades gracefully, but the core audit trail (MCP + hooks) has zero dependency on it.
On tool coverage - Claude Code is fully covered via matcher: ".*" on PostToolUse, every built-in tool fires through it. Cursor coverage was partial by default (Bash and Edit only) - pushed a fix today that adds beforeReadFile and beforeMCPExecution to the default setup.