Rethinking API Access in the Age of AI Agents

Rate limits were designed for predictable clients with humans behind the screen. But AI agents act differently. They make decisions, call APIs, and post content without understanding context. Harm limiting is an emerging approach that focuses on how data is used after it leaves the API. It adds structure and guidance to help models act more responsibly and gives developers a clearer way to manage risk as AI systems become more autonomous.

AI is no longer just a tool. As it continues to evolve, it's taking on more active roles by issuing queries, triggering actions, and posting content on behalf of users. This shift changes the entire landscape of API access.

The systems we've built around API security were designed for predictable clients—browsers, services, and apps with humans behind the screen. However, those assumptions no longer hold when the actor on the other side of the API is a model, so it's time to start thinking about new layers of protection.

One approach is harm limiting: a framework that focuses not just on how often data is accessed but how that data is used after it leaves the API.

Rate limits were built to manage load. They prevent abuse by throttling requests when usage spikes. For human-driven clients, that works. But when the client is an AI system, the risks aren't just about volume. The model might behave differently than expected, not because it's malicious, but because it doesn't understand context the way a human does.

AI systems don't have an innate sense of boundaries. They don't recognize plagiarism. They don't understand copyright. They don't grasp the severity of crossing ethical lines because those aren't hard-coded rules. People grow up learning what's acceptable and what's not — but a model doesn't get that kind of gradual education. It just sees probabilities and outputs.

This becomes especially risky when we give models publishing power. A model might generate and post something that falls right on the edge of harmful or inappropriate. And for many users, especially those without technical backgrounds, there's no easy way to catch it. If a model provides one answer in the UI but sends a different request in the background, most users won't know how to look, much less what it means.

These kinds of mismatches between intent, action, and understanding are where traditional safeguards can fall short.

These problems aren't hypothetical. As models gain more access and start making decisions, things can go off track quickly, especially when the system they're calling isn't built to verify intent. And it's not necessarily malicious. The model is just responding based on probability and pattern.

There's growing recognition of this in the industry. Twilio recently published a post that looks at large language models as untrusted clients, like browsers or mobile apps, and shows how easily they can go rogue if API access isn't adequately controlled. Even with authentication in place, a model can still make the wrong call, unintentionally or otherwise.

That's precisely why rate limiting and basic auth aren't enough anymore. We need to look at different kinds of safeguard that will understand how models behave and anticipate how things might go sideways, even when the traffic looks normal.

Harm limiting builds on traditional API infrastructure by introducing a way to guide how data is used, not just whether or how often it's accessed.

The core idea is to give models structured signals about what they can do with the data they receive. That could mean tagging API responses in a way that clearly communicates whether something is safe to reuse, meant only for internal purposes, or requires additional review before being acted on. Rather than relying on reactive filtering after the fact, this type of system would offer guidance at the point of interaction. It isn't traditional content moderation, but a built-in layer of context that helps models act more responsibly before harm can happen.

We're already starting to see early steps in that direction. One example is MCP , the Model Context Protocol. It's not an industry standard yet, but it's a promising attempt to give models a more structured way to interact with APIs and other external sources, and something we're actively exploring in Cosmo. The idea is to provide models access with clearer boundaries so they're not just pulling raw data but understanding what they can do with it.

In November, Anthropic published an early draft of MCP that outlines how models can securely connect to different systems, from content repositories to development tools, through a common protocol. It's meant to reduce fragmentation and make it easier to build AI applications that know where the data came from, why it matters, and how it should be used.

Whether MCP becomes the long-term solution or not, it's a step toward the kind of infrastructure we're going to need.

This isn't just a model problem. It's a shared responsibility across the system.

Models aren't ethical actors. That's not a judgment—it's a limitation of how they're built. A model might find an entire blog post and offer it as a helpful answer without realizing it's just copying someone else's content. Or it might generate something that seems fine but crosses the line when published publicly.

That's why responsibility has to be layered. Models need some level of transparency. Users—especially non-engineers—need protections that help them trust what's happening under the hood. And API builders need tools to express how their data should be used, not just whether it's returned.

Some of that might involve requiring models to explain their actions, especially in areas like law, finance, or content generation. There are early signs of this with features like citations or reasoning chains, but those practices would need to become more consistent and enforceable.

Microsoft's AI Shared Responsibility Model offers a helpful framework here. It lays out how accountability should be distributed across cloud providers, developers, and end users, making it clear that no single group can manage these risks alone. Harm limiting follows the same logic, because it only works when responsibility is understood as something shared across the stack, not siloed to any one layer.

Zenity made a similar point in a recent blog post about AI agent security . With no clear federal regulation in place, and the U.S. even pulling back some of its earlier guidance, they argue that the responsibility is already landing on individual organizations. Teams are being asked to define their own boundaries, assess risk on their own terms, and figure out what "secure" means without much top-down direction. That shift in expectation is exactly why harm limiting matters. It gives teams a clearer framework to work with, one that is less about reacting after the fact and more about designing systems that guide behavior up front.

Getting to a functioning harm limiting system will be difficult. Currently, there's no shared metadata standard that communicates data classification in a way AI systems can reliably understand. It will take broad industry cooperation to get there, and there's a real risk that competition will slow that down.

But we've seen this kind of thing before. It took years to standardize ports like USB-C because every company wanted to protect its own system. It's easy to dismiss these details as small, but in practice, they matter. And when it comes to AI and data usage, the stakes are much higher than charging cables.

Some teams are already mapping out these risks. The Cloud Security Alliance recently proposed the MAESTRO framework as a way to threat model agentic AI systems : everything from prompt injection to unintended tool use. It's not directly about harm limiting, but it reinforces the same point: systems that act autonomously need more structured guardrails than what we've used in the past.

Creating this kind of structure won't be simple. But neither is the threat model we're facing.

More AI systems are gaining the ability to act, not just analyze. They can post content, make decisions, and take steps on behalf of users. As that happens, we need infrastructure that guides behavior, not just access.

Harm limiting isn't about blocking innovation. It's about giving models a clearer sense of what's acceptable and giving developers the tools to set healthy boundaries. Models don't come with built-in ethics. They reflect the systems we design around them.

Before opening the gates, we should ensure the systems we're building know where the boundaries are and why they matter.