Securing the Future: How to Safeguard MCP and Agentic AI with Teleport and AWS

As enterprises rapidly adopt agentic AI and large language models (LLMs) to automate critical business processes and access sensitive data, the traditional security playbook is no longer sufficient. The Model Context Protocol (MCP), a new connector for AI systems like Amazon Bedrock Agents, is revolutionizing enterprise integration—but it also introduces new risks.

Join us for an in-depth session exploring how to secure MCP-based AI architectures using Teleport’s Infrastructure Identity Platform and AWS. We’ll cover:

• What makes agentic AI and MCP transformative—and uniquely vulnerable.
• Why treating AI agents like human users is critical for identity and access management.
• How to eliminate static credentials, enforce least privilege, and gain behavioral visibility for AI systems.
• Real-world strategies for implementing fine-grained access controls, audit trails, and compliance-ready deployments.

Whether you’re a platform engineer, DevSecOps leader, or AI architect, this session will give you the blueprint to secure the next generation of intelligent automation at scale.

Key topics on Securing the Future: How to Safeguard MCP and Agentic AI with Teleport and AWS

• AI adoption is accelerating rapidly, with 78% of enterprises implementing AI solutions, but 44% are encountering security breaches and negative consequences.
• AI agents, which often have broader system access than company CEOs, are being treated as code rather than non-human identities that require proper access controls.
• Current MCP implementations rely on static secrets and API tokens.
• AI breaches cost an average of $4.4 million per incident.
• AI agents should be treated as non-human identities requiring the same governance as human users.
• Teleport provides certificate-based authentication with short-lived, ephemeral credentials that eliminate static secrets; this approach enables fine-grained access controls, real-time auditing, and automatic credential expiration.
• The solution involves using AWS Security AI Innovation at Velocity framework for structured risk assessment, implementing threat modeling with tools like AWS Threat Composer, applying OWASP Top 10 for LLM Applications mitigations, and leveraging Teleport as an identity broker and access proxy.
• This solution transforms AI from a security liability into an enablement while maintaining enterprise-grade security controls.

Expanding your knowledge on Securing the Future: How to Safeguard MCP and Agentic AI with Teleport and AWS

• White Paper - Securing the Model Context Protocol: Access, Authorization, and Audit for Enterprise AI
• Learn - Model Context Protocol (MCP) Definitions, Terminology, and Architecture
• Blog - Securing Model Context Protocol (MCP) with Teleport and AWS
• White Paper - Automation is the New Attack Surface: Securing Non-Human Identities (NHIs) at the Infrastructure Layer
• OWASP Foundation - OWASP Top 10 for Large Language Model Applications
• GitHub - AWS Labs/Threat Composer

Transcript - Securing the Future: How to Safeguard MCP and Agentic AI with Teleport and AWS

Introduction

Kateryna: Good morning. Good afternoon. Good evening, everyone. Thank you for joining us today. We’d love to hear where you’re joining from in the chat if you want to take a second to let us know. I’m here in sunny Santa Clara, California. Dylan, Boris, where are you joining from? North Carolina, sweet. Oakland, Vancouver? Well, again, thanks everyone for joining us. My name is Kateryna. I’m one of the moderators for today’s session. Along with my colleague, Camden, we’ll be in the background engaging with all of you in the chat. We’re joined today by Dylan, Partner Solutions Architect at AWS, and Boris, Special Solutions Engineer at Teleport. We’re so excited to talk about AWS and MCP, and all things AI in today’s session. But before handing it over to Dylan and Boris, there’s just a couple of housekeeping things to cover.

Kateryna: So please note this big purple section to the right of your screen, and there are tabs at the top. So there’s the main chat tab, the docs, and Q&A at the top. So feel free to use it to post comments, kind of answer any polls — I know Boris will be launching one shortly — and engage with us there. We’ll keep an eye on it throughout the webinar. If you have any questions, please go ahead and submit them in the Q&A tab. We’ll address those at the end of the webinar. And there are a couple of useful links, blogs, documentation linked in the docs section, including the OWASP Top 10 relevant blogs and reference architectures. And last but not least, you will be receiving the recording of the session 24 hours after it ends. So please don’t worry about taking notes, taking screenshots. You’ll be getting that delivered in your inbox. So without further ado, I’d like to hand it over to Dylan and Boris. Let’s get started.

Boris: Yeah. Give me one second to share screen. So actually, as Kateryna said, Dylan and I are here to talk about AI and what that means and, hopefully, what that means to you. But before I fire it up, and while we are just still chatting and people are trickling in, I would like to open up a poll, which hopefully is open now for everybody. If you don’t mind, just answering — it doesn’t really have to be a multiple choice here. Just give us an idea of where you are in your AI journey, or if you do not have any AI journey to starting point, if you will, yet. What we’re finding is that everybody has kind of been given the marching orders, “We want AI.” And that means very different things to almost everybody. So it will be useful to know where everybody, at least live, stands today. I’ll keep this open only for a little bit longer. It’s just kind of to gauge everybody’s understanding of the problem, I guess, I should say. All right, I’m going to go ahead and close this for now. And I believe our presentation should be up on the screen now, and everybody can see.

