Grokbot hacked via Email Inbox? (and how to prevent it)

0:00Connecting Rockbot to read and respond to email is becoming an attractive use case for many people. Unfortunately, that also comes with huge cyber security risk. Attackers might steal data and erase everything in your account. Yesterday, Nate Herk gave a really good tutorial of how to connect agent mail to Grockbot. Let's have a quick look and I will give the full link down in the description here. The email address uh YouTube test agentmail.to to is already connected to Grockbot. Notice that Nate gives a clear command as part of the email. He instructs the bot exactly what to do to tell a joke. And here you can see that everything works as intended

0:42and the bot responded via email. Nate did everything correctly from a functionality perspective. The system works and I also consider him a great educator. But from a cyber security standpoint, this setup receives a 10 out of 10 risk score. Anybody can now write to this email address and Grockbot will just execute any command it receives. This is especially dangerous because all of your Grock bots share the same

1:09virtual machine and the same connectors. That means that if some of your bots have access to Stripe or GitHub, the bot that has access to email can also access these systems. There are simply no boundaries between the bot. Let's look at the worst case what an email command boat could do to you. For GitHub, it could leak the information from private

1:32repository. The same is true for notion. It could leak some secrets you have in private notion pages. If it's connected to Salesforce, it could steal all your customer data. A connection to Versel even allows it to deploy malicious code instead of your real implementation. With access to Stripe, it might be able to exfiltrate your revenue reports or even issue refunds to your clients. Let me give you some pointers for immediate actions that you can apply to be more secure. If you really want to use email as a command center, then use the allow list feature to only allow the receipt of emails from your address. But please

2:14understand that this will not give you perfect security. There's something called SMTP forgery. So the sender of an email is not always authentic. You cannot 100% rely on it. It's a much better idea to completely avoid the command center use case and instead just use email as a normal tool. A client can send you an email and what you actually want to avoid is that they can just inject arbitrary commands, arbitrary prompt into this email. And that's

2:46exactly what we should address now. Prompt injection should not be possible under no circumstance. So the next thing you can do is to change the default domain. Agentmail.to is a well-known domain with these kinds of agentic bots. So this is where attackers will try to inject prompts and see whether the system is vulnerable.

3:08Don't make yourself an easy target. Avoid this kind of address. Next, use prompt hardening. Tell your agent to not take immediate action. It should read an email carefully and first decide is this a legitimate client inquiry? Is it spam or is it an attack? And if it's not legitimate, it should not take action based on the contents. It should just label it. Next, if you want to be even more secure, use separate cursor or

3:38Grock accounts for separate use cases. So have your email and CRM in one account and have a completely separate account for your Versel, GitHub and other infrastructure components. Of course, this comes at a trade-off. There is additional costs and there is a lack of convenience. So you really have to understand how serious are you about the security. And finally, if you are extremely serious about the security and also have the necessary budget for it, here's the architecture of a response system the way we build it. First, the user message is forwarded to a judging agent. Uh, this assigns a score between zero and 100 to score how likely it is

4:22that this is a legitimate inquiry and not spam or attack. Next, the email address is fed directly to the CRM to ensure that only the data of this one user can be accessed. To enhance the latency of the system, a short summary related to this user is directly created and fed into the LLM. The judge agent remains the final arbiter of what kind of changes are made in the CRM and what kind of message is sent out to the client. To recap, please be smart about Grockbot. It is a tool that has no intrinsic security isolation. So, make sure you have a configuration that corresponds to the level of security

5:04that you want to have. You can follow this channel if you are in general interested in the intersection of cyber security and agentic AI.