The 2-Minute Investigation: How Teleport Identity Security Sees What Your SIEM Can’t

The 2-Minute Investigation: How Teleport Identity Security Sees What Your SIEM Can’t - overview

Your SIEM collects millions of events. Your CNAPP monitors cloud configurations. But can either tell you how a developer’s Okta group membership led to unexpected production access through three different systems? Can they instantly trace an API key’s journey from GitHub to your crown jewel databases? Now, with Teleport Identity Security, we’re correlating signals from identity providers (Okta), code systems (GitHub), and cloud trails (AWS) to deliver something neither SIEMs nor CNAPPs can provide: real-time behavioral intelligence about how identities actually move through your systems. It’s not about replacing these tools. It’s about answering the critical questions they can’t. Join Rob Picard, Security Engineer and Ben Arent, Director of Product at Teleport, as they demonstrate how identity behavioral intelligence changes everything:

• See a real 2-hour investigation condensed to 2 minutes using actual incident data
• Follow identity chains across systems that traditional tools see as isolated events or static risks
• Discover hidden access paths like inherited permissions and shadow SSH keys as they’re being used, not just configured
• Get AI-powered explanations of complex session behavior without manual log analysis
• Act on first-party detections that only Teleport’s infrastructure position can provide

Perfect for security engineers, cloud security teams, incident responders, and anyone tired of context-switching between disconnected tools. Come see why infrastructure-aware investigation is the superpower your security team has been missing.

Key topics on The 2-Minute Investigation: How Teleport Identity Security Sees What Your SIEM Can’t

• Organizations face a growing crisis with identity-based attacks, as attackers increasingly compromise valid credentials rather than breaking into systems. With 71% more stolen credentials and incidents taking an average of 11 hours to investigate, teams need better visibility and faster response times.
• Teleport Identity Security unifies audit logs from IdPs (Okta, Entra), cloud providers (AWS, Azure), and code repositories (GitHub, GitLab) into a single timeline. This eliminates the manual log correlation that typically consumes hours during incident response.
• The live demo showcased investigating a suspicious AWS token in minutes rather than hours, tracing activity across systems and identifying malicious behavior like Kali Linux user agents. The platform enables immediate remediation through targeted user locks.
• Beyond incident response, the solution maps complex access pathways through identity chains, revealing shadow access like orphaned SSH keys and over-privileged service accounts. Organizations consistently discover unexpected access patterns, such as engineers with maintainer access across all repositories.
• Even initial deployment provides immediate value through visibility into standing privileges and access sprawl, enabling teams to start reducing their attack surface before full implementation.

Expanding your knowledge on The 2-Minute Investigation: How Teleport Identity Security Sees What Your SIEM Can’t

• Teleport Identity Security
• Blog - Trace Every Identity Action with Teleport Identity Security
• Docs - Teleport Identity Security
• Request a 30-Minute Identity Security Audit
• Inside Identity Security – A Red Team Cybersecurity Documentary by Teleport
• Try Teleport Identity Security with a 14-Day Enterprise Trial

Transcript - The 2-Minute Investigation: How Teleport Identity Security Sees What Your SIEM Can’t

Introduction

Ben: Welcome to today’s webinar. I have Rob joining me. Rob, there you are. Really excited for today’s webinar on Teleport Identity Security. Hold up. Actually, you know what, I’m sharing the wrong one. Let me just come back and reshare. Always a slight snafu, but we can kick this off. As we get started, just let us know where you are in the chat, and we will be back to our scheduled programming in one minute. Okay. There we are. Hi, Kat from sunny California, Lexi from LA. Great to have some Teleporters here. Okay, now we’re ready to go. So today’s webinar is The 2-Minute Investigation: How Teleport Identity Security Sees What Your SIEM Can’t. Really excited. We have a huge audience today. We’ll give it a couple of minutes so people come in. I think we’re expecting a large cohort of people. But as we get started, I’ll just go through the agenda and what we’re going to cover today. We’re going to cover the basics of the Teleport Identity Infrastructure Platform. I know that there’s some people on this call who are existing customers. Some people are net new. So we’ll go over what our platform contains, why Teleport Identity Security, what problems we’re solving today. Introducing Teleport Identity Security — this product has been around for a couple of years, but we’ve recently added a new feature, which we call Identity Activity Center. This is one of the core capabilities that we’ll be showing, but we will also be covering a few of the other features and capabilities which have been in the product for a while and sort of showing the maturity of it.

Ben: I’m joined with Rob today, and Rob will be my sidekick, asking other kind of questions and keeping it jolly. And we will do part of the live investigation and leverage Rob’s expertise. Kind of going on to the core of the platform, we’ll show how we can discover hidden access paths and shadow access in your infrastructure, a little teaser on what’s coming next, what we’re working on, and how you can try Teleport Identity Security. It looks like we have some people from Tokyo, people from Texas. So thanks, everybody, for joining us today. So my name is Ben Arent. I’m Director of Product here at Teleport. I’ve been at Teleport six years, and I’ve really seen the product and platform evolve over time. I’ve been working primarily on Identity Security for this year. And I’m really excited to also have Rob Picard, who joined us. Rob, do you want to give a little intro to everybody?