AI adoption soars – enterprise AI is in crisis

Boris: So let’s dive in. Feel free, as Kateryna said, to ask questions in the chat. That would be a great way to keep this as interactive as we can. But where I will take this story, if you will, is first and foremost, this is not me just kind of pulling these numbers out of thin air. McKinsey just published their current 2025 State of AI Report, and 78% of all industries are reporting that they have, whether it’s the incentive or the top-down order of, “Look, we need to bring AI into our world. We need to figure out how to leverage it to increase productivity, to increase the dollars — that we get more work out of the dollars we’re spending, etc.”

Boris: The downside to this is that about 44% of those companies that are currently trying down this path are running into problems, and negative consequences here is being kind of mild. We are truly talking about actual breaches and problems that arise from using a new technology without kind of thinking about the problem more holistically, around how does it function within an enterprise? So as you kind of enter the AI space, you hear about AI as agents, MCP as a protocol. You see that people are implementing these technologies and are implementing these stacks. And the problem that is arising is that agents, which are autonomous and can truly make decisions that are non-deterministic, have production access to things that they should not have production access to. They are accessing data that it was not intended for them to have access to.

Boris: Again, in the same McKinsey report, only 27% of enterprises are actually looking at the output of what an agent generates or what an LLM generates before kind of, I don’t want to say blindly, but applying set output and utilizing it to do work. I am not attributing the quote that you see to anybody because it was something that I heard in passing at the Black Hat Convention Floor a couple of weeks ago, but it is very, very true. AI has access to more systems than the CEOs of companies, and that should, at the very least, give pause to everybody.

Real-world AI and MCP breaches are already happening

Boris: All right, so let’s actually attribute some numbers to what I’m talking about. $4.4 million is about how much it costs any time a malicious attacker is able to breach an AI system. That is a lot of dollars, right? Beyond that, there is over a half a million dollars of people just testing out and trying out AI tools, whether it’s Claude Desktop, whether it’s OpenAI, where it’s anything, you know, Cursor, etc., those things become problematic at scale, right? And whenever it’s a small business that is doing this, obviously, the costs are very different when you scale it up.

Boris: And also, just to mention this, we do have the poll results. I will fire those up when we kind of get towards the meat of what we’re presenting today. So don’t worry, we will get back to it at some point. And again, I am not inventing this here. There are real-world examples of AI leaking data nearly daily, right? You go into your LinkedIn feed. You go into your Google News. You go into whatever you consume, tech news. Somebody is having issues with AI leaking data, somebody gaining access through convincing AI to do something that it shouldn’t do, etc., which, at the end of the day, becomes a big problem and a big security issue within any organization.

What is Agentic AI?

Boris: So let’s kind of break down the problem, right? I keep talking about AI, and then I keep talking about MCP. So let’s kind of define what these things are and what we’re referring to here. Agentic AI is ultimately AI systems that do not answer just questions. It’s not the chat box that a lot of us are used to. They take action. Now, taking action means that they can go and troubleshoot a system. If you’re a Kubernetes user, think about the amount of times you have to go and figure out a problem within Kubernetes. And there are many components to a Kubernetes cluster that you have to go and pull logs from. You can have an agent that does this for you. Or on the other end of the spectrum, think of a financial system and quantitative trading. I can create an AI agent that executes trades for me, right? Maybe I should hashtag not financial advice here, but their systems exist. And they are out there in production doing these things, firing off actionable and consequential things within enterprises.

Boris: So the power that we give an agent means that they can carry out multi-step processes, they can remember context, and they can adapt their action, which ultimately means that we no longer have the kind of deterministic input and output from, say, a CI/CD system or anything else. We now have an always-evolving and always-adapting function, which again, makes them nearly as useful as a human system user. They can ultimately function like an employee, but are uniquely vulnerable to things that a human is not. If an AI is strict and misused, it will do damage, right? It will do real damage as we establish with real dollars at stake, with real problems at stake because it has the agency that we have given it to make changes in our world. So we need a way to secure them in a way that we already secure our humans and our regular employees and our human identities.

What is Model Context Protocol (MCP)?

