AI agents, the Model Context Protocol, and the future of authorization guardrails

Recently, Cerbos co-founder and CPO Alex Olivier joined Luca Maraschi and Matteo Collina of Platformatic on The Node (and more) Banter podcast to discuss a hot topic: the rise of AI agents and the Model Context Protocol (MCP).

MCP has been touted as “the new API for AI” - a standard way for AI systems, like LLM-based assistants, to connect with external tools and data. This conversation unpacked what MCP is, why it’s needed, and how it changes the game for identity and authorization in modern applications.

You don’t need to have heard the podcast to follow along - but if you’re curious, you can check out the recording above. Let’s dive in.

What is the Model Context Protocol?

MCP is an open standard that enables developers to build secure, two-way connections between AI-powered tools and data sources. In simpler terms, MCP defines how an AI system, such as an MCP client, like a chatbot or coding assistant, can discover and invoke operations exposed by an MCP server, which wraps around a database, service, or any external tool. Instead of every AI application needing custom integration code for each data source, MCP provides one universal protocol to expose prompts, resources, and tools to AI models.

This standardization emerged because large language models (LLMs) on their own are isolated from live data and actions. They might excel at generating text or answering questions from training data, but they can’t, for example, fetch fresh information, execute database queries, or perform real-world actions without help. Early solutions gave LLMs “tools”, like a calculator function or web search, in an ad-hoc way. MCP formalizes this pattern. It lets AI agents maintain a session with a tool service and use a common language (JSON-RPC under the hood) to ask for operations and receive results - even streaming results in real time. Unlike traditional REST APIs which are request-response, MCP supports long-lived, stateful sessions where results can stream back progressively - for example, streaming logs from a long-running task. This suits AI use cases where the model may take many steps and needs intermediate feedback.

By design, MCP is client-agnostic and server-agnostic. An AI agent that speaks MCP can connect to any MCP-compatible tool server, whether it’s local or remote, without custom code. This decoupling is powerful. It’s akin to how the Language Server Protocol standardized IDE integrations for programming languages - MCP hopes to do the same for AI integrations. Developers can build one MCP connector for, say, a GitHub or database API, and any AI client (Anthropic Claude, a VS Code AI extension, a chatbot UI, etc.) can use it out of the box. As the speakers noted, we’re essentially adding a new layer to the modern software stack: alongside REST and GraphQL APIs for programmatic access, MCP serves as the “AI interface” for tools.

From APIs to MCP: a new paradigm for AI integrations

To put MCP in context, Luca recalled the progression of integration technologies over the years. We started with SOAP/WSDL web services with their own complex auth schemes, shifted to more lightweight REST/HTTP+JSON APIs secured by approaches like OAuth 2.0, and in cloud-native environments adopted service mesh and mTLS for service-to-service auth. Each era’s solution reflected what we were trying to connect.

Now with AI agents in the mix, the industry is once again adapting. MCP isn’t just another REST - it's a higher-level protocol tailor-made for AI interactions. It assumes that an AI, which might not be a person or even a single service, needs to perform a series of actions, possibly on behalf of a user, possibly asynchronously, and often spanning multiple tools in one workflow.

One big difference the speakers highlighted is streaming and asynchrony. In classic APIs, a client sends a request and gets a response, end of story. But AI-driven tasks, like an agent that executes a multi-step job, benefit from streaming outputs and continuous interaction. MCP supports a pattern where an AI client can start an operation and receive incremental updates (think of running test suites or long database migrations and getting live logs back). Matteo pointed out that this means MCP servers have to manage state and sessions more robustly - if an AI client disconnects mid-stream (e.g., a mobile user’s connection drops), it should be able to reconnect and resume without losing the thread. In fact, ensuring session continuity and not “dropping” partial results becomes a core concern in MCP implementations.

Platformatic’s own MCP server approach uses a Redis-backed buffer to store recent output chunks so that if the client reconnects, it can retrieve anything it missed and continue streaming results to the user. In other words, building a resilient MCP server involves more than just exposing a function call - it requires handling concurrency, session reattachment, and timeouts gracefully. These are new challenges for developers who are used to idempotent, stateless HTTP calls.

