The read/write split is the part that's held up best for me. I run my side project — a books-to-real-places thing — as a small team of scheduled Claude agents, and what keeps it safe isn't clever prompting. Reads are free; the writes that matter aren't theirs to make. Approving a build, a deploy, or any spend is a drag I do myself on the board. They can recommend all day — a "yes" in chat is advice until I move the card.
We ended up scoping by role rather than by tool: each agent writes only in its own lane, and exactly one of them has a single write permitted outside it. That wasn't foresight. It came out of a small incident where an agent rerouted a piece of work without moving its state, and the item quietly vanished from every queue. Nothing malicious — just more reach than it needed.
One thing I'd add to your list: the permission list is the easy artifact. The harder problem is the tool that silently returns nothing while the agent reports success anyway. A blocked action that looks like an empty result is its own kind of security bug.
This is a great article. Thank you for the heads up. I have set up parameters similar to this in agents that I have built simply because of the industry that I am a part of, always thinking of security is normal, so of course that becomes part of the build out. But I see that it is more to it than making sure if a prompt that comes through tries to have it give the wrong info or hack it.
Thanks for reading! It sounds like your industry gives you a great head start. preventing prompt injection is only half the battle; securing the agent's actual tools is the layer too many teams miss.
I REALLY appreciate your warning people about this. I hope everyone reads it, and takes the appropriate actions and warns everyone they know to do the same thing, or malicious individuals will exploit this to the max, and cause Pols to enact limits to the tech, that will only accomplish slowing down progress.
I really appreciate you saying that! Helping people stay proactive about their security is exactly why I wanted to write this piece. It's so important that users understand the risks so the technology can keep evolving safely. If you have a second to repost or share it, it would really help me get the warning out to more people!
How are people not building and releasing agents with the bare minimum amount of privileges is beyond me. It is worrisome that developers don't follow the "Principle of Least Privilege" for anything designed anymore.
Good articles and points made here on these potential security issues.
I totally agree. The rush to build definitely seems to override basic security principles for a lot of developers right now. Thanks so much for reading and leaving your thoughts!
I’m happy this was published before I started to implement an Ai agent into a tool I am building.
The read/write split is the part that's held up best for me. I run my side project — a books-to-real-places thing — as a small team of scheduled Claude agents, and what keeps it safe isn't clever prompting. Reads are free; the writes that matter aren't theirs to make. Approving a build, a deploy, or any spend is a drag I do myself on the board. They can recommend all day — a "yes" in chat is advice until I move the card.
We ended up scoping by role rather than by tool: each agent writes only in its own lane, and exactly one of them has a single write permitted outside it. That wasn't foresight. It came out of a small incident where an agent rerouted a piece of work without moving its state, and the item quietly vanished from every queue. Nothing malicious — just more reach than it needed.
One thing I'd add to your list: the permission list is the easy artifact. The harder problem is the tool that silently returns nothing while the agent reports success anyway. A blocked action that looks like an empty result is its own kind of security bug.
This is a great article. Thank you for the heads up. I have set up parameters similar to this in agents that I have built simply because of the industry that I am a part of, always thinking of security is normal, so of course that becomes part of the build out. But I see that it is more to it than making sure if a prompt that comes through tries to have it give the wrong info or hack it.
Thanks for reading! It sounds like your industry gives you a great head start. preventing prompt injection is only half the battle; securing the agent's actual tools is the layer too many teams miss.
-Hana
Interesting event - I think I might attend
Hope to see you there! Will be there, too.
I REALLY appreciate your warning people about this. I hope everyone reads it, and takes the appropriate actions and warns everyone they know to do the same thing, or malicious individuals will exploit this to the max, and cause Pols to enact limits to the tech, that will only accomplish slowing down progress.
I really appreciate you saying that! Helping people stay proactive about their security is exactly why I wanted to write this piece. It's so important that users understand the risks so the technology can keep evolving safely. If you have a second to repost or share it, it would really help me get the warning out to more people!
-Hana
How are people not building and releasing agents with the bare minimum amount of privileges is beyond me. It is worrisome that developers don't follow the "Principle of Least Privilege" for anything designed anymore.
Good articles and points made here on these potential security issues.
I totally agree. The rush to build definitely seems to override basic security principles for a lot of developers right now. Thanks so much for reading and leaving your thoughts!
-Hana