Boris: Let’s keep moving to, what is MCP, right? MCP is the connective tissue of AI agents. It extends beyond just agents, right? You have heard it in relation to Anthropic, who released it to the world last year in 2024. It is, at this point, about exactly a year-old protocol, but it has taken up kind of the world by storm, and everybody has adopted it, which makes it fantastic to plug your LLM and your agent in your desktop application to a database, to a CRM, to GitHub, to all of the systems that you want to provide your agent or your LLM with context or plug it in for context, right? One of the things that you hear in all of media is that, yeah, the more context you can give an LLM, the better the end result is. So MCP gives you the ability to act as the USB-C of AI, right? I just go in and plug in my LLM in all of the ports that I want to and have it ingest that data, and then ultimately improve the interoperability of my system.

MCP & Agentic AI – new security challenges

Boris: The problem with all of this, adoption and explosion, is that giving AI access to systems raises a completely new set of security challenges. So what are some of those, right? To not sound too cliche, but with great power comes great responsibility here and, unfortunately, a whole bunch of new risks, right? First, by wiring AI into everything, we’re expanding the AI attack surface, or just the overall attack surface of the system, nearly exponentially. If an AI can touch a system, a clever attacker can try to piggyback through either the same connection, through the credentials that he has, through prompt injection, through a whole slew of things that currently do not exist, right?

Boris: Second, a lot of current MCP implementations are having to rely on static secrets, whether it be API tokens, whether it be environment variables, whether it be service accounts. Your agent might have a key to, let’s say, an internal database, right? If an attacker is able to, through whatever means, get access to that key and leak it, it is now theirs to do what they want, which is not kind of the world you want to live in. The kind of more unfortunate problem with the explosion of AI, with the explosion of agentic systems, with the adoption of MCP, is it made things so easy, we have kind of given agents blanket trust. It is easier to just give broad access to an agent or to your desktop application, desktop LLM interface that says, “Hey, do this and it just works.” Right? The ease with which we’re kind of chasing the, “No, I want the usability of give me access to all the data, give me access to all the context,” gets lost in the, “Well, now, my agent literally has more access than the CEO or the CISO of the company.”

Boris: Tie it all into the fact that there is no native definition of what oversight means when doing agentic AI and when using MCP — means that you don’t inherently log or restrict what that connection can or cannot do. Unlike, say, humans who often have IAM policies and audit logs, an agent does not have to adhere by those standards by default. You could obviously code and create the agent in such a way that it has those things, but it is not something that is given to you out of the box in an easy-to-use way. So okay, let’s start diving into kind of the security of all of this.

AI security in focus

Boris: Earlier this year, OWASP — hopefully, everybody’s kind of familiar — released one of their top 10 lists. And they have done an official kind of — not pivot, but they have turned it into an official Flagship Project to maintain the top 10 risks for AI. To me, that’s a very strong signal that LLMs and AI security has now kind of become a mainstream concern, which, again, is a problem, because it is a secondary thought yet again in yet another new thing that we are bringing into our lives to make our lives easier. And instead of baking it in from the start, we are thinking about what this means after the fact.

Boris: The no.1 threat that they identify is prompt injection. Prompt injection is basically trying to trick the AI through inputs to do things that it was not designed to. Whether it’s through passing in what to a human looks like garbage code or whether it is looking like an actual piece of code that is being asked to be executed, these things happen, and they happen directly to the user that is interfacing with the system and crafting these prompts, and indirectly, such as actual malicious attacks that are trying to insert themselves midstream and send off malicious information down the pipeline. It’s number one because it’s both common and potentially very impactful.

Boris: An attacker can manipulate an AI to do things it shouldn’t, bypassing all of the traditional human checks that we have in place to make sure that Boris is not allowed to access system A, B, and C, and he cannot go and do rm -rf on the root partition if he doesn’t by default. All of this, again, not theoretical. Just this August, a team of researchers crafted an indirect prompt injection in a Google Calendar invite. Before the webinar started, I had four Google Calendar invites for meetings that are happening the rest of the week. I clicked on all of them blindly and said yes. This calendar invite literally had a Gemini prompt injection baked into it. I, as the end user, do not see it, but Gemini, who has complete access to my inbox, sees it and triggers the hidden instructions that arrive in the crafted invite. And now, the attackers had access to the victim’s smart home with privileges to turn off apartment lights, turn up their boiler’s temperature, flip shutters on and off in the house.

Boris: Now, we’ve seen the Amityville Horrors. We’ve seen Texas Chainsaw. This is on a whole new level, right? Now, my computer is trying to attack me. Stuff of nightmares, at least to me. And once this happens, you can’t do anything, right? It’s not like I can go and cut a wire to mitigate access to this. Instead, I need a way to lock down what access and how an agent or how the communication to my systems happens. So Dylan, I’ve been talking a lot here, but I think that there is obviously kind of a scoping problem, if you will, around all of this. I’ve been talking about agents. I’ve been talking about ChatGPT and Claude. I’ve been talking about connecting desktop applications. Depending on the scope of the problem — depending on the scope of the application — there are different things to kind of work through here. You want to talk about that a little bit?