While these details are under the hood, they ultimately impact user experience. Nobody wants an AI assistant that loses its mind, or context, just because your Wi-Fi hiccupped. As MCP finds its way into mobile apps - for instance, the Claude AI mobile app now supporting MCP connections - solving these reliability issues is an active area of development. The community is already feeding improvements back into the MCP spec. For example, the protocol may incorporate more explicit acknowledgement of message receipts in the future to avoid the need for sticky sessions. All of this work is to ensure MCP can operate at scale and in less reliable networks, so AI integrations feel seamless to the end user.

Identity and permission challenges when AI takes action

Perhaps the trickiest aspect, and one that was a major focus of the podcast discussion, is security. Specifically, how do we handle authentication and authorization in this new MCP-mediated world? In a typical API call, there’s a user or service identity making that call, carrying an access token or API key, and the service can validate that token and enforce what that identity is allowed to do. With AI agents and MCP, things become more nuanced:

• Multiple parties in play. When an AI agent initiates an action via MCP, it’s effectively acting on behalf of a user. For instance, you ask an AI assistant to schedule a meeting via a calendar MCP server - the agent needs to use your identity or a delegated credential to perform that action on your calendar. So now we have a human user, an AI client, and a tool server all in the chain, each potentially with their own identity and permissions. The protocol needs to convey who the original user is and get consent for the agent to act for them.

• Delegation and scoped access. Alex noted that it would be dangerous to simply give an AI agent a blank-check token that has all your privileges. Just because the agent is helping you, say, manage a database, doesn’t mean it should have full database admin rights. Ideally, we want to delegate only a subset of permissions to the agent - enough to do the task at hand, and nothing more. This concept isn’t entirely new (OAuth has the notion of scopes, and “on-behalf-of” flows, etc.), but applying it to AI agents is leading to new ideas like transaction tokens. These are short-lived, restricted credentials that an agent could use, which encode not just the user’s identity but also the specific context or transaction it’s limited to. There are active efforts in standards groups (OpenID Foundation that Cerbos is a core member of, as well as the IETF working groups) to define how an AI agent might get a token that says, in effect, “User X has authorized Agent Y to do these specific actions for the next N minutes” - and nothing beyond that.

• Complex auth flows and user experience. Matteo expressed some healthy skepticism about the user experience of connecting AI tools securely. Imagine the first time you connect an AI agent to your system - there might be an OAuth 2.0 device authorization flow or a pop-up asking you to log in and approve certain access for the agent. We’ve all seen those “Connect this app to your account?” consent screens (e.g., “This app will be able to read your calendar and send emails on your behalf”). Now, an AI agent may need to negotiate such a three-way authentication: the AI client, the MCP server (resource), and your identity provider all need to dance together. OAuth 2.0 can handle it (it’s essentially the same as any third-party app integration), but it’s not trivial. The MCP spec recently evolved so that the AI client (like your chat app) acts as the OAuth client on your behalf, and the MCP server acts as the resource server. In practical terms, this means when you set up a new MCP connection, under the hood the AI app does a dynamic client registration to your IdP, gets client credentials, then triggers an OAuth flow for you to grant access. It’s a lot of moving parts - ideally made as simple as clicking “Authorize” once. The hope is that once these flows are standardized and implemented, using an AI agent with your internal tools will feel as straightforward as using “Sign in with Google” on a website.

All of this needs to be done with strong security in mind, because an AI agent will be capable of doing real damage if misused. Alex gave a timely example: there was a recent incident where an AI coding assistant, via a Replit “vibe” coding tool, actually deleted a company’s entire database in seconds without proper permission. The LLM “agent” in that case acted recklessly - it had been told not to make destructive changes without confirmation, but it ignored that and dropped the DB tables. This kind of scenario underscores why we must put guardrails and checks around AI-initiated actions. It’s not enough to trust that the AI will always follow instructions or policy by itself. We need external control points.

