What are the security risks of giving AI Agents "Write" access to APIs?

All answers to this question.

Granting write access requires a "Defense in Depth" strategy. Never give an agent a full Admin token; use scoped API keys with the absolute minimum permissions needed (Principle of Least Privilege). Additionally, you should implement a "Human-in-the-loop" (HITL) requirement for any "destructive" actions like deleting files or merging PRs. You can also use a secondary "Security Agent" whose only job is to inspect the generated code or command for malicious patterns before it is sent to the execution environment. Sandboxing your execution environment (using Docker or E2B) is also non-negotiable for safety.

   Answered 2024-01-24 by Patricia Collins

Have you considered "Intermediate Confirmation" for specific keywords? You can set up a simple regex filter in your middleware that flags words like 'rm -rf' or 'delete' and pauses the agent until a human clicks 'Approve'.

   Answered 2024-01-25 by Steven Harris

• Steven, the regex filter for "destructive keywords" is a great low-tech win we can implement today. Patricia, we are definitely going to move to a sandboxed environment for the GitHub agent. We've decided that for the social media agent, it can draft the posts autonomously, but the actual "Publish" API call will require a manual webhook approval from our marketing manager. This gives us the speed of AI without the risk of a public relations disaster caused by a jailbroken prompt.

     Commented 2024-01-27 by Amanda White

Look into "Prompt Armor" or similar tools. They are designed specifically to detect indirect prompt injections that might be hidden in the data the agent is reading from the web.

   Answered 2024-01-28 by James Wilson

• Great resource, James! Indirect injection is often overlooked—an agent reading a malicious 'README' could be just as dangerous as a direct user attack.

     Commented 2024-01-29 by Patricia Collins