Dylan: Yeah, sure. Love to. Yeah, thanks for bringing that up. So maybe before we jump into the Generative AI Security Scoping Matrix and kind of my top talk track, as we switch gears, it’d be great to maybe review the poll quickly. So I think to do that, we have to turn off the share screen.

Boris: Yeah. One second. I think I can —

Dylan: Yeah, just to your point before we jump into — while the poll gets shared — oh, here we go.

Boris: Yeah. Yeah. So I think this is great. Yeah, the visibility in AI actions, I would say, is probably the biggest miss, kind of as an industry that we did, with adopting all of this at the scale that we have. Compliance requirements, yep, that totally makes sense to me.

Dylan: Yeah. I think it’s really interesting to your point about the visibility on the AI actions too with the point on them acting autonomously, right? That’s a really interesting paradigm. So great point there.

Generative AI Security Scoping Matrix

Boris: Yeah, for sure. Okay. I will dive back into the discussion, but we’ll come back to this towards the end when we get into Q&A because I think this becomes kind of even more relevant by then. Stop sharing. One second. Let me come back in here. All right. So let’s talk about scope?

Dylan: Yeah, thanks. So one of the things I wanted to focus on today is trying to give immediate value to folks, like in the chat I heard talking about — how do you start scoping this, right? How do you think about this stuff? So for us, we want to help kind of create a framework for thinking about the AI security posture, right? So the way to think about this is classifying use cases. So are you using Consumer AI? We talked a lot about ChatGPT. That’s obviously the most popular one right now, but also things like Alexa, right? Midjourney, right? So that’s a Scope 1. It’s really just focused on the lowest control. You have to focus on data sovereignty, things like that. But as you move towards Scope 3, for example, you might focus on access controls, right? You’re using pre-trained models, but you’re building the application yourself. Maybe you’re using Amazon Bedrock with Anthropic’s Claude or something like that. Maybe you have embedded retrieval augmented generation, so there’s data that the large language model has access to. And then Scope 5, where you’re maybe training your own model from scratch. So there’s higher risk because of the data classification. Maybe the data that the models are actually being trained on could be impacted to the point from the OWASP, right?

Dylan: So the key insight here is that your security controls have to match your level of AI ownership, depending on how much you delegate. It’s kind of like the security shared responsibility model. You can’t apply the same security approach to, let’s say, a consumer chatbot that simply reads your documentation versus a custom-trained model, like Boris’s joke earlier about financials, if it has access to financial data, right, that’s not something you’d want to have publicly available. You also want to apply a threat modeling methodology to the AI workloads. This is not new, and I think you’re going to find that a lot of the things we talk about with AI security is not different from application security. So what are we working on? Are you documenting your data flows, assumptions, and business context? What can go wrong? Use frameworks like the OWASP Top 10 for LLMs. People are out there thinking about it full-time. Delegate that thought process towards those kind of standards and frameworks.

OWASP top 10 for LLM applications - mitigations

Dylan: What can we do about it, right? So preventative controls and detective controls. So use identity to block access, but also have, to the poll’s point — have visibility into what happened. And then at the end, always assess. Try to avoid blame. Did we do a good enough job? So validate your assumptions and test them. So this is what we call AWS Security AI Innovation at Velocity. In the information section of the webinar, actually, there’s a great blog on this topic. I highly encourage reading about that. But if you have this approach, you can move fast and deliver business value, which I think is what we’re all trying to do here. But you also have a structured way to identify and mitigate those risks upfront rather than discovering them in production.

Dylan: So summary, understand the risk, classify risk, align a security framework or a set of standards, like OWASP. Obviously, things like GDPR in the chat and threat model and protect the tolerance of the business. Sorry, Boris, I can’t see your screen, but I’m on the next slide now. So back to the OWASP top 10 for LLM applications, right? We talked a little bit about some of those points, but just to really drive home the Security Scoping Matrix. When you go from Scope 2 to 5, your number of potential mitigations that you’ll have to mitigate are going to go up. There’s going to be a higher responsibility. In a Scope 2 application, many of those responsibilities are going to lie to the application provider or be provided as mitigation is already integrated, right? So if you’re doing a scope three, four, five, you’re going to have to carefully select the tools you use, especially to simplify the implementation of your mitigations. Example is using things like a managed service that provides built-in security tooling while help implement those mitigations.

How data flows in a generative AI application