Putting guardrails in place - dynamic policy and human-in-the-loop

So what can we do to prevent AI agents from going rogue or making mistakes with serious consequences? The podcast conversation converged on a clear answer: use dynamic, contextual authorization policies as guardrails. In other words, every action an AI agent tries to perform should be vetted against rules that consider who the agent is acting for, what it’s trying to do, and under what conditions. This is analogous to how we secure human-initiated actions, but with some new twists.

Alex likened it to the risk engines in banking or other sensitive systems. Think of when you try to make an unusually large transaction on a new device - the system might ask for additional confirmation, such as a fingerprint, 2FA code, etc. because it deems the operation higher risk. We can apply similar logic to AI agents. For example, if an agent wants to delete a database or approve a large financial transfer, the policy could require a “step-up” authentication - essentially pausing the agent and asking the user “Are you sure you want to do this?” or requiring the user to re-authenticate before proceeding. This is often called a human-in-the-loop checkpoint. It ensures that even if the agent has the technical permission, a human gets to double-check high-impact actions if risk is high.

Another aspect of guardrails is continuous context monitoring. Because AI workflows can be complex - an agent might call tool A, then tool B, then loop back to A - an authorization system should be context-aware. It should know, for instance, that “this sequence of actions was initiated by User X at 3:45PM via Agent Y, and has so far touched these systems.” With that context, policies could enforce limits like “if more than 5 database deletions are attempted in one session, halt” or “deny any file access if the request comes from an agent and the user hasn’t been active in the last hour.” These are just examples, but the point is that fine-grained policies can prevent unintended consequences. An AI might not understand the real-world implications of dropping a table or sending an email to all customers – but our policies and audits can catch those before they execute.

The group also noted that this doesn’t necessarily require fancy “AI to govern the AI.” In fact, a lot of it can be done with established policy-as-code techniques. For instance, Cerbos, the authorization implementation and management solution, allows writing rules that take into account roles, time of day, resource types, and even custom conditions. Those same constructs can be applied here. If an AI agent is associated with a user identity and perhaps a special “agent” role, you could write a rule like: “Agents acting for a user cannot perform delete operations on production data unless a human explicitly approves”. Or “if the action is outside the user’s typical permissions, always deny”. Crucially, these decisions happen at runtime, on every single tool invocation. This is the idea of continuous, contextual authorization - never relying solely on a one-time token or static role mapping. It’s a natural extension of zero-trust security: “never trust, always verify” applies just as well to AI-driven actions as to network requests.

If you’re looking to safely expose tools to agents without compromising control, reliability, or auditability - try out Cerbos Hub, or speak to an engineer for further details.

In practice, implementing this means externalizing the authorization logic from the AI agent and the MCP server into a dedicated policy engine. That way, the rules can evolve easily without changing application code, and you get a centralized audit log of every decision. It also makes it easier to incorporate additional context (risk scores, session info, etc.) because the policy engine can be fed all that metadata per request. Alex mentioned that the fundamental components to solve this already exist - we just need to apply them in this new context. The same blueprint that secures microservice-to-microservice calls (identities, tokens, a policy decision point, and an audit trail) can secure AI agent actions. We may be dealing with a non-human actor, but the security principles don’t really change.

Architecting secure MCP integrations without the headache

Bringing together the above points, what might a secure architecture for AI agents using MCP look like? A likely pattern is emerging:

• Establish identity for the agent’s session. When a user initiates an AI agent session, for example, connecting an AI assistant to their Slack or database via MCP, the system should go through an OAuth authorization flow. The result is the agent obtains a token that represents “User X, via Agent Y” with appropriate scopes. This token might even be a special transaction token limited to just this session. Standards and tools are still catching up here, but the idea is to avoid blind trust in the agent. All actions carry an identifier that ties back to the real user and the specific delegated rights.