Rob: Yeah. I’m Rob. I am a software engineer at Teleport. I work on security things, generally speaking. I, a long time ago, started the Detection & Response team and AppSec team and whatnot at Robinhood. I led the security team at Vanta. I did consulting for a long time with a bunch of different startups on a lot of aspects of their security programs. So yeah, excited to be here at Teleport now as of May.

Teleport Identity Infrastructure Platform - overview

Ben: Yeah, it’s been great to have Rob on board. And Rob was lucky enough to join at the right time, when we were doing our red team exercise for Teleport Identity Security. So for people who are new, I’ll just give a little overview of the Teleport Identity Infrastructure Platform. An overview. This is sort of an architecture diagram. It’s maybe a little overwhelming to start, but I’m going to start here in the bottom left-hand side. The foundation of our core product — people know Teleport very well for this — is our Zero Trust Access. This provides least privileged, ephemeral access with both audit and session recording. Often, it’s used to eliminate VPNs and bastions in organizations. And when I started six years ago, this was just SSH and Kubernetes. Now we support applications, Windows desktops, and a whole range of databases. Basically, any infrastructure resource that you’d want to access, you can access with Teleport Zero Trust Access. And as we had the flow for sort of development teams and users accessing resources, we found that people loved the user experience and the connectivity and the zero trust aspect that they also wanted to add machines into the same flow. So you can take the same short-lived approach of Zero Trust Access for machines and workload identity. This would be great for hardening your CI/CD servers, and we most recently added workload identity. And you can implement SPIFFE and TLS to authenticate workloads and sort of broaden the whole sphere of Teleport beyond just Zero Trust Access.

Ben: Going up a level, we layer on Identity Governance. This really helps organizations move to zero standing privilege and deploy Defense in Depth. Most commonly, people use this for access requests. So people have zero standing privilege, and they can easily provide access requests to their resources. But in Defense in Depth, you might want to deploy Device Trust. And then you can also manage multiple clouds. And then lastly, Teleport Identity Security. This is what we’ll be covering today. This initially started with just understanding the graph of access, but now you can unify, detect and investigate identity-based attacks. And lastly, down here, we cover a whole range, so IdPs, humans, infrastructure assets, all consolidated in one centralized place.

Teleport Identity Security – why?

Ben: So why Teleport Identity Security? I would also say, as we go through this, we do have a Q&A box, and then also chat. If there’s any sort of questions or I miss something, feel free. We will try to hit those as we go through. So why Teleport Identity Security? Last year, Datadog found that most cloud incidents were caused by attackers compromising identities with humans and applications. And what is different is, instead of people sort of hacking into systems, they’re just finding a valid credential and using that to log into a system. Once they get in, it doesn’t take them long to get persistence into another system, 48 minutes. And once they’re in those systems, since they use a valid credential, it can take 10 days for discovery. And a range of attackers have just sort of discovered that there’s lots of valid credentials out there, and so we’re seeing sort of a 71% increase in stolen credentials. I have links to the reports here, Datadog’s State of Cloud Security, but both CrowdStrike and Google have seen the same information.

Ben: Earlier this year, we also partnered with the Enterprise Strategy Group. We have created an identity security report, Balancing Stability, Agility, and Security, and sort of seeing the state in the market. We’ll be launching this report in August, but one key stat that we found from interviewing — or from ESG’s interviews was, it takes like 11 hours to investigate and remediate a critical identity-related alert on average. And 5% takes more than 50 hours. So when these things do happen, it takes a lot of time and a lot of human-hours to just remediate. And this is just sort of one identity-related alert. And I’ve talked to organizations that might have hundreds a week, and obviously, this becomes a huge problem to sort of triage and investigate all of these identity-related issues.

Ben: And this kind of brings through some of the hidden identity risks in your infrastructure. One easy example is orphaned SSH keys. These can both be from ex-employees, but it can also be older build systems which have privileged access. Service accounts can also create persistence backdoors. It’s a great example of a valid credential that can give a lot of shadow access. And with a move to the cloud and just more systems, there’s also blind spots in the fragmented logs. So Okta, AWS, and GitHub. If you’re on a sort of modern cloud stack, it’s really hard to sort of tie together all of these bits of information to know what all of your developers and sort of SREs are up to. And then this results to the sort of slow and also manual incident response. Often, it’s after the fact. So it takes a lot of time during the incident response to stitch together all of the logs to figure out what was happening, that we also saw with the ESG report. So I have a quick poll here, “How long does it take your team to investigate a potential identity compromise?” And I’ve put this up. It should be in the polls tab, which should be next to the chat. And I think we have a couple of votes coming in. Rob, how long do you think it takes us to investigate a potential identity compromise?