Dylan: So I want to talk a little bit about, what does it actually look like in generative AI application? We’re going to do a little bit of threat modeling here. We’re going to do a little bit of application discussion. Frameworks are super exciting, right? But let’s get to something you can take away right away and apply. So this is how a typical generative AI application is built. It’s no different for direct to consumer or end user or agent to agent. It’s fairly similar across the board there. An app receives input from a user, as we call it as a prompt. Those app queries can be from custom data sources, like MCP or agents. The app formats the user input and customer data into a prompt. The prompt is completed by a model, whether it’s fine-tuned or pre-trained or general LLM. The completion is processed by the app, and then the response is sent to the user or agent, right? So depending on the solution and services you’re using, your responsibilities are going to differ.

Dylan: For example, if you own only — maybe you consume just the application portion, right? I’m basically on Step 2. You don’t have to worry about the customer data, the fine-tuning, right? Your security will be looking a lot different comparatively if you own the whole end-to-end workflow. So, on that point, I’d like to start talking a little bit about threat modeling, right? So if you’re for not familiar with threat modeling, what it is — is basically asking a couple of questions, as I mentioned earlier. What could go wrong? What are we working on? What are we going to do about it? And did it work, right? So we definitely recommend threat modeling your Gen AI workloads and agents. The reason being is that I think this enables you to actually adopt these tools and answer questions back to your stakeholders about — how are we doing this securely?

Threat modeling

Dylan: One of the things that I’ve come across as my background in the security field community at AWS is when we’ve surveyed CISOs at scale, right now, the challenge is that because it’s so new, we’re not comfortable to actually adopt. But with threat modeling, you can really confidently say — we’ve assessed the situation, and we can adopt, right? So do you currently follow a threat modeling process when designing new workloads? Quantify, identify, mitigate security risks? What are the outcomes, right? Is the threat modeling done by a central security team or by the product teams themselves, right? Threat modeling is designed to provide a systemic approach with the aim of finding and addressing issues early in the design process.

Dylan: So why? It’s good to know what can go wrong, right? We talked a little bit about the stakeholder portion and adoption, right? So you want to do it early, and you want to do it at a point where there’s flexibility on the threats you’ve identified, like software bugs. The earlier you identify those threats, the more cost-effective it is to address them. So a threat model will help you ultimately do that. It’s also a living document, right? I think all of us who are going through this right now, two years ago, we weren’t really even talking about agents in MCP. Well, obviously, MCP, it was not invented by that point. But what I’m trying to say is the landscape changes every six months, maybe even faster than that. As breakthroughs come in through with LLM technology and new standards are created, right, your model is going to change. So it needs to be a living document. You should be revisiting and changing it whenever there’s a major change in the adoption.

Dylan: Let’s talk a little bit about what’s on the screen here. So we’re going to do a quick example threat model on this. As you can see, this is a very basic application. We have a malicious user who’s trying to get to maybe let’s call it sensitive data in an Amazon S3 bucket, right? The typical user workflow would be going directly to the Amazon API gateway. Maybe that’s secured. It’s going to the AWS Lambda function, which then accesses Bedrock, and Bedrock uses retrieval augmented generation to get data from the S3 bucket. Maybe there’s a malicious user who’s just trying to get into that sensitive data. They don’t care about the application or the value of the application. They just want the data, right? So you can immediately look at this and go — is the S3 bucket public? That’s an obvious example. Because then you wouldn’t need to go through Amazon API Gateway or Lambda or Bedrock to get to the S3 bucket. You could just go directly to the URL and get the sensitive data, right? So it’s pretty easy to say what could go wrong if the S3 bucket is public or if the API gateway isn’t locked down. So that’s the kind of approach it makes sense to take when you’re thinking about this and how you want to align your things, like the security scoping matrix, right?

AWS Labs’ Threat Composer

Dylan: So at AWS, we maintain an open-source tool called Threat Composer. So I don’t want to just tell you quickly about what threat modeling is. I want to give you something you can take home right now and use for free. It’s open source. There are many ways to do threat modeling, each with their own pros and cons. Of course, your team might already have a standard process. Threat Composer provides a prescriptive way to write threats with the aim of making it easier to make them useful. So there’s examples already to help you understand what a [inaudible] might look like. These are being used with generative AI today. This can be used as inspiration for a starting point, right? There’s insights, supports the non-linear, collaborative nature of threat modeling, right? So I don’t need to go too deep into that. I want you to know, though, that there is a tool out there today to help you threat-model for your agent workloads, and it’s available on GitHub. And there’s also a live demo set up. The links are going to be in the webinar slides there. So again, when you’re starting to align to things, like OWASP or NIST or GDPR, Threat Composer will help you align to that.

