HackerTrans
トップ新着トレンドコメント過去質問紹介求人

trevxr

no profile record

投稿

Show HN: Snare – catch hijacked AI agents before they make their first AWS call

github.com
1 ポイント·投稿者 trevxr·4 か月前·1 コメント

Show HN: Rampart – Open-source firewall for AI agents (v0.8)

rampart.sh
2 ポイント·投稿者 trevxr·4 か月前·2 コメント

Show HN: Rampart v0.5 – what stops your AI agent from reading your SSH keys?

github.com
1 ポイント·投稿者 trevxr·5 か月前·0 コメント

Show HN: Rampart – Runtime firewall for Claude Code and AI agents in YOLO mode

github.com
2 ポイント·投稿者 trevxr·5 か月前·0 コメント

コメント

trevxr
·4 か月前·議論
I built this because Canarytokens.org has a published static bypass — TruffleHog identifies their AWS keys without triggering them by pattern-matching the key format. It's in TruffleHog's own README.

The other issue is CloudTrail latency. Median ~2-3 minutes. For a compromised AI agent that can enumerate credentials and pivot in under 10 seconds, that's too slow.

Snare plants fake credentials that fire at resolution time — before any API call, before CloudTrail sees anything. The awsproc canary uses AWS's credential_process feature: a shell command that runs when the SDK resolves credentials. The callback fires before the first packet leaves the machine.

Three precision canaries by default: awsproc (AWS), ProxyCommand (SSH), fake server URL (k8s). All fire on active use only, near-zero false positives from your own tooling.

Happy to dig into the implementation or threat model in the comments.
trevxr
·4 か月前·議論
Hi HN, I posted Rampart here a few weeks ago. Since then it's gone from v0.1 to v0.8.6 with some substantial changes, so I wanted to share an update.

Rampart is a policy engine that sits between AI coding agents (Claude Code, Codex, Cursor, Cline, OpenClaw etc.) and your operating system. Every shell command, file operation, and MCP tool call gets evaluated against your rules before it executes. Denied actions never run.

What's new since last time:

- Response scanning: blocks credentials (AWS keys, SSH private keys, GitHub tokens) from entering the agent's context window. This is the gap most people miss: your .env file is inside your project folder, so directory sandboxing doesn't help. Rampart catches the secret in the tool response before the agent ever sees it.

- Temporary rules: `rampart allow "docker build " --for 1h` expires automatically. `--once` for single use. Useful when you need to unblock something without permanently weakening your policy.

-Policy from audit: `rampart init --from-audit` watches what your agent does in monitor mode and generates a policy to match. Easier than writing rules by hand.

- MCP proxy: `rampart mcp -- npx @server` enforces policy on any MCP server. `rampart mcp scan` auto-generates deny-by-default policy from a server's tool definitions.

- Native integrations: one-command setup for Claude Code (PreToolUse hooks), Codex (LD_PRELOAD), or any agent (shell wrapping).

Architecture: single Go binary, YAML policies, <10µs per evaluation, hash-chained audit trail. Intercepts via native agent hooks, LD_PRELOAD, $SHELL wrapping, or MCP proxy depending on the agent.

Some interesting things we found while dogfooding: agent runtimes wrap commands in `/bin/bash -c`, which broke our glob-based command matching (fixed in v0.8.6). Claude Code's enterprise sandbox uses bubblewrap with `--unshare-net` but restores network via a Unix socket proxy bridge — Rampart's hooks fire before the sandbox, so they're complementary. And our own self-modification protection caught the agent trying to run `rampart allow` to weaken its own rules during development.

Apache 2.0, no dependencies, ~58k lines of Go. Happy to answer questions about the architecture or threat model.