Hacker News Reader

Comment by jcalloway_dev | Hacker News Reader

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.

View on HN

$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.

The hash chain approach is exactly right — even a simple append-and-sign pattern would catch post-hoc tampering without much overhead. Worth looking at how Sigstore handles this for inspiration.

Good call on visibility-before-enforcement. Alerting built on shaky data models is worse than no alerting.

The SQLite read is clean. Graceful degradation on schema change is the kind of detail that separates "I built this for me" from "I built this to last."

Curious what your rollout looks like — are people self-hosting, or is there a managed path you're considering?

Sigstore is a good pointer - I'll look at how they handle the transparency log. The append-and-sign pattern is probably the right starting point before going full Merkle tree.

On rollout - fully self-hosted right now, intentionally. The core promise is local-only: your data never leaves your machine. curl | bash, single binary, vigilo setup handles the rest. A managed offering for teams is the obvious next step if there's demand - but it's a fundamentally different product with different trust assumptions. I'd build it as a separate thing, not by compromising the local-first model.

Reply on news.ycombinator.com