• Use an external Policy Decision Point (PDP). The MCP server - which actually executes the tool actions - should not hardcode the permission logic for each action. That would get very messy and hard to update (imagine littering if (role == admin) checks all over your code). Instead, the MCP server can ask an external PDP service whether the current identity is allowed to invoke a given tool. This is exactly the model of Cerbos and similar policy engines. The MCP server defines all the possible tools it could perform, but right before execution it checks “Can user X (through agent) do action Y on resource Z now?”. The PDP evaluates the policies and says “allow” or “deny” (or even “require elevate” if we implement step-up prompts). In the Cerbos integration demo, this pattern is used to dynamically enable or disable each tool for the AI session - so the agent literally only sees the tools it’s permitted to use. If the user’s permissions don’t allow deletes, the delete command might not even be advertised to the AI model, preventing it from even attempting a forbidden operation.

• Maintain audit logs and visibility. Every action attempted and its outcome (allowed, denied, etc.) should be logged. This is critical not just for compliance, but for building trust with these AI systems. If something goes wrong, you need to trace back and see, “What did the AI try to do? Why was it allowed? Who approved it?” In a way, AI agents will force the issue of robust auditing - something that is good security hygiene regardless.

One encouraging thought is that enterprises don’t have to reinvent their security stack for this. They can leverage what’s already working: established identity providers (for single sign-on and token issuance), proven authorization services, and best practices from zero-trust architecture.

What changes with AI and MCP is just the scale and dynamic nature of calls. We might go from a few dozen API calls to thousands of fine-grained tool calls per user session. But modern policy engines are built for throughput and low latency, and handle ephemeral identities well (for example, Cerbos is stateless and can evaluate policies on any identity or token that comes in, without pre-configuration). In fact, Cerbos and others have been preparing for this moment by supporting rich attribute-based access control that can take into account time, risk scores, hierarchical roles, and more - exactly the kind of nuance we need for AI agent governance.

Looking ahead: AI-ready authorization

As the discussion wrapped up, Luca posed a forward-looking question: where is all this heading in the next 3–5 years? Alex’s perspective was that we’re moving to a world where every action, whether by a human or an AI, is checked against policies in real time before it happens. In essence, authorization becomes an active enforcer at runtime, not a static gate. This is the principle of zero standing privilege - nothing (no user, no machine) has indefinite blanket access, and everything is verified contextually each time. AI agents amplify the need for this approach because they blur the lines of who or what is making a request. You can’t assume trust based on a one-off login or a single API key configured somewhere. Instead, the system must ask on each step: “Should this particular action be allowed, given what we know right now?”

It might sound like a tall order, but with the right building blocks it’s achievable, and likely necessary for safety. The exciting part is that this doesn’t stifle innovation; it enables it responsibly. If developers and architects know they have fine-grained control and visibility, they can feel more confident rolling out AI-powered features. We’ve seen a burst of creativity with AI agents integrating into IDEs, browsers, business apps - MCP itself is evidence of that momentum. By baking security and policy into the design, we won’t have to hit the brakes on this progress due to an avoidable mishap or breach.

Conclusion

In summary, the emergence of MCP marks an inflection point. It opens up powerful new integration possibilities, letting AI systems interact with the world in richer ways. At the same time, it forces us to confront age-old security questions under a new lens. The podcast conversation highlighted that while technology evolves, fundamentals like least privilege, need-to-know access, and defense in depth remain crucial. The good news is we have tools and methodologies to address these challenges - we just have to apply and adapt them to the AI context. By combining open standards like MCP with robust identity and authorization practices, we can harness AI agents to their full potential without losing control of our systems.

If you’re building or deploying MCP servers and are unsure about how to secure them, we’re here to help. We’ve put together a detailed guide on implementing fine-grained permissions for AI and MCP servers agents using Cerbos, and we regularly work with teams on this evolving challenge. Feel free to book a workshop with our engineers to explore how to put these guardrails in place, and check out our on-demand webinar for a deeper technical dive into dynamic authorization for AI and MCP.