Rob: Good question. I feel like it probably — depending on the exact scenario, I mean, it could take hours, right, to go from, “Hey, there might be something weird about this,” to, “Okay, we’re really confident that there’s either nothing or —” I mean, obviously, if there’s something, then it extends into infinity. Now, then, as it turns out, our newest product happens to help a lot with this and reduce that timeline quite a bit.

Ben: Yeah. All right. I put you on the spot there. So I think we have a few folks coming in. I know I saw — Stephen says months. Yeah, I feel you, Stephen. And I think the — reduce it, for months. I’m going to close the poll. And I don’t know if I can share — actually, I know what I can do. I think I need to stop screen sharing. I can share the poll. So you should be able to see it now. One person, less than 30 minutes. And I’d be interested to figure out who you are with your fairly speedy response. But we have 2 to 8 hours and then, a couple of people, more than a week. So it kind of matches up with what we see. Now I come back. Thanks, everyone taking part in my poll.

Story of a compromised identity

Ben: And so I have a story of a compromised identity. So as we built this product, one thing that we sort of tried to solve was a problem that we also faced internally. And this is an example of a non-human identity. I’ve often found that people are quite aware of human identities, a range of non-human identities, which can be SSH keys, tokens, service credentials, which might have privileged access. In this case, we had a reporter reach out to us about a GitHub-leaked PAT, which is a personal access token, that was found on the internet. First thing that our team did was to create the incident. We tried to figure out the scope of the token. The token had the ability to have some form of lateral movement. Then our team had to create custom scripts to figure out and understand how wide that scope was. That was mainly through correlating GitHub and AWS logs, also GitHub action workers, to make sure that it wasn’t leveraged or used. And then lastly, we sort of had this remediation action.

Ben: And in this bottom area, I sort of have from the researcher, investigation time, and then a little bit of hardening. This is sort of a 14-hour — I think four people within our team were involved in resolving this one. And what this looks like is sort of: review permissions/tokens, query GitHub API, match tokens to access scope, expand scope for CloudTrail, also query the SIEM, look for events. As you may have noticed, our title was Showing What Your SIEM Can’t. I think this sort of highlights that we didn’t really start with the SIEM. We started with sort of the token and then went from there as sort of our foundational things. And this will also be part of my demo. Reviewing the blast radius. In this case, the PAT had access to an AWS instance, which had an instance role, which could potentially write to ECR. So, “Was there anything written?” to sort of fully close this investigation out. Obviously, at the end, we rotated and locked down access and scope of this token and performed a root cause analysis.

Detecting identity chain threats

Ben: And one thing that I’ll be talking about next is detecting identity chain threats. This is sort of something that’s come up as I’ve been talking to a lot of our customers and prospects — that actually lots of teams think about their groups of access through their IdP. So this could be Entra or Okta. You add all of your engineers into the “Eng Group” [engineer group]. The “Eng Group” has access to a couple of accounts. Your SREs have access to everything. Once you’ve added someone to a group, you sort of let them in the group. You don’t do much else. But as you can see here, there’s a range of different groups and people in the organization. Here I have Teleport in the middle to also have another layer of RBAC mapping. And then you have the downstream AWS accounts and AWS roles. And then it’s the same for non-human identities and robots. They come in, and they might just go directly to Teleport, or they might just go directly to AWS account. I think, currently, the sprawl of machine identities are also booming, and they’re also much harder to track than a small amount of individuals. And so, with Teleport 18, we can now detect identity chain threats that are hard to see. We do this by unifying audit logs into one centralized place, so the activity from the IdP to cloud and infra into one timeline. We can investigate. We can figure out things that logs might miss. And then we can also detect, and we have some more proactive alerts and investigations as well.

Demo: Teleport Identity Security

Ben: So now I’m going to come into my demo portion. And a question I talked to somebody the other day was, “A developer has quit, but they have 20 AWS keys. What are they doing? Can Teleport Identity Security help with these non-human identities?” And this might be a pretty familiar thing for most people, especially within AWS. Here, I’m logged in as my federated user. This is my official one. I have administrative access. But users can also create sub-users with sub-tokens, and this can become difficult to manage. So I have this debug app, which looks like it was active. Used today. Created seven days ago. And you can see first that, okay, whoever created this made a big mistake by giving this administrative access. Now we’re trying to figure out from the security credential. It was last used an hour ago, but I’m not exactly sure what this is. And let’s say in this scenario that this person quits. What has he been up to? We may be able to go to CloudTrail or somewhere else. We can’t figure out what’s happening here. So let’s take this access key and come into our Investigate view.