Dylan: To get back into the threat modeling portion, I want to talk a little bit about how — as an example, let’s say we’ve now assumed — we’ve figured out the threats, what could go wrong, right? We’ve already established the first two points. What are we going to do about it, right? So this is an example right now. We know that malicious user is trying to get into S3 to get the sensitive data, right? So now, Teleport is in the solution. How do you start with identity verification, right? So every request, whether from a legitimate user or a malicious user, will now have to authenticate through identity platform, specifically, obviously, Teleport Identity Platform. So cryptographic, identity verification, certificate-based authentication, malicious users are going to hit that stop sign because they simply can’t get past that checkpoint. So if you look for the application layer, the request is going to flow through the API gateway. Again, fine-grained authorization policies. So if you see the IAM resource policies, for example, that should all be fine-grained. So if a user was to get past the initial point, let’s say they’re identified, they managed to become a user, but they’re not mapped to a certain set of resources, because it’s fine-grained and least access, they won’t have access over to the resources, even if they have access to the application. So again, overprivileged access. That’s what we want to eliminate for. Again, you’re going to see a lot of themes that this isn’t so different from regular applications.

Dylan: At the workload level, AWS Lambda connects to Bedrock. AI agents themselves have unique identities, right, which Boris is going to chat on in a few minutes here. They’re not running the static service account credentials. They’re getting just-in-time access tokens, scoped to specific functions, data protection, IAM resource policy controlling S3 access. Teleport integrates with AWS- native controls. So it’s not about replacing the existing security. It’s about enhancing it. So again, the poll mentioned auditing access. Teleport will fit in very well with that. So the point of this is that there are multiple security checkpoints. Each system is treated independently. They’re unified so that there’s not friction to adoption. The hops in the chain are authenticated, authorized, audited. And if a component is compromised, the blast radius is contained to that system, right? The goal is to transform a liability into an enablement, really, right? And think about how it can scale if maybe new features are added. So threat modeling isn’t just about saying, the business, that we can’t do something. It’s about enabling them to move faster. But yeah, so maybe now we can start chatting a little bit about the paradigm around AI agents as identities, not code. So pass that back over to you, Boris.

Boris: Yeah. So I think the kind of big summary here, and I buried the lead at the start for those that were paying close attention. But the problem, as I see it today with how we implement agents and how developers and companies think about agents, is more to do with the fact that they are trying to just treat it as another piece of code, as just another, say, CI/CD pipeline, as just another process. And they’re just not, right? They need to be treated as non-human identity. For those that are not familiar, non-human identities, you’re already using quite a large number of them in your service accounts, in your machine credentials, in your SSH keys.

Treat AI Agents as identities, not just code

Boris: There was a study that was conducted — I believe it’s two years ago. Non-human identities outnumber humans by 25 to 50x in almost any company. It doesn’t really matter how big you are or how small you are. We all have processes that are executing at all times. And all of those, again, are non-human identities. AI is a non-human user, right? We need a way to make sure that we manage them, both from a code perspective and creating and wanting to do what they’re supposed to do, but also being able to scope down and bring down the least privileged concepts to those now non-deterministic pipelines and processes that we are inserting them into.

Boris: What identity-centric kind of process around this ultimately means is that AI now can try to do something outside of what its kind of assigned lane is, but we can catch and prevent it because there are gates between it and whatever the malicious actor or the malicious action is. So whether we are trying to scope down what an agent can do or whether we are trying to scope down what a user can do, the exact same governance should be able to apply to both. Both AWS and Teleport are very well aligned around this approach and are kind of working towards — what does it mean to have an identity-first solution to the AI and MCP problem?

Identity-first solution for AI & MCP

Boris: In this, Teleport tries to bring kind of, as I said, scope both humans and non-humans and treat them identically. Obviously, us as the operators of all of these systems, we need the juxtaposition of human and non-human, but to Teleport, whether it’s Boris or is Boris AI that is in the system, they’re no different, right? We become the identity broker and access proxy that sits between your AI agents and your LLMs and the rest of your infrastructure. When an agent wants to use MCP to talk to a database or an API, it will go through Teleport, get a stamp of approval, or get a denial. And you will have a record of, who is this agent? Is it certified and trusted? What is it allowed to do? And then we can check against its kind of policy and governance to — just like we’re checking a regular user’s RBAC and either pass it through or deny entry.

Boris: If you want your AI to only read certain data, we can enforce that. If you want it to have out-of-policy requests, we have a way to request out-of-policy privilege escalation. We can do that now. All of this is based around SS X.509 certificates, right? This is a very well-understood technology. Everybody in the enterprise and even non-enterprise is using certificates in some manner. We’re just leveraging it at scale by providing short-lived credentials that are based around a certificate that can be time gated. So now, when an agent is fired up and we know that it’s going to be operational for only three minutes, its identity will only be active for those three minutes.

Boris: Even if somebody compromises that identity on minute 3:01, that credential is no longer valid within the system, which means that the blast radius has been shrunk down to nothing and doesn’t exist in this particular case. But even if it was to somehow be compromised prior to that, again, it is time gated. It is scoped down to what can I do, not do, meaning that all credentials within the system become ephemeral. There is no longstanding anything. And because it’s flowing through the same kind of pipeline, if you will, that means that I can audit and track all of these actions that are being taken and are being produced by what we’re doing.

