APIs have traditionally been designed around a fairly simple assumption: the software making requests is doing exactly what its developer intended. AI agents complicate that assumption.
More developers are giving agents access to APIs so they can search data, organize information, create things, update things, and generally act on their behalf. That’s useful, but it also changes how we need to think about API permissions. If I want an agent to organize my library, I need to let it make changes. I probably don’t want that permission to include deleting half my library because the agent misunderstood what I asked.
Bredbox’s API was designed with that distinction in mind.
Write doesn’t mean delete
A lot of APIs divide permissions into two broad categories: read and write. The problem is that “write” often means everything that changes data, including deleting it.
That makes sense from a traditional CRUD perspective. It makes less sense when the API client might be an AI agent. Bredbox separates API access into narrower read, write, and delete scopes, so you can give an agent permission to create and update information without also giving it permission to delete that information.
It’s a small distinction with an important consequence: you don’t have to choose between making an agent useful and giving it more authority than it needs. This is the principle of least privilege applied to the way APIs are increasingly being used today.
Some actions shouldn’t happen immediately
The Bredbox API is intentionally powerful. It gives you full programmatic access to your account, including operations that can clear all of your data or delete your Bredbox account completely. We think you should have that control because it’s your account and your data.
But having an API endpoint doesn’t mean every request to that endpoint should execute immediately. The most destructive account-level operations require a human confirmation step. If an API client requests that Bredbox clear all of your data or delete your account, we send you a confirmation email. Nothing is deleted until you click the confirmation link.
So a script can manage your entire account, but an agent with the same API credentials can’t accidentally wipe everything out with one bad tool call. The API still gives you control. The confirmation step protects the boundary where a mistake becomes irreversible.
MCP gets an even narrower set of permissions
Our MCP server takes this approach further. MCP is specifically designed to let AI tools interact with Bredbox, so its default permissions are deliberately more constrained than those of the full API.
By default, the Bredbox MCP server can read and write your saves and collections. That’s enough for an agent to do useful things like find saved content, add something to your library, update a save, or organize saves into collections.
Deletion is different. When an agent attempts to delete something, that requires a separate approval at the time of the request. The agent doesn’t silently inherit deletion rights just because you’ve allowed it to make other changes.
Some capabilities aren’t available through MCP at all. An MCP client cannot clear all of the data in your account or delete your Bredbox account. Those account-level administrative capabilities remain outside the MCP server entirely, and that’s intentional.
Give agents the access they need, not the access they might need
There’s an understandable temptation when designing an API to expose every capability as consistently as possible. For human developers writing deterministic software, that can be a nice property. AI agents make the tradeoff different.
An agent can misunderstand a request, select the wrong tool, or receive ambiguous instructions. As agents become capable of chaining more actions together without someone approving every individual step, the consequences of overly broad permissions become more significant.
We don’t think the answer is to make APIs less capable. The Bredbox API still gives developers full control over their accounts. Your library shouldn’t end at our UI. You should be able to build your own tools, scripts, integrations, and automations around it.
Instead, the answer is to be more deliberate about where that control is granted: separate read, write, and delete permissions; put a human confirmation step in front of exceptionally destructive operations; and give AI-specific interfaces a narrower set of capabilities than the general-purpose API.
These aren’t particularly flashy features, and ideally you’ll rarely have to think about them. That’s the point. AI agents are going to become a more common way of interacting with software, and we want Bredbox to give them enough access to be genuinely useful without requiring you to hand over the keys to your entire account.
Your library belongs to you. The tools you connect to it should only be able to do what you intended.