Ben: So within Teleport, we now have the addition of the Identity Security tab. I’m just going to log into the Investigate view. I can filter down by token, paste in my key, expand this to “Last three hours”. Okay. And so you can see here that there’s a range of activity for this AWS token, including this PutObject. So it looks like someone uploaded a hello-world, which might be okay. It might be something else. But these ones are also looking a little bit suspicious. DescribeKey. He looks like he’s been enumerating KMS keys. And here there’s a user agent, kali Linux. I would definitely put this in the realm of something suspicious. So from here, we kind of know that this token is potentially doing something kind of mischievous. Actually, I’ll try and zoom in a bit, the best I can. And so let’s take our token to search. And we can see here that this also correlates with my Teleport audit log. We can also tie this into our Okta audit log as well. And so we can see now that, okay, this token is more likely related to Ben Arent, who’s an active user. And this would be something that we’d want to investigate. Now, if we are in a real incident response, one thing that you might want to do would be to lock my user. Within the Teleport platform itself, we have the ability to create a targeted lock. I won’t lock it for this demo because I’ll lock myself out, but this is a nice way to also remediate.

Ben: Let me come back to my slides. So for the demo recap, started an investigation into a sub-user with the user and key, located the access token, quickly found the activity in Teleport Identity Security to investigate, used the data to pivot and learn more about that key. That’s how I found out the matching IP address and the user agent was suspicious. One thing I didn’t mention here is — you can also — as we think about remediation, we think about locking. But also, what’s the solution for AWS keys? This is where Machine & Workload ID can be a perfect replacement for AWS keys, and moving to Machine ID to move to short-lived tokens. And then lastly, we can review other alerts, but I’ll sort of dive into this when I talk to Rob. So now I have Rob joining me. A very serious Rob here, a slightly less serious one in real life. And as part of the development of Identity Security, we partnered with Persistent Security to perform a red team exercise. And, Rob, do you want to give a little overview about this exercise and what happened?

An investigation with Rob Picard

Rob: Yeah. So it was really fun. It’s cool. This is my second week on the job too. So we all met up in Lisbon, Portugal, and we had three days, basically, of working together with the Persistent Security team. And we kind of had our own little areas in this room, and they were doing a red team exercise on an environment that we set up, with Teleport Identity Security monitoring the environment. And what we’re able to do is we’re able to sort of see, like, “Okay, let’s test. Will the products actually detect the activities that they’re doing? Will we be able to investigate and sort of do interesting things with the product based on the activity?” Right? So it gave us a live-fire exercise, essentially. It was cool. Essentially, one person from the Teleport team was the kind of go-between who helped sort of give them the inside, like, “Okay, here’s your initial access,” and whatnot, but really, most of us had no idea what they were going to be doing. And so it kind of started off with us just staring at Alert dashboard, hoping to see something, but it ended up being really interesting and useful demo of the product.

Ben: And this was over two days. Do you want to talk about the two different days? What was sort of our team’s exercise on the first day and the second day?

Rob: Yeah. So on the first day, essentially, we had a Kubernetes cluster, and they focused on essentially an escalation from pod to node takeover and using that as their entry point, right? And then, on the second day, we focused much more on the identity use cases, where ultimately — and again, we didn’t really know this going into it on the sort of blue team side of this exercise, but they were given a machine account, essentially — a service account that had been set up to test, I think, Temporal, right? And they were sort of given an access key from — access to Okta with a service account, I think, was the very initial thing. And then they used that to kind of pivot into — I mean, they were trying to get into GitHub and AWS. And so we were able to start to detect some of that and see what they were doing and investigate it.

Ben: And you’ve been around the industry a little while. And we’ve been to RSA, been to Black Hat. So many vendors have a tool for everything. How do you think — and I know you work at Teleport, so this could be a little biased. But how does this compare to the sea of tooling that we currently have? How can you see it augmenting and helping organizations?

Rob: Yeah. Yeah. And I mean, obviously, yeah, there’s a million tools for everything. How do you kind of figure out what’s actually useful to add to your tool belt and complements what you already have? I think what’s cool about Teleport is — we do have a unique position — if you are using Teleport to manage access, then you’re sticking us in a spot that’s very advantageous for us, right? There’s sort of like an analogy, right, in security, or a strategy, where the idea is, “Put your stuff in the middle of a big valley surrounded by mountains with one way in or out, and then watch that one way in or out very closely.” And so when you’re using Teleport, you’re making us the sort of gatekeeper for that one way in and out, right? And that gives us the advantage of having information about what all of your identities are — who is in your company? What are the machines and workloads that are in your environment? What can they do, right? So what permissions do they have? What access do they have? And then what are they doing is sort of that third question, right? And so that’s the new developments that we’re talking about today. We’ve always had audit logs for what they do in Teleport, but now you can go in and say, “All right. Also, here’s the CloudTrail piece of the story. Here’s the Okta piece of the story.” So we can start to build this full picture of what everyone’s doing, and then you can very quickly pivot into like, “Well, what’s the blast radius for that? Let me go,” like you demoed, “and lock that identity.” It kind of puts us in this really nice little spot where we can complement whatever tools you already have, specifically on this identity layer, right? We’re not looking at all the process executions that are happening in your entire AWS or GCP environment. That’s a different tool, maybe, right? But when you think there might be an identity compromise, we can really hone in on that use case, and I think that’s pretty useful.