Measurable business value

Boris: Since I started kind of the talk with numbers, I’m going to end the talk with numbers. All of this has real business value, right? It doesn’t just cost money. It also does very much make money, right? You are able to generate dollars by ensuring that no breaches to your AI workflows are happening. You will save engineering hours by making sure that your CISO’s office is not running around trying to do compliance checks, or is trying to do breach analysis, or it’s trying to do security analysis on kind of the slew of things that is flying their way.

Boris: And then again, the big thing is that stopping with the whole credentials management is probably kind of the biggest win you can get. The less amount of tokens we have to give out, the less amount of API keys we have to give out, the less amount of vaults we have to manage and ensure they’re secure, obviously, the better. By being able to reduce the complexity of all of this already complex system and making sure that we can bring security to it, you are inevitably saving time, saving money, and enabling the making of money, right? All of the things that we want to do.

Demo: Traditional approach vs. Teleport secured

Boris: So I will dive into just a quick demo. We have about 15 minutes. I want to make sure that we have some Q&A time for all of this, but I will dive into a quick demo of what it means, kind of how users utilize AI and MCP and how that same process looks through Teleport’s lens using kind of the exact same system, if you will. So let me come in here real quick. Oh, sorry, it is being — there we are. So first and foremost, I’m going to show you kind of Teleport, but it turns out that my screen share just stopped. All right, technical difficulties. Obviously, live demos are the best way to do demos, right?

Boris: All right. Let’s talk about Teleport. So what you’re looking at here is Teleport — is a system. I, as Boris, have access to some number of resources. It’s in this particular cluster. Let’s make it a little bit more visible. I have access to everything from Kubernetes clusters to databases to very specific web apps, right? Teleport is very versatile, and we support just about any type of endpoint resource that you want to manage. But let’s focus specifically around MCP. I have a Postgres database available to me. I have a few different MCPs available to me. All of these are off-the-shelf — is off-the-shelf code. This is nothing specific to Teleport, right? I went to GitHub just like any other developer would that is currently 100% leveraging MCPs on their desktop through Cursor or through Claude Desktop or through ChatGPT or through whatever you have it.

Boris: And now, I want to use it. I want to be able to do something useful with it. The other thing that I’m going to do is, in this case, utilize Claude, right? The process here, whether I’m using an — whether I’m using a chat application or an agent is doing all of the actions that I am doing here — the process is the same, right? Whether I am instructing the AI to do something on my behalf or an agent is autonomously doing it, they will interface with this the same way. So here, I’m going to kind of illustrate two separate database access, one through Teleport and one just directly to a database through some things that I plugged in my credentials into. We’ll see what the —

Boris: Let’s see if it works. One of the fun parts of working with LLMs is — and it’s going to be a great illustrator of my point that all of this is — it is non-deterministic. Okay.

Boris: What I’m trying to do here is what I didn’t show you is I have, again, connected through MCP and trying to ask Claude to act as an agent, right? To connect the database that I showed you earlier that is connected to Teleport. And I have one other outside of Teleport database. And okay, now, we can actually see it. Here, the LLM is generating queries and firing them off against the databases through Teleport. But also, because I have a non-Teleport database, it is doing the exact same thing and firing it off to this other system that I just plugged my username and password into. Now, the number of queries it’s going to generate, the number of these things will, as seen, will always vary. But the important piece here about what we’re talking about is the access, right? In one system, the output of all of this is irrelevant almost. But first, I have access to my top secret database through Teleport. In the other one, I have direct Postgres access to execute queries to some Postgres database that is hosted somewhere in AWS for me. Excuse me.

Boris: All right. So how do I audit what just happened here, right? Maybe right now, you will go and fire up something like pgAdmin. Maybe your administrator will go in here and will go, “Well, let me see what queries were executed. Oh, my logging is not turned on. Oh, that’s too bad.” I cannot, in any particular way, shape, or form, audit the actions that Boris or the LLM took on behalf of Boris. But worse, I have no context around what was done and why. Let’s flip back. And again, this is the database that, again, I just directly connected Claude to with no intermediary kind of authentication and connection.

Boris: Let’s look at this from the other side. Let’s look at it from the Teleport side. Let’s see. All right. On the other end of the spectrum is, again, all of the information was passed through Teleport. And I’m not showing you the full logs here, but you can actually now see, “Hey, Boris connected to our database, topsecret, at this particular address, with this particular user and operated within the bounds of the system that the particular user is given.” You will see that I now can capture the specific queries that my LLM was generating, right? And because everything is passing through Teleport, I can immediately deny any, say, drops of tables, as an example.