Ben: Awesome. Before I dive in, is there anything else you want to cover before I keep going on with the demo?

Rob: No. I think the thing — and I think you’ll kind of cover this a little bit, but maybe just even set the stage for it. I think our real strength here is this investigation bit, right? It’s very nice to be able to go from — and we found this — I mean, hey, go watch the documentary, right? But we found this in that exercise, like, “Oh, hey, this alert fired on this identity.” It almost doesn’t matter what the alert was or why, but we had an impetus to investigate an identity, right, this test account. It was very easy to go from there to like, “Let me slice and dice through all of the CloudTrail, the Okta, the GitHub. What is actually happening here?” And then we’re able to see, “Oh, okay, they sort of stop at some point.” And that point was — they created a new user — or sorry. Actually, they created a new trust relationship in AWS, where an external AWS user was able to assume a role and go from there. So we’re able to then very quickly pivot onto that role and see what’s going on there and what that external user was doing, right? So it ended up being, I don’t know, very quick. Again, that’s why they called it the two-minute investigation. It’s very easy to sort of just pivot around within those. And I think that’s the core strength that, in my opinion, we’re sort of here to talk about today, is like, “Hey, we can give you a really sharp view on this layer if you’re using Teleport for some of this stuff.”

Discover hidden access paths and shadow access

Ben: Yeah. Awesome. I think that was a good thing to cover. Yeah, like Kat said, the documentary is there. There’s also this short link here that you can watch it. It’s definitely a niche piece of content, but hopefully all 30 people here on this webinar will be into it. And moving on to discovering hidden access pathways and shadow access, this is how Teleport Identity Security can also help. One of the simplest questions that we also get, especially in large organizations, is just: what is people’s standing privilege? If I have 1,000 employees, or even like 30 within the SRE org, do I really know how much access they have? And Identity Security is very well-positioned for this. We actually have a high standing privilege report. This will also pull in AWS and your IdPs, like Okta or Entra, users. So this is a very privileged AWS user, the one that I showed earlier. But I’ll come into my user. And as I went through my other example, people often have groups. People might be in multiple groups within the IdP. Then you might have multiple roles within Teleport or your access tool. And then you have multiple resources. Since we use kind of a graph, we can figure out how much access people have. In this case, we have 52 standing privileges. We have all of the roles. And so if I come to this one, this is my AWS console access role. But it’s hard to really figure this out. And also some traits that you might have within your IdP, which people often use as a way of fine-tuning their access.

Ben: So if I come in now and view this — make it a little bit bigger — we have my user and — well, you can see here, I have access both to roles and also to Okta groups, which I’m an owner of. You’ll also see here I have access to access-mcp. We recently added MCP in Teleport 18.1. I won’t be covering this here, but I think this sort of highlights the things that people are accessing — are always kind of growing in all different interesting ways. Teleport is a great way to consolidate all of them. And if I view all of the graph, this could be a little overwhelming, but we can trace one down. Let me look in for one particular resource. Okay, let’s pick my topsecret database. This is my favorite one. So I can pick my — we can also go from the inverse. So instead of just looking at the user, we can inspect the resource. And so, here, I’ve kind of made a snafu that I’ve added *: *[wild wildcard] that this is a way to access my topsecret database, when it should be env: prod. And if I fit to view, we can see all the access pathways. So here, these two DevOps engineers have production access, but these requester roles also have access, too. I’ll also highlight that this is a helpful feature of the graph. If you’re using Identity Governance and access request flow, we can also tell you, “Hey, this user could potentially access that resource.”

Ben: And when we deploy this, people often start with a whole web, and then they start making a plan to reduce it. Once you sort of have things sort of locked down in ways which you like, you can set up crown jewel matches. And so this will alert any time an access path pattern has changed. One example would be, if the interns suddenly have access to your top secret database, you’ll get a graph, and then this will also get sent into the Teleport audit log. And so we can, both, view this path has changed, and we can view this in our policy. Yeah. And we covered crown jewels and risky behaviors. I don’t know, Rob, if you have anything on standing privilege or crown jewels before we go to the next one.

Rob: No, I don’t have anything specific to that. I think it kind of mirrors how people generally think about — when you’re doing a risk assessment, or something like that, of infrastructure, a lot of times people start with, “All right. Well, what are our crown jewels?” and then, “What are all the paths to get there?” So I think this is a good tool to help with that, basically.

Ben: Yeah. Yeah. And here’s an Okta user. Same kind of flow. So going higher — and I think this is often when we talk about the chain — the chain and the graph is basically the relationship with the chain, something like IdP to Teleport to AWS. And we can even go down to database tables as well. I want to say, yeah, Alice has access to even specific tables in our top secret database, so this very sensitive agent table, which is also something that you could detect as a crown jewel, to say, “Hey, any time access path changed to our agent table, alert us.”

Ben: And lastly, scanning SSH keys and shadow access patterns. If I come in, we have a complete query editor. We have a range of examples, which can be very helpful to just understanding access patterns, both allowed and denied. I’m going to pick my SSH one. This is just a relatively simple one, but you can see here I have this authorized break-glass key, which both has Ubuntu and root. Not in this environment, but my other environments, it sometimes shows packet keys and other build tools which don’t clean up the key. And so, even just deploying this, you can get a lot of interesting insights into potential backdoor and shadow access that a team might’ve employed.

Ben: And so our supported integrations for July, which we have a couple more days left. We have Okta and Entra for IdPs within the Access Graph. The Teleport platform supports just SAML and OIDC, but if you want to get the things within the graph and the full visibility and the audit logs, these are ones that are provided. For AWS, Azure, and on-premise within our clouds. We also support code. And so you can map repositories to users for both GitHub and GitLab. And then lastly, just infrastructure, Teleport, resources, SSH key scanning are all within one centralized place. One thing I haven’t mentioned yet I probably should’ve mentioned at the beginning, Teleport is offered both as an enterprise SaaS offering but also on-premise. We also have FedRAMP editions. One thing that’s really liked by a lot of our customers is that you can have all of these sort of powers of tools that you might see within Synapse, but you can run it yourself within sort of highly regulated environments too.

What’s coming next?

Ben: And what’s coming next. So coming quite soon will be AI Session Summaries. This will allow people to have some session classifications, summary and security assessment for SSH, Kubernetes, and database sessions. For people who have only just heard about Teleport, this is some of our session recordings. So we already record session activity. If I come into a host, we can view what’s happening. And people often have like tens, or even hundreds, of thousands of session recordings that they might want to review. Our AI session summary makes it much easier to both classify what kind of work are they doing and then also potentially showing security alerts. And this obviously helps a lot with compliance. Especially in Europe, we have people who have full-time employees just reviewing session recordings, which isn’t the most exciting job. So really helping other organizations with both compliance and saving them reviewing sort of hours of just standard maintenance.

Ben: And so we’ve worked with sort of four main customer areas as we’ve sort of gone to market: crypto companies, neobanks, high-frequency traders, and also AI companies. And we’ve really helped drive transformation to provide sort of end-to-end visibility, highlighting where they had blind spots but now they can see everything, understanding more credential sprawl, tokens and keys which weren’t necessarily within the Teleport ecosystem, then moving that to Machine & Workload ID. And we hope that our learning system will keep improving so it’ll make incident response more proactive. I didn’t actually show Alerts yet, but Alerts is great because it also includes GitHub, Okta, AWS. We have the same graph. We have the same audit logs. And so we can have sort of a complete visibility into our users across all resources. And yeah, crown jewels, unmonitored, and now it can be actively alerting.

Ben: Before I get to Q&A, we deployed this earlier this year with one of our enterprise customers. This is just for our GitLab integration that they found after they deployed it. Two engineers basically had maintainer access across all of their repos, even ones that they knew that they shouldn’t have access to. And this was sort of a quick win. They were trying to reduce their potential risk. And I think, when we deployed this internally, we found our CTO had the most amount of access. And it was like, “Let’s remove the keys from our CTO and start sort of breaking up access.” Because if an attacker is targeting somebody, they know that they’re sort of key individuals who might have access to everything. And first, start with the visibility, and then start reducing their access. If someone has less access, you’re really reducing your exposure. Rob, I don’t know if you have any comments on reducing risk.

Rob: No, I probably should, right? But no, I think that’s right. I think what’s nice about this is these kind of like just quick wins. Even turning this on, seeing it, there’s a whole kind of — a lot of different ways you can operationalize this going forward and how you actually want to use this day-to-day and use the alerts and use all the investigation tools, all that kind of stuff. But also, sometimes, just turning it on and taking a look, I mean, it really can show you just like, “Oh, what are the top three things?” Right? And that can be an 80/20 rule type of thing, right? So I think that it is really, really well suited to that kind of thing, where you just sort of can quickly get some quick wins and insights out of it.

Ben: Yeah. So now I have two polls. I have one — let me stop sharing — which isn’t this question. I’ll follow up with this question afterwards. But it’s, “What keeps you up at night from a security perspective?” I should’ve asked this one earlier, but I’m sort of interested to hear what people are concerned about, whether it’s identity and access management, incident response, misconfiguration, alert fatigue. Yeah, I see somebody has one vote there. Rob, what keeps you up at night from a security perspective?