Boris: All right. I have a fully auditable, actionable log, but how do I make sure that my user has permissions? And how do I make sure that Boris has scoped access? And how do I ensure that his MCP desktop has scoped access? This is where Teleport roles comes in kind of in focus. This is where you define as the operator. I’m showing you kind of the more text way here, but at the end of the day, what you want is the ability to define what is Boris or Boris AI able to do, where, and how? Here I can vary, both programmatically and in kind of a simple layman’s terms define, “Hey, Boris has only read-only permissions to anything MCP related.”

Boris: The Boris AI agent also has read-only permissions to anything that it accesses. This means that, again, scope brought down from huge blast radius to, “Nope. Boris can never, ever have write permissions to the production database.” So Replit cannot drop my entire production database just because it feels like it, and it wants to ignore all instructions, right? I’m kind of flying through this because we have five minutes, and I really want to come back to the poll and make sure that everybody has a chance to ask questions. I think one of the questions was whether this will be shared. Yeah, the recording of all this will be shared. There’s a bunch of docs that explain how to do a lot of what I just kind of flew through on your own at home. You can test it out. So I will stop sharing now and hope that we have a little bit of time for Q&A. We have about five minutes. Don’t be shy, guys.

Q&A

Dylan: Boris, I’ll read some questions from the chat here. There’s a question, “Is there a way to enforce MCP and agents only use Teleport minted keys to access APIs?” Oh, it’s on the screen. Awesome.

Boris: Ah, there we go. Yes. So what I just showed you, there is a step that I skipped where you actually configure your MCP manifest that tells your client, “This is the type of MCP actions you can or you cannot do.” That is where you can ultimately say that. And because, again, step that I skipped in the command line. But what happens is before the session is initiated, there is a certificate exchange between your MCP client and Teleport that says, “Yep. This MCP is tied to Boris; Boris is allowed to access the MCP in question; this is the identity that is attached to it,” which — what we didn’t talk about — is you now have a way to present an MCP catalog of approved MCPs that your developers can freely consume. So hopefully, that answers that question in some detail. And I’m happy to dive deeper with anybody that wants to. My email, obviously, and Dylan’s will be shared.

Dylan: No, that’s a great point to call out. There’s going to be a lot of questions, and we have three minutes. So if any question doesn’t get answered, just feel free to reach out to the Teleport team or myself.

Boris: Yeah. So as far as prompt injection and jailbreaking, so this is where we get into the scoping that both Dylan talked about and the actual implementation of scoping through roles and through tool filtering. Even if I told Claude just now, “Hey, Claude, go and drop the database,” he would have been able to do it on the non-Teleport-protected database because, again, I just plugged in whatever credentials I was given. And if that had access to it, you would have done it. On the Teleport side, my role, boris, is not allowed any write access to any resource unless I specifically go through the system and request such access through just-in-time workflows. So even if the prompt was inserted that said, “Go drop databases, go generate a bunch of drop queries,” one, I will record that I try to do drop queries. But two, the system will reject them and not allow you to actually do it. So the prompt injection piece, even though it can still happen, the ability for it to do something malicious is nearly eliminated.

Dylan: Or is it fair to say that it’s because the identity is being passed from the user, such as yourself, rather than you prompting and saying, “You are a database admin, and you have access to everything,” and then we give all the access to the agent, right? It’s that passing of the identity and verification.

Boris: Yeah, for sure. No, that is a very good way to kind of think about it. Let’s look at this. How should I respond to — I am not sure what this is asking, unfortunately. I’m sorry. If you recontextualize the question in the Q&A box, we have to come back to it. Yeah. So all of our audit logs are — we have a bunch of integrations. You can also ship them off to your already existing SIEM tools, which will then obviously integrate with whatever evidence tooling you want to. But we have also built a new product that we didn’t have a chance to kind of highlight here, but Identity Security, which gives you a whole bunch of evidence collection tooling in order to be able to build out, “Hey, this is my compliance. This is how I’m — this is why I can confidently say that we’re compliant with GRC or PCI or insert your favorite compliance acronym here.”

Boris: And I believe we are at time. So I think I would, at this point, like to thank Dylan for taking the stage with me. And I loved all the questions. I really want to say thank you to our audience. Would love to connect with anybody that wants to talk about this more. My email is [email protected]. Please don’t sign me up for any mailing lists. [laughter] But yeah, I would love to see everybody and chat with everybody around this topic.

Dylan: Yeah. I’d love to connect with folks in the chat as well. Dylan Souvage on LinkedIn is the easiest way to reach out to me. I’m sure the Teleport team would love to field some of those awesome questions. I still see a lot of them that I’d love to get into. But I think the best way is just following up with the team. Thanks to the Teleport team for having me. Thanks for being such a great audience.

Boris: Yeah. Thank you, everybody.