Rob: My kids keep me up at night. [laughter] No. Yeah, I think —

Rob: Yeah. Honestly, I think it’s over-permissioning, right? It’s really, really hard — the idea of principle of least privilege is obvious and great in theory, and it’s just so hard to implement. You’re never done with it. It’s always like, the environment’s changing, what people need is changing. It’s increasing/it’s decreasing for this group and that group. New people are joining, leaving, moving all the time. So I think that is genuinely the biggest thing, right — is just reducing the attack surface with that. There’s always stuff like malware and all that, but I think the question of like, “Okay, so there’s malware. Now what?” It really comes down to what can that account do. Can malware steal creds and then run away with your infrastructure, or is it going to have to submit an access request and do all this stuff? And there’s always a mix, right? Even Teleport, we still have a mix of things and people, like you said, like, “Okay. So CTO has a lot of — okay, time to reduce that. Okay, this person, this team. How can we change that?” And you’re just always iterating on it.

Ben: Yeah, it’s always changing. And it looks like insider threats and privileged access, 30%, has most of the votes. I think also lack of visibility. Pull this one out too. So this kind of matches what I’ve sort of seen in the market too, and hopefully we’re building a product to help solve some of these needs. And so now I have my second question, which is, “What would have the biggest impact on your security operations?” So for sort of things that I’ve shown, would reducing investigation time help the most or have the biggest impact, removing shadow access, unifying audit logs? And then these ones are a little longer, so I’ll give people a minute to fill that out. Rob, what do you think would have the biggest impact on our security operations [crosstalk]?

Rob: So glad you asked. Yeah. Obviously, it’s a little bit of a cheat because we have access to some of these things already, right? So improve relative to it. I think the visibility on shadow access, to me, is one that really kind of stands out, because, again, that’s one that you never really just solve. Anytime you think you have, there’s always something else, right? There’s always some vendor that has a different way of accessing your thing that you need, and so you set up a special case. There’s always weird stuff going on. And so I think that one is probably the most, I don’t know, significant. I will say, during the red team thing, the AI session recording summaries — you were showing that. That’s very cool. At least during that exercise, those looked pretty good. So hopefully we can kind of productionize that really well when we ship that because that’s super useful. Having to sit and watch the session and then think about it is very different from like, big red flag, “This session was doing super sketchy things. You should go do that.” And I think LLMs are really well suited to that problem.

Q&A

Ben: Yeah, I think it kind of ties into alert fatigue too. And I was thinking, as we think about alerting, “What alert do you wake somebody up for, and which one do you have some other form of remediation?” And I think there’s different philosophies from the SRE world on like, “Should anyone be paid — at what point do you wake someone up at 3:00 AM in the morning?” There’s likely a case for Identity Security, something that you do want to do that, and I think that would be interesting to explore. And yeah, it looks like, for my second poll, everyone’s going for, “All of the above,” the easy answer. So I’ll close this poll. I’ll stop sharing. And now I think we have time for Q&A. My slide says Recommended Next Steps, but this is also my Q&A slide. So if you want to try Teleport Identity Security, we have a 14-day trial. The Identity Activity Center, which I sort of highlighted in this webinar, will be coming later. You can also just email me, and I can get you sort of early access and do a deeper demo. We also have a Slack channel too. It’s a great place for both our community and our enterprise users to discuss everything Teleport.

Ben: And so now I’ll kind of move into our Q&A section. So let’s see. Jaxson Perry, “Do you support multi-cloud?” Yes, we support both multi-cloud and a whole range of different things. So you can run Teleport Identity Security yourself in different cloud providers. For Identity Activity Center, we do require Athena, but you could plug in data from Azure or Entra. And also, from a monitoring perspective, we support AWS and Azure, and we’ll be working on adding GCP and other clouds so you can really consolidate all those logs into one place. So hopefully that one has been answered. Stephen, “Can you see exfiltration paths outside of a company network to the internet?” This is an interesting question, which — I don’t know. What would you say, Rob?

Rob: Yeah. I think the question’s kind of getting at network layer sort of paths, and I think the answer is kind of no. Really, we’re focused on the identity layer. We’re trying to be very, very good at that problem. We’re not necessarily going to highlight like, “Oh, these three steps through your network will lead to the internet,” when you thought you had egress controls on. Teleport, in general, can be used to reduce the amount of exfiltration paths — excuse me — because of the way that we can help you access them more securely via reverse tunnels, that kind of stuff, but what you’re going to see in this graph is really more of the identity-level stuff, like who has access, what are the unexpected permissions that you see there.

Ben: Yeah. I think, also, going a little deeper, one thing that we run is our Enhanced Session Recording. So for people who are savvy Linux people, you might be aware that there are ways in which you could turn off the recording methods. And so we added Enhanced Session Recording, which is an eBPF module. This can also be helpful for obfuscation and network commands if you’re locking down hosts. We’re also increasing our SELinux support. So we can really go sort of super deep depending on the specifics. We’re happy to sort of nerd out on this topic too. I think, like anything — I’m always worried of blanket statements. I think no tool is impenetrable, from any sort of solution, but I think defense in depth is always the way to go. Stephen also answered, “How about using the community version to get a feel for the product?” Yes, you can use this to get a feel for our Zero Trust Access. Also, there’s a few access requests in it. But for Identity Security, there is no community version. You’d have to use the 14-day trial to get started. If you’re a large organization, we also do offer proof of values, PoVs, kind of proof of concepts, that we can really work with your team to figure out the scope of access where we can really deliver value as well.

Ben: And any other questions coming in? Let’s see. Alexey, “Watching reverse —” oh, I don’t know how I share these ones. “Watching reverse shell connections, things like this, in Teleport.” Yeah. This is sort of — as we’ve been testing AI session summarization, it did a pretty good job of capturing [inaudible] of securities container escape, and there’s a few things — sort of like fine-tuning. And so if you can record what people are doing on the session, I think there’s a few interesting ways in which we can figure out what people are doing. Let me come back to the chat. I’ll look at this. Let me approve this one. Sasha, our CTO, “What’s planned this year for Identity Security?” Great question. So in August, we’ll launch our AI session summaries. This will summarize SSH, Kubernetes, database sessions, and then also classify them, as I already highlighted. And we’re working with a range of design partners as well, adding KMS keys into the graph, very sensitive resources that people want to monitor. We’ll work on refining our alerts, also sending alerts to sort of third-party systems so you don’t have to log into another tool for alert fatigue. And I think that will keep us pretty busy throughout the rest of the year. All right.

Ben: Okay. Let’s see. Another one. Jaxson, “How are you extending the same identity and auditability to agentic AI actors, especially in ephemeral environments where static keys aren’t an option?” That’s great. We actually have our Machine ID team currently at an agentic AI hackathon in London, and so I’ve been talking to them on this very topic. You can use Machine ID to issue a short-lived certificate for access, and then you can also give that to a bot. If you just use the same Machine ID platform, you get all of the auditability, and then you also know what people are doing. I think there’s multiple layers to answer this. There’s the first layer, which is, people are running AI tools on their behalf. So I’m using Claude Code. Then we have customers who want to deploy an AI agent, run it for a week, and then come back with something. It can access a range of different things. If you can put that all within the Teleport platform, you get all of the same audit log and connections to figure out what’s happening. And we’ll just include that into Teleport Identity Security so you can figure out, “Hey, what are bots doing?” If I show you how our bots think — I think I have an earlier demo — you can see that they do create a lot of noise. And so, yeah, this is something that we’re working on. Two last minutes, I can get my demo going. Okay. So we have 10 more minutes. Any other questions? Thanks. More coming in? Rob, do you have any questions?

Rob: I do not. I feel thoroughly answered.

Ben: I mean, since we do have a little bit of time, why don’t I — I think I have it, actually. Let me show you my Claude Code deployment for MCP, since it’s always an interesting example. Okay. So this is my top secret database, which you might’ve seen I used earlier, my example. This is just off the hot press with Teleport 18.1. You can now protect and order MCPs within Teleport. So, “Tell me about the agents.” And what this will do — this connection goes from Claude Code into Teleport. It’s running kind of a query. And since this is going — since this MCP is sort of proxied via Teleport, once this sort of completes its query — it’s actually interesting. Sometimes Claude Code does block this because it actually thinks there are top secret agents, which is not the best use. And so we can see it’s made a range of things. We have the agent_id, a whole range of other information. We have “GHOST”, “SHADOW”.

Ben: Now, if I come back into Teleport — let’s see. Last-minute live demo. Let’s come to the audit log. You can see all of these database queries that have been run. So this query was on my behalf, but we can see that it has viewed all of the agents and all this information. And so you can get great visibility into what the MCPs are doing [inaudible] within your systems. This is our database access, and we also have support for a range of other hosted MCPs, so our GitHub MCP or developer-run things. So an extra kind of bonus there. Oh, my last question. Will we have a presence at Black Hat? Great question. This is my bonus slide. We will be at Black Hat — myself and Rob. We have a page here. We’ll have a booth. You also can just email us. We’ll be happy to meet you in person. Okay. I think that is it. Thank you, Kat, for sharing. And thanks, everybody, for joining us in today’s webinar.

Rob: Well done, Ben.

Ben: All right. I’m going to stop sharing and go. Have a great rest of your day, everybody.

Rob: Bye, everybody.