Techstrong TV Friday, April 17, 2026

Hey everyone, welcome back here to techstrong TV. Look, everybody's talking about this Mythos and Glasswing, and is it a vulnerability apocalypse? Is it a big nothing burger?

I couldn't think of a better person to talk about this with than my friend Jeff Williams. Jeff, I'm going to let you introduce yourself, if you don't mind, but don't be shy and don't be modest. Tell them who you are.

Thanks, Alan. I'm Jeff Williams. I'm the CTO and founder at Contrast Security.

I've spent the last 30 years working on application security problems, helped to start OWASP, and now we sell an application security platform driven by instrumentation and runtime security. Excellent. And Jeff, for those who aren't familiar with Contrast, right, Contrast started life, as I think many AppSec companies did, doing scanning, DaaS, SaaS.

You guys had some of your own twist on different kinds of scanning. But I guess it's more than a year ago already, you started not pivoting, but recognizing that the mission might change here and the mission might grow. And started looking at runtime security, which for a lot of people in AppSec was kind of blasphemy, to be on that side of the horizon.

And a lot of different things other than just pure scanning and finding vulnerabilities. Yeah, it just makes sense when you see organizations struggling for really decades with vulnerability analysis and remediation and building security into their products. At some point, you have to say, "Well, okay, what are we going to do about the vulnerabilities that we know are in production?

Are we going to see if anyone's attacking us? Are we going to stop those attacks? " And then I think what's the most important is how are we going to create a feedback loop from production back into development so that we can prioritize correctly and fix the things that need to be fixed, and not the other 95% of stuff that really can't be exploited.

Exactly. You know what, I want to talk about Mythos and Glasswing, but Jeff, while we're here, let me give you a chance to give us an update on what's happening with Contrast. Yeah.

So we spent the last couple years bringing together the development view of application security and libraries and supply chain and all that with the production view of those same things. And what we found is that it really changes the game, because you can get the prioritization and the context from production to make sense of the vulnerabilities that you have in development. And it's interesting when a new problem comes out, really, organizations should start two workflows.

Like if there's a new vulnerability like Log4Shell or something, when that comes out, there's really two workflows. There's how do you respond, like incident response in production to that, and then how do you fix the underlying problem in development and get that into production as the fixed version. And so we think that the right way to solve both of those problems is with runtime instrumentation to watch what's actually happening in the running applications.

I love it. People maybe want to get a little more information on Contrast. com?

I don't remember. That's it. Yep.

That's what I thought. Anyway, go check it out. Jeff and his team there are always kind of on the leading where what you'll see a lot of AppSec and security vendors doing next year.

You could go get a clue into it right now. Jeff, of course, we're all the security industry, and I know you have a lot of friends in it, as I do. We're all over the place with this Mythos, huh?

Yeah. It's super exciting to me. As a security researcher and a long time pen tester and threat modeler, it's exciting.

AI's doing some things that we thought that really required human expertise to do. There's a few questions around exactly what did it do and how did it do it, and how expensive it was, and is this just a marketing stunt. But I think if you take a step back, there is some real progress happening here.

There is, no doubt about it. " I don't know if this is going to be the end of the internet or the end of... But it's also not something to trivialize or take lightly either.

At the very least, it's going to fundamentally lead to more vulnerability reports. The big question is kind of the tokenomics question, like- Uh ... imagine this made vulnerability discovery free.

Well, then, sure, there's going to be an explosion of vulnerabilities. Imagine it makes it like you can find vulnerabilities, but it's really expensive. Well, does that really change anything?

I don't know. And the estimates that I've seen seem to make it look like it's going to be roughly the cost of a human pen testerTo find- Oh, really? this is going to be 40 or 50 times more expensive than using traditional AppSec tools and techniques.

Mm-hmm. So I don't know if that's going to change that much. And when you think about there's millions of open source libraries out there, are we going to all of a sudden find all of those?

I think it's important to think of it like Bitcoin mining. There's some that you can find right away, then there's harder ones and harder ones and harder ones. But there's always going to be vulnerabilities out there because you're never going to get to the ones that are super, super, super expensive to find.

Agreed. So my suspicion is that this doesn't change very much in that world. It will create more risk for companies that now they're finding more vulnerabilities in their code.

There's more open source vulnerabilities at some scale. So that's going to leave them with an exploit window to deal with. So here's the thing.

It depends on whose wallet this is, right? If you've got nation states involved, well, except for maybe North Korea, they'll do it on a shoestring, right? But for most nation states, the tokenomics of it are not as important as the political ramifications, if you will, or the political- Sure.

They don't need to find all the vulnerabilities. They just need to have an arsenal of exploitable vulnerabilities that they can use as weapons. And quite frankly, I wouldn't doubt if the NSA or the Chinese Communist Party or the Russian, who used to be the KGB, they probably are still sitting on a bunch of zero-days they haven't used.

So- What people don't understand is that the number of vulnerabilities that we've found so far in history, it seems like a big number, and it doubled last year. But it's a tiny fraction of the vulnerabilities that are out there. Most vulnerabilities are latent.

Yeah. We don't know this for sure, but I'm pretty sure there's tons of them out there because you think about what is our system for finding those things today? It's a ragtag team of volunteer researchers doing this in their free time.

And there's this huge security industry built on the shoulders of these geniuses doing this work. But if AI comes in, maybe that calculus changes. Agreed.

I feel the same way. But here's the other thing, and you mentioned it when we were talking off camera. This is really the first domino.

Right. All right, so now the AI, let's put tokenomics to the side. AI finds a lot of vulnerabilities.

Okay. We know that, I don't know, 98%, 99% of them are not exploitable, not reachable, or are big nothings, right? They're- Yeah, there's no critical asset, that it's not connected to the internet.

There's a bunch of ways that these things aren't exploitable. But so this is an old saying. But now AI could maybe write exploit code.

So it does a good job of making some percentage of them more exploitable. So maybe we go from 99% to 95%. People out there saying, "Well, it's still 95%," but that would be a huge amount.

I don't know if we'll ever get to that high, to that big a jump. But nevertheless, let's assume it makes some jump. Right.

So now this is like the book The Goal or The Phoenix Project, the theory of constraints. Now we move to the next bottleneck. Right.

The next bottleneck is, okay, we got to fix them. We got to fix them. How are we going to fix them?

Well, we could do them by hand. We could do them by AI, maybe. Yeah.

We could automate them. Now we fix the vulnerability. But Jeff, we go round and round the merry-go-round here, round and round the maypole.

But at the end of the day, when do we get to writing better, more secure code? Yeah, that's the thing. It's kind of a failure of imagination here.

Yeah. We're trying to solve yesterday's problem with AI. So they're using it, the current mode of people's AppSec programs is find vulnerabilities and fix them, and find them and fix them, and find them and fix them.

And we all know that we should be doing things like secure by design and threat modeling and security architecture and assurance work, but nobody does that because they're too busy feeding the hamster wheel. But I think the real interesting opportunity here is how do we keep toppling those dominoes, and we use AI to do some of those activities that we were never able to get to because we didn't have enough experts. We couldn't scale them.

They weren't part of our process. But that's the real opportunity here is using AI to generate a positive assurance case automatically for the software that you're building. And, if you read the people that are really doing software development with AI, they're talking about dark software factories where you feed it a spec, and it runs in the dark with the lights out, and a few hours later, it spits out a fully complete, fully tested, a working application.

And look, that's on the cutting edge here. It's not perfect yet. I'm not saying that exists.

But it's going to exist. And we can make security part of that, but we got to be working on those dominoes, the next five dominoes that have to fall. How do we do threat modeling with AI and feed that into a spec?

How do we do security architecture and feed that into the spec, and so on. That's how we get there. Let me ask you a question.

Do you ever wish, if you could go back 25 years ago and tell Jeff 25 years ago what was happening here, what do you think Jeff of 25 years ago would be saying? You know what I would do? I would make a really dumb security product that checks a box, and I'd sell it like crazy.

Sell it like hotcakes. For the last 20 years, that's what has succeeded in the market. That's the security industry.

And that's terrible. I probably wouldn't do that. But like- No, I know you wouldn't ...

it would make a lot of money, bet you it's- But I hear what you're saying. But let's be real for a minute. As much as, and you know a lot of security people, I do too.

We want to make the world better. We want- That's right ... more secure software.

We'd like to see developers develop better, higher quality software. We want to make it easier for people not to be hacked- Yeah ... and security instances.

However, we're very much a A-to-B-to-C kind of world of industry, right? And you look at this as a visionary kind of person that you are, Jeff, and say, "Wow, I could see beyond the first three dominoes. I could see to the promised land," and this might get us to some sort of promised land.

Yeah. But the average Joe, he doesn't. He sees going from domino A to domino B to domino C.

And you can't blame him, right? His bread's buttered there. Right.

Their bread is buttered there. But so how do we get people to see that big picture, to see the end game, to move to that and not get stuck in the trees? Yeah.

Forest. I think the more I mature and the more I understand the market better, I think it's pretty obvious to me that the market is broken. And I've talked about this for 20 years, but the market doesn't really demand security, and a lot of that comes from the sort of the regulatory, the big tech lobby and the regulatory kind of environment that we have in government right now.

I thought we were making progress with some previous cybersecurity orders, but the latest ones are really not pushing that hard. And without regulation- It's a concept of a plan. Yeah.

So that's going to be really tough to change. We have rules in this country that say money is speech, and so big money buys policy. And, without policy change, that's going to be tough.

So we've got to work within the constraints that we have, which is that organizations are required to do very little. The compliance requirements are, they seem burdensome, but- They were always least common denominator requirements, but they're even worse. They're getting worse now.

I agree with you. Look, this Mythos thing is, and the response to Mythos is a perfect example, right? The CSA came out with their Mythos-ready report.

A lot of people you and I know are involved in that, including the folks at RSA and a lot of industry. But little to any public government involvement. Well, here's the thing.

It's going to take a long time to change for the reasons that you're citing. Security people, they want to do the right thing, but they're also very conservative. And I think I'm pretty aggressive that way.

I want to blow things up and change them because I don't think what we've done is working. And when you look at the stats in AppSec, the average app still has 25, 30 vulnerabilities. That's the same number that it was when we wrote the OWASP Top 10 in 2002.

And it takes six months on average to fix vulnerabilities. Just all the stats are really- And that's part of this. Okay, so I already have this many, let me put my hands up, this many vulnerabilities that are just sitting there.

Now I'm going to have this many vulnerabilities that are just sitting there. What changed? Yeah, right.

It doesn't change. And I feel like we know that the existing process doesn't work very well. To me, that's the bar we have to exceed.

But- That's a pretty low bar, my friend. It's a low bar, but it's very difficult to get people to change the way they do things. They think that AppSec testing has to be a certain way.

It has to be scanned. They think that security architecture is something you do every once in a while. That compliance is the big driver, and I don't know, it's weird.

People don't use runtime protection. That's crazy. The one thing you can actually do that really lowers your risk dramatically is put some runtime protection in place around whether it's an AI app or a regular app or API.

You should run without that. Some of that is because of the silos in security. If it ain't AppSec, it don't mean crap, and so in AppSec, it's all about runtime and, "Oh, that's someone else's job.

" But that's the biggest risk, is the people- Oh, absolutely ... the processes, and the culture. Those are going to take a decade to change.

Yes. Yes. Even with AI Agreed.

And I wish I could paint a rosier picture for you and disagree, but- Yes. It's the truth, and that's just within the security silo itself. Right?

Now if we start saying, "Okay, if we're going to speed up vulnerability remediation, we got to automate remediation," well, you got a big problem in the IT department there about that because they're not going to go for that. Right? I learned this lesson in my days of doing Still Secure, when we had intrusion prevention.

We went from detection to prevention. We went from vulnerability finding to remediation. No one wanted to turn that on for whatever reason.

" But there's a massive difference there. People are much more reticent to accept an AI-generated fix into their code base than they are to use it to find a vulnerability. Yeah.

And even if they're using AI to build the code, they're still not comfortable. The security people aren't comfortable with using AI to fix the code, which is kind of crazy, but- But it is. But it is what it is.

That's why I love this time. It might be crazy or not. So here's the thing, though.

I do think we're going to pass through a bit of a crucible, right? Just the sheer weight of vulnerabilities and these other things, I think it's going to, I don't want to use the word force, but force people to reevaluate a little bit how we do things. And I think we do come out the other side better for it.

Yeah. It's just getting there. Yeah, it would be incredibly helpful if the government would put some weight behind it.

I know in the EU, they're pushing the Product Liability Directive. Absolutely. It's super exciting and changes everything.

It's a really simple change, actually. It just says software's now a product like every other product. Yep.

And you can be held liable. No, but here we're trying to preempt states. Let's not get into the politics of it.

Let's just say that I do hope that one day, maybe after this next election cycle or the one after that, we kind of come to our senses a little bit and realize- Unless the market changes ... it has to be a partnership. Unless the market changes, nothing's really going to change.

We might have some changes on the margin, but it's going to be still mostly about not getting fired and meeting compliance. And that's- And doing good security is going to come third, even though that's what everybody wants. No, it's the A to B to C people who don't, they won't get to C without doing B.

Anyway, Jeff, we're over time, but I enjoyed talking to you, man. I'm sorry I didn't get a chance to see you at RSA this year. We were busy.

I know you were doing different things with Contrast, but don't be a stranger, man. Oh, of course not. Thanks.

Actually, no, there's too much good stuff going on. We should talk more. Well, now that you're in the 20th century with your fiber hookup, we can talk more frequently, maybe.

Absolutely. Always on. com, here on Techstrong TV.

We're going to take a break. We'll be back with more. Hey, everybody.

We're back at Amsterdam, and we're here at the KubeCon + CloudNativeCon Europe Conference, and I'm talking to my friend Valdemar here about a new version of LocalStack that's out. And LocalStack is basically a local replica of an AWS environment for developers. Valdemar, welcome to the show.

Thanks for having me. It's good to be here. So, what's new in the latest release and the latest update, and what can I do today that I couldn't do two days ago?

Yeah. So we had some exciting changes that we pushed out yesterday. So we basically unified our community offering and our paid offering into a single unified experience.

So previously we had an open source repo that was on GitHub, and we built an image there, and then there was a separate experience for our paid customers and the paid offering. And we decided we want to unify these two into a unified version. We also provide a free tier with pretty generous for non-commercial use.

And you actually get more functionality and more features also than what you got previously in the free version. So that's kind of new. We are generally always evolving and implementing new features in the emulator, of course.

There's been some exciting developments. AWS is our flagship product, but we also recently launched a Snowflake product about a year ago. And we are about to launch also Azure in the next couple of months.

That's currently on a private preview. Cool. How do you keep those things in sync?

Because the AWS cloud environments are constantly changing, so how does that kind of stay even with what's happening on the local desktop of the developer? That's, yeah, a great point. So we built a lot of automation and internal tooling to keep up with the pace of change at the cloud providers.

So that starts from, for example, scraping all the API specifications. Those are public, and then we can see whenever there's a change in the APIs, we can start implementing the change on our side. But yeah, I'm not going to lie, it's a catch-up game, and it keeps us busy, for sure.

Yeah. So who wakes up in the morning and decides that this is their problem? " Right.

Who takes ownership of making sure that whatever gets built locally can actually run on the runtime? Yeah. So this is really sort of our kind of bread and butter.

So we have an internal prioritization mechanism. Of course, any larger customers that we work with, we know well in advance which kind of services, which kind of workloads they're running, so we can more proactively make sure that everything works. And then when it comes to more the broader community adoption, we just have like a backlog of feature requests that we just work through in general.

But yeah, this is really this high-fidelity environment that we offer is really sort of the value proposition of what we bring to the table as a company. I guess what I'm trying to get at a little bit is it the developer who wakes up and says, "I'm tired of getting yelled at, and I'm going to go build this and add this locally"? Yeah.

Or is it a DevOps team that kind of sits up on top of this whole workflow and says, "We need to give these guys a better experience locally so that we're not having the same conversation over and over again"? Exactly. So we're working more and more with these DevOps or platform engineering teams that are basically rolling out developer experience for the entire organization.

And typically, it's something like you have a make script or something that stands up your local dev environment, and they are the ones that are kind of standardizing it across the org, right? And we're working with these platform engineering teams to make sure that they have a consistent experience across all the devs in the organization. There's also some insights and telemetry that they receive, if they use our paid offering to see which kind of services are being used and how many instances are basically running.

But yeah, it's all about having a central entity, either a cloud center of excellence or a platform engineering team typically that we work with. We, of course, live in the age of AI now, and you can't walk down the aisle here without somebody leaping out to tell you about their great new AI thing. How do you envision AI playing out in this world?

Because I see AWS is playing all out with AI and will you create this complementary set of agents or how does that work in your mind? Yeah, so the whole AI acceleration is actually something that plays very much in our favor. We did not plan for that when we first built Localstack.

But now, the whole industry is talking about sandboxes and how you want to make sure to have a risk-free environment that these agents can operate in. And Localstack is the ultimate sandbox environment in that sense. So what we started doing is we built, for example, an MCP server integration that makes it very easy for these agents to talk to Localstack, do a lot of the testing.

And it just accelerates the feedback cycles also for agents. So there's a couple of comparisons that we have on our website. It takes maybe 15 minutes to spin up an RDS database cluster on AWS, minutes, and it's like five seconds on Localstack, right?

So those are the kind of side-by-side comparisons, and those have compounding effects the more you test and the more agents you run in parallel. The other thing we hear a lot about these days is digital sovereignty, and it's no secret that a lot of developers work in one country, and they work for companies in another country. Mm-hmm.

Is this mechanism that you have kind of giving me a way to hire developers anywhere in the world and give them local instances so that I'm compliant, but when the actual thing that I want to run, I might want to run somewhere else? 100%, yeah. This is something we see a lot that if you have a global workforce and you might have different local regional jurisdictions or different legal systems.

So yes, we're kind of democratizing that in a sense, right? Giving you more on-premise or local execution environments before you hit the real production. And this whole topic of sovereign cloud has come up a lot at this event also.

I think in Europe specifically, it's a big topic, presumably also in other parts of the world. So it will be interesting to see where that goes in terms of is Europe going to create their own cloud at some point, or is it more like a region of AWS or some of the big cloud providers? But it certainly, again, is very much in the same narrative that we also play.

It's decentralized, with more test shift left, test more at the edges or at the end consumer. So interesting trend also that plays in our favor in a sense. " Yeah.

I think we definitely have a set of best practices how to ideally set up Localstack and get the best value out of the tool. For us, a lot of it is just educating the market to some of the more advanced features that we're offering. Because the foundation of what we do is these emulators that give you this local cloud environment, but we're also building a lot of what we call DevX features, things that sit on top of the emulator and give you additional developer value for debugging your stack or doing certain experiments.

We have a feature that we call chaos engineering, for example, where you can inject errors or latencies into these APIs and test for resiliency. So it's mostly about educating the market of what's already possible with the solution today that goes beyond the pure emulation part. Are you seeing a shift towards platform engineering as kind of a larger trend?

And what does that platform engineering team look like compared to, say, a traditional DevOps team or even a loosely affiliated set of developers? Yes. So surely, the term IDP, internal developer platform, is something we hear a lot from customers.

There is some off-the-shelf IDPs that are being used, but also increasingly teams building bespoke solutions within the organization, within the enterprise. And almost every large org we work with has some kind of a DevX team or a platform engineering team that is following, if it's a regulated environment, for example, banking, insurance, they might need to follow certain internal rules or laws. So yeah, it's very much sort of a core offering, and then you have these satellite integrations that are usually making it more seamless to integrate it into a certain organization.

Yeah. How much development is still happening on a local laptop versus when there was a push for a while there to kind of push all the developers into these cloud services? Mm-hmm.

But it seems the developers kind of like holding onto their machines. Exactly. Yeah, because if you have your IDE set up there, you can set break points and you'll have deep inspection of your stack.

I think maybe also with agents now, this idea of these cloud development environments is coming back a little bit more because when you shut down your laptop, then the agent dies. You want to make sure that you have some consistently running instance in the cloud. The nice thing about Localstack is it's a very portable environment.

You can bring this on your local machine, in a CI/CD pipeline, it can be in a cloud development environment. So it doesn't really restrict us in terms of where it runs. It's more we're alongside wherever your code runs or your agent runs really.

Or is the developer just going to wind up with two machines, one for them and one for the AI agent that runs a couple of tasks and then ships it over to them? Yeah. And I think we've seen those with things like Cloud Code, sorry.

Was it? Yeah, Cloud- OpenCloud, I think OpenCloud, exactly. Yeah.

To kind of using some of the Mac Mini that's maybe in your home environment and just spinning those up and having this agent run there. So I think it's kind of a bit of a resurrection for compute that is just up and running all the time, and you have things running that are reacting to events or doing work on your behalf. At least we're all talking about the fact that in the age of AI, the pace of application development should accelerate considerably.

Mm-hmm. " My personal view is it's probably the latter. So we need to fundamentally rethink software engineering best practices in general.

So what we're already seeing today is a certain review bottleneck. So a lot of code is being generated by these agents, and it's still predominantly humans who need to now review that code, have a conversation with the agent, something not working and so on. So I think just everything that's been built over the last decades around human-centric engineering, I think will have to adapt to a certain degree.

And I think the other interesting area is code generation is kind of growing at an exponential rate effectively. There's just so much code that's being generated, also sloppy code in some cases, but the actual code that makes it into production is not growing at the same pace let's say. So there's a big sort of gap, which we call the testing and validation gap.

You need to give these agents an environment to test and rinse and repeat in terms of the logic and have also strong quality gates in place. So I think over time it's going to be less maybe about the actual code logic. It's more about making sure that you have guardrails and quality gates that really define the outcome that you want to achieve with the application effectively.

So how do you envision this playing out? Each developer's likely to have multiple AI agents that they're using to build. Mm-hmm.

There's probably going to be autonomous AI agents on the back end somewhere on the CI/CD that's managing certain tasks on behalf of a bunch of developers. Mm-hmm. How will all that get orchestrated?

Not to mention all the agents that might be sitting up in the cloud. How are we going to kind of manage that so these agents can coordinate? Coordinate, yeah.

So there is already some level of, for example, this new paradigm of spec-driven development, which is something that's now emerging. So there's already a certain specialization happening that you have agents that are a bit more like a PM, like a product manager, and then there's another agent that's a bit more like a software architect, and there's another agent that's more like a senior or junior developer. So we're starting to see some specializations already in the planning and execution phase of how software is being built by agents.

The other interesting trend is kind of adversarial situations where you have one agent maybe generating code, another reviewing, and they kind of critique each other essentially. Or the most advanced use case would be like you have a fully multi-agentic use case where everybody's trying to achieve the same goal, and then you have a waiting function and the best solution just wins in the end. So I think those are the kind of scenarios we're probably going to see more in the future I guess from- Will these agents kind of argue with each other then at some point, just like humans do about certain things, and how will we decide to resolve that?

And what's going to be the language that they talk to each other? Is it going to be English? Yeah.

Yeah. Definitely interesting times. I think we're going to see much more in 2026, 2027.

So it seems like the industry is in almost like a pivotal moment right now with figuring out this next wave of development. And as you said, a lot of the booths here are about AI agents, so interesting times for sure. So let's pretend that you have been made king of all things IT for a day.

What's that one thing you would fix by decree if you could? King of IT. So I would focus on efficient utilization of my resources, so making sure that there's no waste and no idle resources that are not being used.

So that's the first part, and when it comes to application development, it would be focus on the guardrails. Really in order to accelerate things, you still want to keep the quality in place. So testing and test quality and coverage become even more critical than in the past.

So yeah, those would be the two points, resource efficiency and guardrails. And we talk about things like FinOps out there, but it seems to me like developers aren't inherently wasteful, but they don't have a lot of visibility into how much infrastructure is being consumed and what it costs. Mm-hmm.

So is that something you can provide using your platform? Because I don't think they understand how much it might cost to run something that they're building on their local platform. Yeah, 100%.

So I think Werner Vogels from AWS mentioned that every engineering decision is a buying decision. Because as a cloud developer, if you choose to go with one service or the other, you implement it in your code, but it has a direct cost implication in terms of how much your organization is paying for it. So yes, 100%.

The one part is the-Um, having a rigorous process, especially for dev and staging environments, to keep those effective and efficient and not creating unnecessary costs with our solution, for example, but also if you test in the cloud directly. And then, of course, in production, there's all kinds of like FinOps optimizations that you can apply for auto-scaling and techniques. But for the part that we focus on, it's really anything that's pre-production, and there's a lot that you can optimize and automate by going more onto your machines, more local, and local testing.

To your second point, there's always not been a whole lot of love between the security people and the application development folks. Are there things that we can do on the local machine to reduce that friction so that I can maybe, I don't know, have a set of best practices that are running locally, so at least everybody has the same experience? 100%.

Just from an onboarding perspective of a new engineer with a solution like ours, there's no need for cloud credentials or giving them access to the kingdoms, in a sense. It's just getting started, up and running real quick. The model that Localstack provides and offers locally is even that you can test your applications and develop them even without IM or security built in.

So we have a way to enforce IM locally in Localstack, but you can also turn it off, switch it off. If you're just interested in the functional piece and you just want to develop your app, you don't care about the security piece, and then you can maybe do that at a later point in time. That's also feasible and possible with Localstack.

But yeah, to your point, I think security teams will be happy because they don't have to distribute credentials to everybody and do key rotation and whatnot. Don't have to take care of cleanup scripts that are running every night and clean up unused resources. So it's just a fundamentally different way of thinking about resources and development.

Yeah. All right, folks. You heard it here.

Well, it turns out laptops and the cloud can live together after all, in harmony. Hey, thanks for coming by. Thanks so much for having me.

All right. And we'll be back in a bit. Hi, it's Jon Swartz at RSAC again, with Nicolas Dupont, who's the founder of Cygborg.

Welcome, Nico. Hi. Thanks for having me.

Great having you. Day one of the show. You just didn't get here.

You're from the East Coast. You went to a show last week down the road in San Jose, GTC. Yeah.

I actually want to ask you about that. Well, we'll talk about RSAC plenty, but what were your impressions of that show? It was insane.

It takes over the whole city of San Jose, as you know. We were exhibiting there Monday through Thursday, and it's really the epicenter of AI and kind of the pulse check on where the industry's going. So it was very interesting.

It's kind of the polar opposite of RSA, where security very rarely gets talked about at GTC. Yes. And this is all about security.

It's always interesting. One comes after the other, and almost kind of in the way it plays out in real life, where you evolve all these advancements in AI, cloud, whatever. And then there are the consequences on the security side, so that comes later.

Yeah. It's a secondary whiplash, for sure. Yeah, absolutely.

And I'm just going to ask you about RSAC, and just a couple things, and then we're going to go deeper into your company and what it does. Because I think it's really important what you're doing, and I want you to spell it out for us because we might have some folks out there who are unfamiliar with your company. But RSAC, it's interesting in that it's become almost a little bit of a political bent.

There was definitely last year what went on with CISA, and I think the current climate of our security framework. But I'm wondering what you anticipate coming out of this show or what type of themes most interest you going into the show. What would you like to learn more about or hear more about here?

Oh, that's a good question. I think we're seeing a lot of AI for security, in the broad sense of the word. And I think that I haven't gotten a chance to walk the expo floor.

It opens at 5:00 today, but I anticipate we'll see a lot of that like we did last year, probably even more so. I'm actually more interested in the other side, which is security for AI, which is how do you secure model behavior by all means, but how do you secure AI infrastructure? The kind of boring meat and potatoes of the next attack vectors that we'll see in the enterprise.

Right. I'm so glad you mentioned that because we do a show every day, usually live, Techstrong Gang, and that is a constant theme. This idea that this technology's moving so fast, we see a refreshing of models every month from each company.

We hear so much about agentic and autonomous workforces. We hear so much from the top down about how this needs to be put into use, but security is... It's not given short shrift, but it's mentioned down the list of importance like it always has been.

" Yeah. And is that- The underlying anxiety ... do you hope they acknowledge this here?

Yeah. I'm sure they'll talk about it. I'm sure they will.

We're at the RSA Conference, so there's going to be talk about it. I'm biased because that's where we're focused on, the underlying risks from the centralization of data for AI and what that implicates in the enterprise and downstream everywhere. So it's always interesting to see how everybody else is thinking about it and who else is trying to solve the problem.

Right. You mentioned AI infrastructure, and it was very well put. I think it may have been from your company.

I'm not sure where it came from, but basically said AI infrastructure is harboring a hidden security risk, which is the vector databaseCould you maybe expand on that a little bit? Sure. And I know it plays into what your product does, among other things.

Yeah, totally. So, maybe I can set the lay of land a little bit. Sure.

Absolutely. Over the past call it three years, we've seen a massive shift in the center of gravity in AI from training, who had the biggest GPU clusters, was able to build model frontier capabilities, to inference. You go to any AI conference today, it's all about inference.

Inference speeds- GTC was a lot about inference ... it's all about inference because that's where you get ROI from your massive AI investments. And the way that you drive value with AI, specifically in the enterprise, is by arming the AI applications and the AI agents with data that is proprietary and specific to you and your organization, so that it can drive insights or take actions that are relevant to you- Mm ...

and your organization. And that creates an inherent risk because in order to do that, you have to centralize and pre-process your data to be AI ready, so to speak, to put it in AI knowledge bases. And so you're taking data that was previously siloed across the organization and centralizing it to a single point of failure, a kind of honeypot of source, which is your vector database.

And, this creates an inherent security risk because, A, if I'm an attacker wanting to breach the organization and get a cross-section of the data from that organization, I now only have one place to hit as opposed to all these various silos. Mm-hmm. But also because this AI knowledge base, which is typically a vector database, is comically ill-equipped to deal with this type of security risk.

And that's because vector databases deal with vector embeddings, the lingua franca of transformer models. They deal with those in plain text because they have to compute distances between vector embeddings, and they can't do that over ciphertext typically. So it's processing all of this data in plain text, and it's creating kind of a big hole in the security posture of basically every enterprise pipeline out there.

Wow. I was going to ask you about the architectural constraints. So explain this to me as a layman.

So vector databases operate in plain text with no encryption in use. Can you kind of be more specific on that? Or may not be more specific- Sure ...

but can you explain why that's important, why that's significant? Right. So, in the traditional database world, with structured databases, you have row-level encryption, column-level encryption, in document stores you add field-level encryption, et cetera.

These are well-known paradigms for being able to use cryptography to secure data and enforce strong access control on that data. In the world of vector databases, vector databases do have really just one job. It's unstructured semantic search.

How do you search for data via context, via meaning, without an underlying schema or structure? And inherently, in order to be able to do that, you take data, you process it, you feed it to an embedding model, and you convert this data from its original modality, whether it be text, images, audio, 3D spatial data, et cetera, into vector embeddings, which are these very large, high dimensionality numbers, that encode semantic meaning or context to that piece of data. And vector databases allow you to do that search, matching of for a given query, what is the most semantically relevant piece of data or pieces of data at scale, very rapidly.

To do that, they employ a distance computation, a distance metric such as Euclidean distance, cosine distance, et cetera. Mm. And to compute the distance between the query embedding and the candidate embeddings that are in the knowledge base, they need to literally compute, do a L2 or a dot product to be able to compute that distance.

That needs to happen in plain text. So it means that the data cannot be encrypted while it's being used. And furthermore, if you were to have to encrypt the index and decrypt it on the fly to be able to add this encryption and this strong access control, it would make performance slow to a crawl, this inline decryption.

So it means that every vector database out there is essentially insecure in this regard because they're operating on data in plain text. And so this creates a risk in terms of infrastructure compromise, right? Any access to the host, any type of insider risk.

Mm-hmm. The data is not encrypted, in use, and sometimes not even at rest. And also it makes it really difficult to do things securely, like multi-tenancy.

How do you isolate multiple tenants on a single vector database when the data is not encrypted independently across tenants? How do you do strong access controls, whether it be rule-based, role-based, attribute-based access control? It's a very immature breed of technology that enterprises are betting a lot of not only money in their infrastructure, but in their actual proprietary data storing within these vector databases.

So in a sense, there's kind of this calculated risk. What I think about is in terms of priorities, in terms of, not to be alarmist, but I'm assuming there are a lot of enterprises who are verily concerned about this scenario and what could possibly go wrong. And I'm wondering, what type of companies are you working...

You're working with a lot of enterprise companies. Is it across the gamut in terms of industries you work with, or are there particular ones that are more focused on this than others? Yeah.

Well, firstly, we've been partners with NVIDIA for a little over two years. We've been working very closely with them and a number of their teams. com.

Okay. We're one of seven companies to do this with them. And it was kind of a reference architecture meant to show for enterprise use cases, how do you build secure AI infrastructure specifically for RAG, which is the bread and butter of enterprise AI today.

And we're doing some additional work now on agentic RAG with them. But this allowed us to get a lot of credibility and exposure in the enterprise becauseWe also don't want to be alarmists, but we don't believe- Yeah ... it's a calculated risk today.

We're very much in a phase of the market that is market education, teaching that this is an inherent risk of vector databases, that vector embeddings, if leaked, are invertible, meaning you can convert them back to the original modality of data. So they need to be treated with the same level of sensitivity as source material. And so in that vein, we're working with a lot of companies that are traditionally very security-minded.

So the companies that we work with then in turn service regulated markets like financial services- Mm-hmm ... insurance, healthcare, and public sector. And then there's also a lot of organizations that are starting to realize outside of these traditional sectors that actually my data should be secure even if compliance is not required.

Are you finding that, say, this year compared to last year or even two years ago, the level of scrutiny and awareness of what's going on in terms of security is much higher than it was? Because to be honest, last year I thought was hailed as the year of... " I'm just wondering if the level of awareness of security is higher now than it was a year ago.

Definitely. I'm really glad you brought that up. Firstly, I feel for CISO's today.

They've got 1,000,001 risks to emerging risks to have to parse through and they're underwater, so I completely understand. And a year ago we were kind of screaming into the void about this particular brand of risk, of the centralization of data, vector databases not being secured, but thankfully a lot of organizations have come out with lists and with materials regarding this that have highlighted this risk. So OWASP came out last year with their top 10 LLM and GenAI risks list, and number eight on there was vector and embedding weaknesses- Okay ...

which is exactly this- What were the top, do you remember? I don't want to put you on the spot, but- I could- ... it was in the top 10.

It was number eight on there. Obviously, context poisoning was up there. Model jailbreaking.

I couldn't tell you exactly what the list is. We're focused on our narrow slice- Mm-hmm ... of the problem space.

But they came out with their top 10 agentic risks, which also had that. MITRE came out with their frameworks and called this out as a risk. Fenno.

So there's a lot of industry organizations- And was this based in part at all on high-risk incidents, or was it just based on possible scenarios that they were thinking through? 3 out of 10 criticality that let anybody with access to the same network as the vector database itself to bypass authentication and dump out all of the data from the knowledge base directly. And they were very responsible in patching it and disclosing it.

But these security organizations are realizing the writing's on the wall. The risk is going to transform from a risk to an actual breach that will be traceable back to this problem. And so I would say the appetite to solve it is increasing, the awareness is increasing, and the tools with which to actually solve these emerging risks are also maturing quite a bit.

So in that vein, in terms of solutions, tell me a little bit about CyborgDB. How does that address this problem or try to tackle it? Well, we're laser focused on this problem, and we have been for a while.

We've been working on the underlying technology for CyborgDB for close to six years. And so CyborgDB is essentially application layer security for AI knowledge and memory. So what that means is it's essentially a Docker container that sits within your AI infra, in front of a backing store, whether that be object storage, whether that be Postgres, Redis, or your file system, distributed file system, and it replaces your vector database and it does two things.

It does what a vector database does, which is- Mm ... essentially approximate nearest neighbor search. But the second part, which is unique to Cyborg and subject to our family of 16 US patents, is cryptographic indexing.

So we transform vector embeddings into cryptographic tokens that allow us to selectively regenerate those tokens at search time in order to do that coarse approximate nearest neighbor search on encrypted vectors without decrypting them. Then we only decrypt the final candidates that need to be re-ranked and fed to the LLM, or we even have modes that use partial homomorphic encryption for the last re-ranking step such that there's no decryption at all. And so it does a few things.

That firstly now makes the vector database encrypted even in use- Mm-hmm ... significantly elevating the security posture of your entire pipeline by making your proprietary data secure. It allows you to do cryptographic multi-tenancy, cryptographic isolation for multi-tenancy- Okay ...

which is a really difficult thing to do today with vector databases. How do you have multiple tenants, whether within an organization or actual separate organizations in a hosted solution, have strong guardrails and isolation guarantees, and allows you to do strong access control that is cryptographically enforced- Okay ... whether it be rule-based, role-based, attribute-based access control.

And so we've built this and we shipped it last year. It's at the heart of this blueprint that we did with NVIDIA, and essentially meant to solve this wholeA class of problems at the heart of enterprise AI pipelines. Okay.

So I'm going to go back. You founded the company, you said, was it six years ago? Yeah, we started working on this about- So you started in this specific area six years ago?

We were working essentially a separate startup before that on- Okay ... data compression, and began working on searchable compression, which was a really interesting technical space that had zero commercial value. Yeah.

And that kind of gave the idea for this venture, working on searchable encryption. So that's what... Yeah, that's kind of what I was getting at, is every company has this journey, and I was just wondering how maybe in the last couple few years with this kind of rabid, kind of almost feverish pursuit of AI that changed the thinking of the calculus within your company of what you were going to do.

But it seems like you were already on that path. " Right. That's kind of- Sure ...

what I'm trying to get at, actually. Look, I wish I could say that in 2020 when we started working on this, we saw the whole in enterprise RAG pipelines. But to be honest with you, enterprise RAG didn't exist.

None of these words were really around at that point in time. We were working on building solutions to do... We were laser focused on how do you search while keeping data encrypted, and vector embeddings were actually a means to an end for that.

And then we just happened to be extremely fortunate in terms of market timing, that vector embedding started to become the heart of enterprise AI applications. And we just happened to have built a robust system for being able to search through them semantically while keeping them encrypted. So I do not mean this as a loaded question, but how prepared are most companies addressing this kind of agentic AI or autonomous workforce mandate?

I'm wondering if most of them are pretty well positioned or have thought this out, or if there's such an incredible amount of pressure to adopt, whether they're kind of walking a tightrope. And I don't want you to cast aspersions towards industries, but I do wonder, based on what we have written about and some of the studies I come across with CISOs, it's like they are being asked to run down a very fine line with not a lot of margin for error on either side. Candidly, I think the market at wide is vastly underprepared for what's to come.

Yeah, I agree. And it's not for fault of trying. Mm-hmm.

And even at this conference, everybody's trying to solve this problem. I think that the problem fundamentally is that most organizations have not figured out how to mitigate insider or rogue employee risk, right? Social engineering attacks are still running rampant, and the way that they work is by conducting a social engineering attack on an employee or an insider in order to be able to conduct some sort of breach.

And agentic AI is no different. We're trying to imagine that it's a new future where you've got these machines that are somehow very different than humans and very different than employees. But I think that if you're looking at it that way, you're looking at it wrong.

With agents, you're just onboarding new employees, essentially. You're onboarding non-deterministic systems- Yeah ... non-deterministic agents within your organization.

Well, guess what? Companies have been hiring non-deterministic people for a very long time. That's humans, they're employees.

And so looking at how we solve the insider risk problem is kind of the same way that we solve the agentic AI risk. Different tools by all means, but so long as we've not solved one, I don't think that we're going to have the other one fully solved. And the risk there is that the speed at which an insider attack happens by an employee is vastly slower than by an agent.

See, this is the thing. This is the rub for me that is particularly terrifying because I'm seeing, given the state of the economy and this urgency among companies, and I'm not saying it applies to most companies, but there are quite a few companies, Meta, there's a rumored 20% layoff, which I think was influenced by efficiency- Sure ... where humans are replaced by autonomous workforce.

I think Amazon, there's this long-term goal of swapping out 600,000 folks for robots, what have you, in whatever form they are. Dell just announced 11,000. I always wonder if they, in their pursuit of better profits, more efficiency, whether this kind of raises the ante and raises the stakes or raises the risk.

And I know they've looked at it internally. I would hope they have. Sure.

But it's just the one thing when you mentioned this whole kind of movement towards non-human factor and where that leads for everything. I don't want to comment on any specific company. No, I'm just talking in general, this kind of climate that we're in- Right ...

where companies are trying to raise their market valuations or trying to address- Totally. I think that the change is going to be painful and is going to be a ripe opportunity for attackers. Right.

And I don't know, it's hard to say because losing talent that is in charge of the security... We're seeing there's a lot of rumors about downtime happening at some of the major infrastructure providers, that it's happening because the security DevOps cloud talent is- Excuse me ... is gone.

It's hard to say, but I know we're going to see probably a whole new class of issues. But on-- Yeah. I mean, perhaps on the bright side, maybe we'll get better orchestration of agents to address security.

Maybe. Maybe. I mean, I- Maybe We don't know.

We're in for a very tumultuous time, and I feel for all the people that are losing their jobs as a result of it. Yeah. And I hope that we've got some problems to solve from a security lens.

We've got some very big problems from a societal lens to figure out- Absolutely ... as well. Absolutely.

I don't want to step outside my- I know. You're a wise man, Nico. Hey, thanks, Nico, for your time.

Appreciate it. Nice to meet you. Thank you for having me.

I appreciate it. Thanks. Pleasure.

That's it for today for me, I think day one. Day two, I believe Alan will be back with a lot of interviews back to back to back all day. So, stay tuned.

Stay on TekStrong TV. Thanks. Hey, everyone.

We are back here live. We're at RSA Conference. We're in Moscone West.

I guess it must be getting near lunchtime or the keynotes are opening, because I'm seeing a lot of people congregating down there. But let me introduce you to my next guest, I hope I get this right, Chris Pearson- Yeah ... with Black Cloak.

Yeah. I'm going to do this a little backwards. I usually ask people to tell me a little bit about yourself.

But as the founder, I founded three or four venture-backed companies in my day. You know this because you've done it. We breathe life into our companies, especially early on.

Oh, yeah. Right? We are kind of the passion that they feed off of.

A lot of people out here don't know Black Cloak, though. So let's start there. Yeah.

How would you describe Black Cloak to our audience? It's pretty simple. Black Cloak is the pioneer of digital executive protection.

We started in 2018. We're a team of about 150 Cloakers, all spread out throughout the US. We have clients in 42 countries.

Protect about the top 20% of the Fortune 100, top 25% of the Fortune 500. And at the end of the day, what does Black Cloak do? It does digital executive protection.

What that means is that we are protecting the corporate executives, the board, the C-suite, the executive leadership team, and their families, super important, in their personal lives. Especially right now. We see what's going on with the CBS.

The threats are no higher. They're just so incredibly high right now. Yeah.

It's really important that you think about the attack surface that's at outside the four walls of the company. So once again, the CISO, the CSO, they take care of things on the inside four walls of the company. We're protecting the executive and their family members' personal privacy, personal cybersecurity, their home networks.

I mean, they have three to five homes on average. And then we add in our concierge, which is unlike anything else. It is literally an entire US-based security operations center, 24/7, that's watching, monitoring, protecting, reacting, and responding to any cyber and privacy needs they have.

And look, in a post-United Healthcare world, tragic events from December of 2024, that convergence that we've seen has only gotten worse in terms of physical and digital security protection. I love it. So now I'm going to come back to what is usually my first question is, Chris, what led you to do this?

Well, look, my background spans many different things. A little bit of time as a DHS special government employee on privacy and cybersecurity, so we saw some of these threats coming at our defense industrial base companies firsthand. Background as a lawyer, 23 years as recovering a lawyer, started a cybersecurity practice at a large firm way, way back when.

Former chief privacy officer for the Royal Bank of Scotland and two-time chief information security officer. It was the threats that I saw on the intelligence community side, as well as, as a CISO, where they were literally attacking outside the organization, right? You're not going to take down a defense industrial base company by hacking them directly.

No. But you can by targeting the board member- But the head ... the CFO, the CEO, even maybe the person that's in legal that's in charge of intellectual property and find out what's coming next before it hits.

And then as a CISO, I saw the same thing in terms of our executives, our boards, our VCs, right? Every time we announced a funding round and there was another wave of attacks that was happening. And so for us, it became really, really critical, how can I, how can my team, how can we protect our company by extending that layer of protection outside the four walls of the castle to them, their family members, and their personal lives?

So bottom line, like all great companies that start where you have a problem that is personal to you, that impacts you, impacts your team, you just got to go solve it. I love it. Before we segue into news here from RSA, people who want more information on Black Cloak, where can we send them?

io, and you can go talk to a member of our team there, see some demos, see some information, get some threat intel reports, all the rest. Really easy to do. Absolutely.

And I should mention, we've partnered with Black Cloak now over a year. It's not just executives, right? In today's world, high net worth individuals.

It is. It's a lot wider of a net than one would think when there's reasons for people to want to- Yeah ... exfiltrate, to want to slow down something, to want to have access to something.

And increasingly, things like character assassination, AI deepfakes, which we're- Oh, my ... going to talk about. But even think terrible physical things.

Kidnapping- Yeah ... and stuff like this. Terrorist-Never forget terrorist, it has terror involved.

Yep. And that's part of it. It is a wide attack surface, right?

It is those people that, if you think about it just in terms of high-value targets, corporate executives, C-suite, board members, as well as high net worth, ultra high net worth individuals, sports star, rock star, politician, these are folks that are in the limelight. Today, AI scientists, right? Because these guys, they're making more money than baseball players, not to mention athletes and so forth.

But Chris, I want to talk a little bit about RSA. Oh, gosh. RSAC.

We're here. Yeah. You guys released some news around it.

Three things. Yeah. Let's go through them.

Yeah. So this week, Black Cloak announced the further deepening of our protection platform, and it really is a platform. It's technology that is brought together, that is holistic on the privacy, the cyber, the home, and that concierge front.

And so we did three different things announced out in the field. Number one, search suppression. So you've heard a lot about data broker removal.

These data broker websites, the Spokeo, the Zetta Search- Yep ... the 411, all the data broker removers. It's absolutely necessary, but totally insufficient in terms of actually hardening the attack surface for an executive and their family members.

So Black Cloak announced on Monday they released search suppression. So if there is personally identifiable information that is out there on the Google, let's just say, that we are able to actually suppress those links to make you, once again, a harder target to find. All engineered by a great team, and really, really, we're super excited about this and the next step it provides for our clients.

I think a lot of us, Chris, have looked at this because we all see- Oh, come on ... there's too much of our personal information out there. To a certain extent, it gets to be Whac-A-Mole.

It is. Right? What you killed today, it pops up over there.

Yep. How is this different? How do we not play the Whac-A-Mole game?

So no matter what, just the way privacy is not a fundamental human right in the United States, so your data's going to be out there, it's going to be bought, it's going to be sold, it's going to be transferred. So it is going to be a game of Whac-A-Mole. But what you have to do is actually solve it through other ways.

So when your information is out there exposed on the dark web, you have to make sure that you're changing the passwords, getting dual factor, and doing encrypted password vaults, but you have to do it with and for people. That's where the concierge comes in. When you have data broker information that is out there, yes, you have to go schedule it for review.

Search suppression takes it to the next level. But then what you have to do is really teach, uniquely teach individuals how to go ahead and leak less information, harden their cellphone, their tablet, their computer. Same things that we use in the government, but make the device 100% frictionless, friction-free, so you just do what you want to do, but you're sharing less information about you and keeping that information out of the limelight.

So those are some of the tips and tricks that we actually impart to our clients. And once again, we do it with them and for them, really the key. Love it.

Yeah. All right. That was number one.

Number one. What's number two? Number two, just amazingly, amazingly proud of the team on this.

It is travel advisory. So literally, you're traveling out to some 214 countries that Black Cloak has in its inventory. We have the ability in live real time to be able to say, "Hey, here's the travel risks to the country.

Here's the things that you should think about in these different cities. Here's where the embassy is. Here's where resources are.

" This is how we judge your activities, and we're able to do that on the fly for our corporate commercial clients as a bolt-on, as an additional add-on to the overall digital executive protection platform that they already know, love, and have. This has become really important in recent times with the conflict that is going on right now in Iran. I was just going to say, it's pretty timely.

Yep. And with the conflict that occurred- It's not just Iran. You've got the Ukrainian situation.

Mexico, Ukraine, all over. Mexico cartels. Yep.

The world is a dangerous place right now. It is, and the key thing is this, the chief information security officer, the chief security officer, they're looking for a relationship partner, someone who can, on the fly, generate this travel advisory information for their key executives, for the executive leadership team members and board members that are traveling, moving about the world, sponsoring perhaps the Olympics. They want the information.

They want it at the tip of their fingers, and they also want, and we will be able to, shortly this spring, provide all that information through one button click in the Black Cloak app to our members at certain different tier levels. So really, really excited. This is where you combine good threat intel, good information, good intelligence with the actual physical, practical know-how, and actually in a formed product that out.

It's not going to be your 50-page product. This is really, really sharp. The notable quotables you need to know and get it right into the power of the person's hand immediately.

I love it. Yeah. I don't know if I should say this publicly, but I'm planning a trip in next month, and I started looking at some of the official- Yeah ...

travel advisories, and you're right. The signal-to-noise ratio in there, I don't know if I should get vaccinated for every disease known to man- Yeah ... or what else is happening.

But there- After RSA this week, at RSA, you're all set. Maybe I should, right? Yeah.

You got exposed to everything. You're all right. I get...

Touché. I was here in 2020. Yeah.

Left here and found out- Oh, yeah. I walked home with a few extra parting gifts. Yeah, exactly.

As you as well. Let's move to number three. Oh, number three.

How's that? Number three's really big, though, Tim, and- Yeah ... Well, it was interesting about number three, the topic of deepfakes, especially AI-powered deepfakes.

Look, two years after this really became possible and feasible, right? We had that in February of 2024. You had the transfer from somebody who thought it was the CFO on with them from the Hong Kong institution.

Hong Kong, yep. $25 million. $25 million out the door.

No guns used, no hacks, no this, no that. Deepfake, and the technology for doing it live real time- It's gotten better ... it is amazing.

It is amazing. So here's what we did. A few different things.

Number one, one of the smartest things possible, right? We powered up withTechStrong and had a survey done, all the rest in terms of how do we think about this? How do we go ahead and actually figure out what is happening?

And over 33% of the respondents said, yes, in some form or fashion, they have been exposed to deepfakes about them. This is the cream of the top. " This is really, really scary.

And so here at RSAC, number one, we did a two-hour learning lab on this. Nothing about Black Cloak in there. How do you think about it?

What policies do you have? What procedures do you have? What education do you, Mr.

and Ms. CISO, and your team members have to go ahead and tackle it? Second, we, Black Cloak, have announced the re-release of impersonation protection.

It's a feature within the Black Cloak application that allows for our members or people within that circle of trust, including family members, to be able to verify that I am actually on the phone with you because you uniquely have been approved to the Black Cloak platform. I'm on the Black Cloak platform. We are logged in, we're synced in together on our devices out of band, and whether it's a Zoom Meeting, a Teams meeting, a phone call on a regular old telephone line, a cell phone call, WhatsApp, Signal, whatever the cool things are that everyone's doing today, we can say, "Hey, hold on a minute.

" Right? Yep. " And we don't want to.

We want to go ahead and you just open up the app, put in the person's name, go in and say, "Hey, I'm on a Zoom with you. We're talking about a new transfer of $10 million for the new penthouse we're getting. " You send it, it does the biometrics on you on your phone, goes to your phone- Right ...

does your biometrics, sends it back, location, and now we know through the power of Black Cloak, we can rest assured that- You're you ... the other person is really you, and it's all nice and seamless, and it does not add any extra friction to the process. We're talking about five to 10 seconds to make a verification.

Really, really groundbreaking technology. We're super proud of it, super proud of the team. I love it.

And look, this sounds a little thing, like a little bit out of Ocean's 11 or science fiction, but this is real. As you said, it happened in Asia. I've seen with voice cloning, video cloning, and I'll tell you something, you know who the worst offenders are?

It's these executives doing it themselves. They're playing with things like Sora, the video maker, or other AI-enabled things that are making AI. And I'll be honest with you, I'm guilty of it, too.

You may be. You're making likenesses of yourself in an AI environment. Once it's out there, other people could harvest that, too.

What's even worse is when you think about this, your board, your C-suite, your executive leadership team, all on the website, About Us in Leadership page, they have the low-res, medium-res, high-res images out there. They've got the audio clips from the different share earnings reports. They've got the video clips from them being on CNN- That's all they need ...

CNBC, and all the rest. They already have everything out there. They got everything they need.

And here's the thing is, no putting the genie back in the bottle, no digital watermarking, all this stuff. No, stop. They're just chasing things.

Literally, all the information's there. What you have to do is just make sure that you have a way to make sure that your company doesn't lose money, intellectual property, have a breach as a result of it because you have a means and a mechanism to verify, through that closed loop network, that the person is who they say they are, period, end of story. How can we get people over to here to check this out?

io. We love having the demos, showing the demos, grabbing people on board, but we're going to be pushing this out at a rapid pace to all of our existing clients and bringing on new folks onto the platform. We got to really change the narrative- Yeah ...

and get out there ahead of it. Thank you, man. I appreciate it.

It's a pleasure. Absolute pleasure. Chris Pierson, founder, CEO of Black Cloak here, live at RSAC.

We're going to take a break. We're here all day, though. Stay tuned.

We'll be back in just a bit. Hey, everyone, it's Alan Shimel at Techstrong again. Hey, for this next session, we call it Agents+Apps+Chat.

It features Richard Riley, who's GM of the Power Platform Marketing at Microsoft, as well as our own Futurum analyst, Dion Hinchcliffe. Dion and Richard will build upon the foundational vision of Agents+Apps+Chat, creating a solution-orientated view into the heart of agentic business transformation. In this session, you're going to learn how agents are enhancing workflows and redefining the architecture of business value today.

You're going to hear about practical applications for agents in terms of UI, logic layer, and decision engines across business functions, everything from finance to HR to sales, and even customer service. I think you're going to enjoy it. Here's Richard and Dion.

Thanks, Alan. This is Dion Hinchcliffe, VP and practice lead for our chief information officer research group, and I'm with the Futurum Group. I'm here with Richard.

Richard, can you give us an introduction? My name's Richard Riley. I lead the low-code go-to-market team at Microsoft, so that covers all of our low-code portfolio, Power Apps, Power Automate, and includes Copilot Studio, our agent building platform.

Well, it's great to have you, Richard. And what's interesting, the CIOs I talk with, they're undergoing all these changes with AI, and now agentic has arrived, and they're under this realization that they are going to have to transform their organizations usingAI agents. And so I was wondering, to help them understand this, how do you define agentic business transformation that goes beyond just mere automation and really explains why it's a new paradigm?

Well, I think agents can do lots of things. We tend to think of them existing on this kind of spectrum. So you can have very simple agents on one side of the spectrum and very complex agents on the other.

So to give you a bit of an example there, I would say on the left side, on the simple side, we say agents that just do regular Q&A. They're grounded on a few documents, you ask them a few questions, and they can give you answers. They're super useful in certain situations.

And then on the right-hand side, you've kind of got things like autonomous agents that can work off triggers, they can run business processes, they can literally work autonomously, and have very complex logic, complex instructions, and run very complex business processes. And then you've got everything in between. So we kind of think it really depends on who's asking the question and what they're asking, the context they're asking the question in.

But it's helpful to think about these as a spectrum of things versus an agent is just the same agent. We appear to be on the cusp of a massive wave of agentic solutions. Some are narrow, some are broad, and some are open source.

What makes Microsoft's approach defensible and distinctive in the flood of agent frameworks and offerings that we're seeing show up? Yeah, that's a good question. So I'd probably start with the breadth of tooling that we've got.

We kind of span from the very easy-to-use experiences that are built into M365 Copilot with Copilot Light. You can literally describe an agent that you want, you can give it some grounding content, you can tell it to go talk to SharePoint and a bunch of other kind of content sources. Super easy to do, super easy to share.

Very valuable. We then have Copilot Studio, which kind of takes that a step further. You get access to a lot more capability, including things like triggers.

And then we take that an even step further when you think of Azure AI Foundry. All of these things are kind of tied together in a very integrated way. So it's very easy to move from one to the other and incorporate one or the other in your solution.

So I'd say our breadth of toolset is probably number one. Number two, I would probably talk about access to data. Any customer that's an M365 customer of Microsoft has an enormous amount of that tacit knowledge, that data in Microsoft Graph.

We make it very easy for you to get at that to make your agents more intelligent. It's one thing to be able to run off rows and columns in a CRM database or in our ERP or FNO kind of service. It's something else when you can marry that with that tacit knowledge that you've got in your enterprise to bring intelligence, much more intelligence to what the agent can do.

And then thirdly, I'd say our kind of core strength in security, governance, and compliance. We've invested heavily for a long time to help customers secure and manage their enterprise data. All of that investment flows through to your investment on the Microsoft stack for agents.

Agents respect all of the policy, the labeling, all that kind of stuff that you've already deployed to manage your data. If you're building your agents on the Microsoft stack, that stuff just flows through. So I'd say these three things are probably the three primary.

Yeah. That makes a lot of sense. And so let's zoom in for just a moment.

Help people understand, how do agent-powered interfaces change the way that workers interact with business systems compared to traditional user interfaces? There is a lot going on in the industry with how kind of apps and agents are coming together in super interesting ways. I think over time, we'll see agents starting to adopt some of the app modalities that we expect from apps today.

So think of a time when an agent can actually start to build an app or even just a UI, like a form, on the fly for it to solve a business process or to help you move forward with whatever the thing is that you're working with the agent on. I think we're going to start to see that show up. It's not today, but over the course of time, I do think the app modality and the agent modality will start to mix.

And ultimately, if you think about it, there's a very good reason for bringing those two things together. The example that I like to use is around a procurement process, like every company has to buy stuff. Today, at Microsoft, you have to know three people.

There's three different tools. A bunch of approval stuff happens. The couple of apps you have to go use, that could be built into a series of agents, and Copilot kind of marshaling the whole process.

" Copilot could know the agents that it needs to go talk to be able to do that. There could be a legal agent to check the statement of work that you're trying to kind of work through. There could be a procurement agent that could go make sure you've got access to the right, and you're hiring the right vendors.

Like every step of the way, Copilot could run that whole process. You don't necessarily need to go through three different tools. If Copilot needs some data from you, it could create a form if needed, if it's not a conversational type of thing that it's asking for.

So you can see how these things start to really blend together when you start to think about agents working with other agents, and then having something like Copilot kind of manage that interaction for you. So I'm glad you brought up talking about different agents working across the business, and that's something we call orchestration. And one challenge enterprises face is orchestrating multiple agents across different domains, finance, HR, customer service, without chaos, integration, or security issues.

How does Microsoft envision enabling agent orchestration across the enterprise, and what governance mechanisms will make it all work and safe? That's a good question. So there are a couple of things that I don't think we're particularly unique in the industry with, like supporting MCP for agents to be able to use tooling, and supporting A2A for agents to talk to other agents.

That's kind of table stakes these days. The thing where it starts to get interesting with Microsoft is our ability to use capabilities like Agent 365 to provide end-to-end observability across all of the agents that you've got running in your organization, to the extent that you can even give an agent an agent ID and treat it like a user. Things like conditional access, all that kind of stuff, just work.

And then I also think once you give organizations the ability to observe and manage and govern agents, it starts to open up new frontiers of where they can use agents. It allows them to think about business problems that they've had in the past that have historically been kind of un-automatable. Maybe they're too non-deterministic or too complicated to do with traditional automation tools, and apply agents to those problems.

And we've seen a ton of customers look at existing business processes and decompose them and figure out where they can replace certain parts of them with an agent. They don't replace the whole process, but they start to replace parts of that process, and over time, as the technology matures, as their understanding and confidence with the technology matures, they start to build out more. But also look at brand-new problems that they've faced for a long time that have just been very difficult to address with technology.

And that's when if you bring all of the assets together, the things like A2A and MCP, things like Agent 365, things like the security and governance and compliance capabilities that the Microsoft stack offers you, it really does let you start to look at these problems in a very different light and start to apply technology to things that you just previously wouldn't have tried to because it was too hard. So let's talk about really getting started with agents. You've talked about agents being on a spectrum.

How should organizations assess where they are, and what kind of agents do they need? You talk to a lot of different customers, and you have a good sense of that. Can you share that with us?

Yeah, totally. And there's no single answer to this because everybody's different. But I think it's important for people to start in a place they feel comfortable with.

It's very easy to run into this too fast, not be super successful, and then feel a little bit terrified for trying to scale it. So it's actually very similar as well to the way that people in the past, over the past six, seven, eight years have deployed low code. The deployment patterns that we see with things like Power Apps are very similar to the customers that we see deploying agents in any meaningful way.

And actually the customers that have already deployed low code at scale seem to have a very familiar pattern to follow with how they deploy agents. So it really does fall into that pick a business process, maybe just pick one, find the one that's the most inefficient, the most expensive, the most painful, it's creating the most work. And then break it down, decompose it into its component parts, and start to figure out where you could apply agent technology to those component parts.

Don't try and replace the whole thing. " Now, that may be possible, but it's really difficult. So basically, figure out what that recruitment process looks like and break it down, and then attack it in chunks.

And then you'll learn what the technology is capable of. You'll learn what your teams are capable of. And as both mature, you'll be able to expand and expand it within that process and expand it outside of those to other processes as well.

So it really is a journey, and most people will find their own way through it. We have a ton of best practices, guidance, patterns and practices, that kind of thing, and templates that we can share. But ultimately, every customer is different, and everyone's going to look at this differently and figure out which is the best place to start.

So when we talk about agentic business transformation, we see a lot of organizations are trying to figure out, well, how does this fit into my legacy systems, the architecture I have today? What thoughts do you have about how do we bridge that gap between the modern agent stack and legacy IT? Yeah, there's a couple of things there.

The first one would be find ways to integrate, like MCP is a perfect way. The rate of adoption for MCP has been phenomenal. So go learn about that.

Go figure out how you could stick an MCP server in front of the services that you want to expose to your agents. That's step one. And then step two is, if you already have deterministic workflows, which I'm certain everybody does, there are ways you can start to pull those into things like Copilot Studio, keep them deterministic, but build them as agents.

And that's one of the great value props of Copilot Studio is you can blend this kind of non-deterministic AI agent-driven approach to workflow with very deterministic with things like agent flows. So you can actually replicate what you've got in an agent, and then over time, you can start to replace parts of it, so it's more AI agent-driven than deterministic. So there's lots of ways you can start to bring these two worlds together without diving in or not.

Agents will become the core logic and decision-making layer in business processes soon enough. How does agents as the new logic layer change the way that enterprises think about their core systems? What are the implications there?

Yeah, I think there's going to be a meaningful change with how people interact with core line of business systems like ERP, like CRM. Traditionally today, this is kind of a forms over data type web experience. I think fairly soon there'll be kind of an inversion of where the IP and the logic sits.

It will be less on the database and forms layer. It'll be much more on the agent layer. And what that means for users is they're going to get faster access to data.

They're going to get smarter answers. They're going to be able to use multiple data sources to assess a certain situation. If you're a seller, why am I sending you to our customer service solution, plus your CRM to go figure out what the customer you're about to meet, whether they've got any open support tickets, and they're angry with you.

It should just be able to ask an agent to be able to do that. If you're a salesperson and you've just got off the phone with a customer, maybe the call's transcribed, maybe there's a bunch of email traffic between you. Why am I making you go repeat that, cut and paste it, make it up again, and submit it into a CRM system somewhere?

An agent should just be able to do that. So I think there's going to be that switch from people laboring away in web forms and web services to an agent proactively, in many cases, working with these systems, and helping the salesperson or the service person or whoever else it is to get more done, and be way more productive. So how are agents enabling organizations to leapfrog traditional low-code development and go straight to intelligent orchestration?

So I'll give you a few examples. The first one is, I wouldn't exactly say leapfrogging. I would say we're using agents to make that kind of low-code paradigm even stronger.

So things like the ability to use plans in Power Apps, where gone are the days where you're trying to describe an app and build an app. What you do is describe a business process, and then Power Apps plans can use several agents. There's an architecture agent, there's a data agent, and it can actually go build a business solution for you.

And that business solution could be two or three apps, some workflows, a couple of agents. It'll actually do the end-to-end thinking, like if you were a business architect, what would you build versus just building an app. So that's number one.

We're leveraging agents to help you build kind of better low-code solutions. And then number two, we have new capabilities in M365 Copilot like Workflow Builder and App Builder, where someone with absolutely zero coding experience can come and literally describe an agent or a workflow, and App Builder and Workflow Builder will go build it for you and run it. And then it can store persistent data in SharePoint.

You can share that with other people. You can even start to modify it. So if it's not exactly what you want the first time you kind of describe the app, you can modify and change it as much as you want conversationally.

And that really does open the door to many more people being able to use this technology. These aren't going to be apps that you end up running your business on. They can help a team, an individual achieve more, be more productive, using AI, to build apps, things like apps and workflows.

So what we're seeing as companies plan for the role of the maker evolving, where that maker has really been that low-code developer who's been using things like Power Apps to build point solutions in their corner of the organization. What we're seeing is that role is growing up and it's becoming one that's going to take advantage of all these intelligent agents that are being built inside the organization. And now they can build new solutions that span departments and cross silos in terms of the business processes that they can integrate.

And so creating higher order, more strategic solutions out of that agent landscape that's forming. And these are things that now will automate and run on their own, but we do see that maker still has a role and in fact an even more important one. I was wondering what you thought about that.

Yeah, it's a really important point. I also think IT are going to play a very important role in this as well. They'll be the ones building the MCP servers, so they can provide access to data and logic to business units that want to go build their own agents.

They'll be the ones that are building the kind of high order bit agents so that business users can take advantage of those. So I think when you bring those two things together, you definitely create a total is greater than the sum of the parts type math for customers. So in this new world of agents, where the code, the AI is touching your business and your data, the concern is around compliance and security.

I was wondering if you could speak a little bit to how does Microsoft ensure that these very powerful agents that are working with your business are following the rules and are secure? Yeah. It comes up a lot in conversations that I have.

The thing to remember, though, is agents only have access to the data that you give them access to. They also respect all of the policy, all of the governance controls that you've got over the data. They only get access to it if they are granted access to it.

And I think that's fairly unique to the Microsoft stack in the sense that all of the investments that you've made on things like Purview and managing SharePoint, that kind of stuff, that all just flows through to agents. When you go outside of the Microsoft stack, you essentially have to kind of copy-paste that data somewhere, and at that point, you lose all of that governance control that you once had when it was in your M365 security boundary. So it's a super important point and one where I think we have a fairly meaningful differentiator for customers.

Everything just works. I think it's fairly just pretty much as simple as that. And so thanks so much for being here, Richard.

It was great to talk with you. Thanks, Dion. Yeah, it was a really full conversation.

I appreciate your time. So what was really interesting to me is seeing how far Microsoft has come so quickly with agents. We see this as a whole new stack that's forming inside the organization.

It was really fascinating to hear that you're spending so much time looking at how do I make agents work across the business. I think we've looked at a lot of individual automation in the past in low code. But I think it's understanding that Microsoft has that big picture view, and it's the breadth of the tooling.

It's the scope of understanding. It's not just departmental. Of course, it's departmental, but it's also how do we make this enterprise wide, and how do we elevate the thinking so that we're preparing those inside of our organization, to take advantage of the big shift that's happening going from building maybe those point low-code applications to orchestrating across the business.

And a lot of the pieces around making agents work together, providing that security and compliance, that ensures that you can do all of this safely and not constantly sweating. Am I going to go outside the security boundaries? Am I going to go against corporate policy?

And knowing that all your agents can do that. It really is gratifying to see how far Microsoft has come in assembling this vision, and then offering it in... No one can say this is mature yet.

But hearing about the stories we see at your events about how far the customers are coming and already getting a lot of these things out there. So that was the takeaway I had, is just getting a sense that Microsoft is really trying to make sure that they're leading this agentic transformation. So my name is Farrokh Taef Smatian.

I'm a Principal Technical Marketing Engineer with Cisco's Data Center Business Unit. I've been with the company for over 16 years now, and I spent the last 10 years looking after Nexus product lines, specific Nexus 9K, and we recently rebranded as N9000 series. And today, I'm just going to build on top of what Richard introduced on the Cisco Nexus One.

And two the building blocks of Cisco Nexus One is Cisco Silicon and Systems, and I'm going to talk about them. And my colleague, Paymon, is going to pick up on the optics and talk a little bit about the optics as well. You all hear about Cisco Silicon One, and you all know that in Cisco, we are moving towards building platforms across different business units with Cisco Silicon One.

There are different series of Cisco Silicon One. There are G series, P series, and E series. In the data center business unit, we build platforms with the top three.

On the G series, there are AI scale switch, low latency, high bandwidth, and high radics. We built our 93 series of SG2 and SG3 with the G series. With the P series ASIC, these are more like a domain interconnect and core switches, and that is where some of the conversation around scale across comes into play, and we also use those for core switches and ACI spine as well.

So we introduced recently in Cisco Live Amsterdam, our N300 SP2R and also the SP2R line card that is for modular chassis. And finally, the E series. These are relatively lower bandwidth but highly equipped with feature sets that you need for enterprise data center.

And we built the 9300 SE1 and SE1U platforms with that. But today, we just want to focus on the G series and P series because those are the ASICs we use into AI/ML platforms. So if I put them into two different buckets, if I have the G series in one side and P series in one side, G series, they're again highly optimized for AI/ML scale out, and they're high bandwidth ASIC, high radics with low latency.

They're output queue architecture, and as Richard already mentioned, they're a highly programmable pipeline. They come with advanced SerDes speeds. We start with 100 gig SerDes lanes, and we have 200 gig SerDes lanes as well.

And they're fully shared packet buffer. And they obviously, because it's targeting the scale-out deployments and you have a lot of AI/ML backend workloads, they're highly come equipped with advanced load balancing, something we rebranded in the umbrella terminology. We call it Cisco Intelligence Packet Flow.

We'll talk a little bit more on that as well. But now if you compare that to the P series. P series, again, they're optimized for scale across.

They have integrated line rate encryption, IPsec, MACsec, and they have larger table sizes. They still have high bandwidth and high radics, but they're a virtual queue architecture. We still have a programmable pipeline here as well in the P series, and they come with advanced SerDes.

Of course, we start with 100 gig SerDes, and their on-die packet buffer is also fully shared with additional of the HBM peak buffer that comes with the P series. Okay. I have a quick question.

Sure. Phil Gervasi. Heard from another vendor today, actually, and I asked, posed the same question.

Going back a slide, with regard to the P series- Mm-hmm ... using it for scale across- Yep ... do you find that there is adverse effects to job completion time because you're using those deeper buffers, for those synchronized activities that GPUs do in multiple data centers?

Whereas normally, you'd use those very shallow buffers, like in a G series. Yeah. So the expectation is actually most of your workload won't go across the- Right.

That's a good answer ... data centers. Yeah.

Yeah. But we see it, there's differentUse cases and different scenarios that you can test. But whatever we test so far, we don't see any negative impact of having the buffers for scale across.

But to your earlier comment, you're not necessarily seeing people do that kind of activity over that DCI, right? Yes. They are doing it- They are ...

but not in a scale that you will have in your own local- Oh, okay. I see. I see what you mean now.

Yeah. All right. Yeah.

That makes sense. Another quick question to add to that. Sure.

Jason Ginnert. Yeah. So what type of workloads are you seeing go across that, in a scale across sort of scenario- It'd be GPU to GPU as well.

Okay. Yeah. Thank you.

Sure. So let's go back to the Silicon One's. They have some common feature sets and personalities, but they also have their own differences.

That's why we have different series. I just want to quickly touch on what they have in common. Cisco Silicon One is similar to Cisco Cloud Scale ASICs.

They're a slice-based architecture. So we have anywhere six from a single slice all the way to 16. And we talk about what the slice is in an upcoming slide, but their second common feature set is this highly programmable pipeline, which Richard already mentioned that.

And that's really a key here because we can use the same physical silicon into C9000 Catalyst switch, for example, or we can use the same thing in N9000 Nexus platform, or we can use it in the Cisco 8000 router. Same physical ASIC, but we can give it different personalities because they're highly programmable, and we can change their personalities. And a third thing they have in common, they have a fully shared packet buffer.

So no matter how many slices you have, everything would have access, all the ports and feeds will have access to the fully shared packet buffer. This is a little bit different than some of the other ASIC architectures. For example, Cloud Scale ASICs, sometimes you're limited to a buffer pool for a dedicated number of ports, but that's not the case with Cisco Silicon One.

It's truly fully shared between all the ports. Okay. So what's a slice?

It's basically a self-contained forwarding complex. Again, we basically divide the labor of front panel ports into different groups. It really is important to know which ports are connected to which slice if you want to scale your, for example, access list.

But you don't have to worry about packet buffering or anything like that because everything uses the same buffer. Now, first ASIC and silicon that we want to talk about is our from G-series G200 ASIC. 2 terabit.

It comes with 512 100G SerDes lanes, as well as 512 MAC, so we can get up to 512 interfaces. And it's really helpful for deployments, as Richard mentioned. If you're doing a multi-plane deployment and you need high radix, this chip can provide that.

It has a fully shared 256 megabytes of packet buffer on die, as well as this one will support LPO optics as well as four-meter DAC. So I can pass it down if you want to take a look. Mm-hmm.

Now, in addition to what I mentioned, they also come with intelligence packet flow. This is, again, those advanced load balancing techniques that we have and we use for AI/ML workloads. Some of them you're probably familiar with.

You could do high entropy ECMP, you can do a packet spray, you can do DLB or flow-led load balancing. But in addition to that, like Richard mentioned, we had a customer that came to us say, "I want to do WCMP with DLB. " And because we have this capability with the programmable processor, we were able to create that feature for that customer.

In addition, we have policy-based load balancing. This is where we talked about you can have different treatment for different type of class of traffic, right? You can do a packet spray for RDMA traffic.

It can do flow-led load balancing for non-RDMA traffic, for example. I had a question- Yeah ... relative to the slices.

So are they all the same, or you can custom- They're all the same. Okay. I actually have a next slide to show you.

So this one takes a little bit. But if you take a look, if you zoom into the slice itself and zoom in inside that ASIC that you just passed by, like I said, you have 16 slices. Each slice is responsible for 3,200G SerDes lanes, or four 800G ports.

Slice features. As the packet goes into the ASIC, again, we have an ingress portion, we have an egress portion. Some functions will happen on the ingress side, some functions will happen on the egress side.

As the packet comes in, we do our normal lookups. We have fully shared databases across the ASIC. So we take a look at if you have a V4 packet, for example, you take a look at the HRT, host route table, and LPM.

Then you find out that you have a route for it. You're not going to drop it. You forward the packet to what we call the traffic manager.

Here, we actually put the packet in the full shared memory, and we do all the rest of the decisions based on what we call a packet descriptor. So we do DLB. This is your flow-led load balancing.

We take a look if you need to do replication. In case of multicast, we do replication. We'll send it to the output queue.

And finally, the scheduler would schedule the packets to be dequeued. We read the packet from the memory, we send it to the egress controller site. This is where we do, if you have egress policy enforcement, for example, you have egress ACL configured, that's where you enforce it.

Or if you're doing VXLAN VPN, because this ASIC supports both Layer 2 and Layer 3 VXLAN, if you're doing an encapsulation or decapsulation, you need to rewrite the outer packet header. This is where we do that, and then we'll send it to the egress MAC, and the packet leaves the ASICs. Now-Another unique thing about Silicon One buffering architecture is that if, let's say, you're doing RDMA configuration, you have RoCEv2 configured, so you have to basically do a dedicated buffer pool with no drop and drop pool.

Usually with the normal ASICs, we have a dedicated ingress buffer per port for those pause frames to send out. But with the Silicon One architecture, we can actually carve up the headroom from the fully shared packet buffer as well. So you're not limited to what interface can do per interface.

You can actually allocate more if you need to. And we have customers that really tweak this allocation, and they get the best performance based on their use cases, because every use case is different. Okay?

You can kind of go in there and allocate the different memory and stuff like that. Yeah. So if you configure a no drop buffer pool, for example, you can allocate more for that, and you can have less for normal traffic.

Exactly. Now, before we get to the platforms, I just wanted to give you a little bit of nomenclature slide here, because we recently also changed the naming of some of the PIDs. So basically, everything starts with N9000.

If the second number is three, that means the ASIC underlying is based on Cisco Silicon One. If it's a one, that's NVIDIA Spectrum ASIC. Corresponding number is going to be the number of ports, and the letter indicates what type of port it is.

6 terabit interfaces. Okay? And next section is the ASIC part.

If it's a S, that's a Cisco Silicon, and then if it's N that's NVIDIA. So SG3 means, Silicon One G-series 300, for example. Okay?

And the last letter, if the platform supports both type of optic, QSFP and OSFP, O stands for OSFP, Q stands for QSFP, but for some latest G300-based platforms, we only have OSFP form factor. So the L or A would indicate whether if it's a liquid-cooled chassis or it's a air-cooled chassis. Okay?

Thank you for that. Yeah. Sure.

That will be helpful in the future. Yeah. That's half of my job by the way .

Well done. Yeah. Really quickly, I know Payman is going to go in town with the LPO optics, but because I'm supporting it in the next platform I'm going to talk about, I just want to give you a little bit of overview.

Pluggable optics, or sometimes they refer to as fully retime optics, or sometimes you hear it as retime optics, is the normal optics where you have the digital signal processing DSP in the optic. But with the LPOs, we remove that, you guys know. And what that does, basically lower the power by half.

And we support that with this ASIC that we just passed with our new ASICs. Now, one thing is important here. Not only we save power on the optic itself, but the switch also can run in the lower speed fan, so you don't have to work as much.

Interesting. So we actually did a demo side by side for a fully loaded system with the pluggable optics compared to LPO optics in OCP a few years back, and we demonstrate around 560 watt of difference, right? Because the switch was working much more relaxed than the other one with the pluggable optics.

Are you still considering CPO? Do you have a position? Yes.

Actually, a good question. Well, Cisco as a company, we have experience with CPO. We actually did a demo with the G100 ASIC.

Okay. The first version of that one. But in our engineering back in the day, we thought that, for 100G and 200G SerDes lanes, CPO wasn't as important, and LPO is doing a great job with 800G optics.

6 jump... Yeah, but when you go to- Yeah ... 400 lane SerDes lanes- Mm-hmm ...

that's when you really need a CPO. And actually, we will have a CPO with the newly announced ASIC as well. Okay.

Right. So it's on a rope. Yeah.

What's the timeframe, rough timeframe? Second half? I can tell you something, but it won't be true.

Right? So- Okay ... yeah.

But it's on- NVIDIA announced Q4. Yeah. Actually- At GC key.

So that's a good point. After NVIDIA, Jensen announced it, we see a lot more requests, and we see a lot more- Yeah ... questions around CPO, so that's why we're considering for G300.

Yes. Yeah. Okay.

So now let's talk about the 9300 chassis. So the first one, this is based on the G200 ASIC. We have the 9300-SG2.

There are two form factors. That one is a QSFP form factor, and we also have OSFP form factor. As I said, you can do breakout in every single port because we support 512 max.

So essentially, you can get 512 100G ports in 2RU. And again, that's really important if you're doing multi-plane or you don't want to have three-tier design. We also have the Cisco Intelligence Packet Flow supported with this.

These are the advanced load balancing that we're going to talk about. And if you want to support the LPO optic, which I think I have one here, you have to get the PID with the X at the end, okay? Now, their architecture is relatively straightforward.

Everything on the ASIC SerDes, they connect to the front panel port cage is straightforward. There's no PHY or MACsec PHY or anything like that between them. That's because we look for the lowest latency, and we don't need encryption with these use cases.

A little bit on intelligence packet flow. Like I said, you have pretty much all the technologies that we use today for load balancing available. In addition to that, we created the weighted cost or WCMP with DLB, as well as policy-based full load balancing.

So I'm going to give you example on what they are. If you have, let's say we have a setup with three leafs and two spines, and you do load balancing. This one will require BGP because BGP is in charge of WCMP, so BGP will see equal path to get to both leaf one and leaf two, so you will have a single ECMP group, and you basically divide 1,000 to all four different lanes, so you have 250 for all of them.

If, let's say, one of the links between leaf one and spine one goes down, right? Now you have unequal way of reaching to leaf one, but your leaf two reachability is okay. So software automatically would create two different ECMP groups, one to get to the leaf two.

That one is okay because we can use all the ports. But the second one would be different weights. So if you want to go through spine two, you have double the weight of going through spine one because you have one link down.

So that's WCMP. But we're doing this with additional flow-led load balancing. Now, the second example I want to give you is the policy-based load balancing.

This is when we talk about you can have different way of treating your traffic. So RDMA traffic, you can do flow-led or RDMA traffic based on a DSCP match. You can do packet spray, and you can also have a default mechanism to do default ECMP if you want.

Again, that's possible with G200 ACX. Now, this would require reordering of packets at the NIC level. If you do packet spray- Yeah ...

your assumption is your next, yeah, they can reorder packet. Right. Okay.

Next, ASIC. We recently at Cisco Live Amsterdam, we also introduced G300 ASIC, which is double the bandwidth of what you just saw. 2 terabit ASIC.

6 terabit interfaces. You still got 512 radix, so you can do breakouts to 512 200 gig, or you can do 128 800 gig, and these are based on 200G SerDes lanes. This one also has a fully shared packet buffer of 252, and again, of course, it's a programmable processor.

And in addition to speeds and feeds, we also introduce some new capabilities into the IPF. So now APF gets another terminology underneath. They call it intelligence collective networking, which basically not only you can pick the uplink or pick the next link based on local congestion awareness, but you can also have some information from remote hosts, and what we call it the fabric level congestion awareness.

Okay? And I'm going to pass this ASIC as well. Thank you, sir.

Yep. That's the G300. Now, here are some key enhancements that we had on G300 as compared to G200.

We enhanced the telemetry feature set. We have now CSEC, PHL timestamping, and we have a full supporters packet trimming now, and with addition of some of the stuff that we talked about for topology awareness. Okay?

Now, before I talk about the platforms, I wanted to take a moment to talk about two different OSFP optics that we have today with these systems. There are one that probably most of you are familiar with, the integrated heat sync optics. What that means is the heat sync is integrated into the optics.

You can see the heat sync here. The front panel port cages are a little bit bigger. And we see these usually used in air-cooled system, usually.

But with the excitement of liquid cooling and some of these platforms are building, we have a liquid cooling plates in the front, so we can piggyback off some of the cooling to the system so we can have riding heat sync optics. So these are riding heat sync OSFPs. They're a little bit shorter, you can see, and usually you see these with the liquid cooling platforms.

I can pass it along, you can see the difference. And one more slide on the liquid cooling, and I'm not going to go through all the details here, but I want to quickly touch about the cooling methods that we see in the data center today. Most of you probably familiar with the first one, which is air-to-air cooling.

We also see some rear heat exchanger, as well, in cases that you have a hybrid environment. Let's say you have servers that are 85% liquid cooled and 15% air cooled, and you want to put the air cooled system inside the rack, then you can put a rear door heat exchanger and cool down the rest of the heat from there. So these two mostly is used with air-cooled system, but as we go forward, you need to support more kilowatt in the rack.

So we'll see direct to chip liquid cooling systems coming along now. Immersion cooling, that's future. There's going to be some challenges with the component warranties if you do immersion cooling.

We actually did a demo for the servers. But for switches, I think what you're going to see upcoming next is mainly direct liquid cooling. Okay?

And that's why we have the system here, and I want to show that to you. One more thing. Promise that's the last thing.

So there are multiple different liquid cooling racks and standards out there todayAnd if you guys familiar with OCP, Open Compute Project, they have the first one, ORv3. That's the one that Richard mentioned. So ORv3, it's a little bit different than your normal rack.

Yes, you have manifolds in the back for liquid cooling, but the power is actually provided by the rack, so you will have a busbar at the end. It's a 48-volt busbar that would provide power to all the platforms that would go inside. So your platform will have a connection that goes inside the power bar, and you get the power, and then the manifolds will connect to your connections for liquid cooling.

But ORv3 is the first one, the standard one. It's a little bit wider than normal 17-inch switches. So this is 21 inch, because the rack standard is 23 inches.

And the standard open unit, it's a little bit actually bigger than standard rack unit. 75 inches per RU, now 48 millimeters. Right.

Yeah. 5. Okay?

And it makes a difference if you have four RU systems. So you won't be able to slide this into a normal rack. But if you have a standard 19-inch air-cooled platform, there are trays that they provide with ORv3.

You could put it in a tray, and you can slide the tray into the rack. Okay? 7 is the height, because it's 2OU.

But then, of course, we also have the MGX accelerated computing rack. This basically was introduced by NVIDIA, because their use cases, they wanted more power, they wanted more cooling. So they have the MGX accelerator rack.

Now one thing is cool about MGX is, is not as wide. It's still the same 17-inch switches, but you will see them sliding into the same MGX rack as well. Now, the height is also same.

This is 2RU, right? Or 1RU. You can put 1RU or 2RU switches.

But every single RU would have its own dedicated- Points ... quick connector connection to the manifold. Right?

So NVIDIA announced their five RU switch, and you can see in the back, they have five connections to five of these liquid cooling connectors in the back. Because they have five different boards, right? So you can also have a single one in 2OU.

That means you just need one of them, then the other one won't even connect to that, right? Just going to take the Zoom mic. All right.

So that was G300. So let's take a look at the G300 platforms. We have two to display now.

One is this one here. It's the IN9364F SG3-L. Now this one is liquid cooled, but what is cool about it is 100% liquid cooled.

Usually, you see the first version of the ORv3 switches that were liquid cooled. They're mainly 80% liquid cooled and 20% still air-cooled. So you see some fans in the back.

This one doesn't have any fan because it's 100% liquid cooled. Okay? We also have a 3RU air-cooled version of this box.

And this one is interesting because usually, as I mentioned, if you have a air-cooled switch, you will have integrated heat sink optics. But with this platform, we're also going to support a riding heat sink optic. So you see the OSFP cages are a little bit smaller and tighter.

Okay? If you take a look at the architecture of this switch, this, again, relatively straightforward. G300, remember, it was 16 slices as well.

But everything is fully shared, all the packet buffer is fully shared between all the ports, so they're all directly connected to the front panel port. Now, I wanted to give you a little bit more details into this platform. You can see there are different loops to cool down the platform.

You have a primary loop, one dedicated for the NPU or the ASIC in the front. You have two loops to cool down the liquid cooling plates in the front. You have one loop to cool down, this is the power distribution unit.

Because, again, we're getting a 48 volt from the busbar, but not every component in the switch needs 48 volts, so power distribution will lower some to 12 volts and what not. So we have to cool down that one. There is one dedicated for CPU and, in addition to this component, what is also new with these liquid cooling switches, that we also have to have some sort of leak detection mechanism inside, right?

" And if you come take a look at it, we have six loops coming in, and in the picture you can see we're looping around the places that we think might have a leak. But these are all connected to the same leak detection board. Okay?

Question. Vincent Slunderwood. Yeah.

Out of curiosity, let's say you do have a leak. Is it going to be isolated to that particular unit or is there a chance of spillover? Yeah, that's a great question.

So with the switches, it's not as critical as the servers, right? So those kind of questions we hear on the server side more, and usually what you see there is what we call a liquid controller on each rack, so the controller can decide what to do, right? Again, it really depends on the customer and what they want to do.

They detect the leak. Depending on how severe the leak is, they can shut it down immediately. Some customers, they want to shut down the entire rack, right?

But with the switches, again, the customers that we're talking to, they say, "No, not really. " Because maybe it's leaking a little bit. It really depends on how much you're leaking.

If it's a little bit, they can just fix it and don't shut down the whole rack, right? Because you have- Leaking a little bit is still leaking. Yeah.

It's hard to- No, bust out your duct tape and... Don't let the magic smoke out. Yeah.

It stops working. Yeah. So we'll see.

Again, we're in this game, we're experimenting, and we will see what the outcome would be. But yeah. I don't know.

Did he answer your question? Were you asking how watertight the- Like how the- ... the base of the chassis is?

Because that- Yeah ... that's kind of what I'm asking too. IP25.

Okay, so you have some sort of certification, right? So- Yeah. So are you talking about what liquid we use inside?

No, no. We're asking how watertight the actual chassis is to prevent it, if there is a leak that's severe enough to- Yeah ... spill out of the chassis or gain enough liquid in there to actually potentially leak out.

And the first thing you can do, you can actually pull it out. As soon as you pull it out, you disconnect the liquids from the manifold, so you shut it off, but I don't know if it would leak out. I haven't seen anything leak out.

I hear pretty crazy stories. Oh. But not on the switch side.

I think this is something that we'll just need to watch as systems age. Yeah. Right?

Because that corrosion- Yep ... and people bumping into things in the data center over time, it does happen. I'm sure there are safeguards that are being engineered in, maybe a little more robust than the drip pan underneath your- Hot water ...

the air handlers in your- Underneath your house. But... Yeah.

Exciting times. Okay. Next ASIC I want to talk about is the P200 ASIC, and this is where we get into basically integrated encryption in all ports.

This is also 64 ports of 800G port, and this is truly remarkable. There is nothing like this in the market. 2T.

Right? You get 64 800G ports, and you also have high Radix, you get 512 100G ports if you do the breakout. This one has 144 megabytes of on-die packet buffer.

In addition to that, you have 16 gigabits of HBM deep memory. And like I said, it's a virtual architecture for queuing, and we support some of the load balancings that are relevant to this as well. So what we call-- I hear Rakesh from our Cisco say this is a switching efficiency with router feature set, because it's truly true.

Now- Rakesh Dubey? Rakesh Chopra. Okay.

Thank you. Yes. There are a lot of Rakeshs.

Now, if you take a look at the architecture or what's inside this ASIC, again, you still have 16 slices. The same architecture for Silicon 186, but now, as the packets come into the traffic manager, if you guys are familiar with Nexus 7K, it's the same view queue architecture. " Output queue says, "Sure, send it over," and then we'll send the packet through the crossbar to the egress slice.

Again, this is where we do, if you need to do egress replication, we do it. We read it from the memory and put it back to the egress slice. Again, this is where you do your egress modification.

If you need to rewrite the packet header, we'll do it in the egress slice MPU. Now, what is unique about this architecture? You see here I have something called HCAM, and I'll talk to you a little bit of what HCAM is, because it's truly unique to this architecture.

In fact, the other platform, and I'll talk to you about, the 9300-SE1. If you look at the data sheet, you'll see that that platform supports 132K ingress and egress access lists, which is a lot bigger than what you usually see with a data center class of switches, right? So how we do it, we do it with HCAM, which is a combination of TCAM and SRAM, which we call it TILEs.

So TCAM is expensive. It takes a lot of space in the ASIC, and we're always limited to how many TCAMs we can have in the package. They're key-based and variant mask, and they take a lot of power.

Whereas TILEs, they're not as much power heavy, but they have a hash-based full mask, and the combination of these two, it gives us a big scale that we need for classification. And with the P200, we have-Every single slice has a 6K ingress TCAM and 4K egress TCAM. But in addition to TCAM, we also have 48K ingress SRAM or tiles, as well as 16K egress tiles as well.

Per slice, you have 16 of them. Okay. Faraz, quick question for you.

On the slices, so what do those solve for? What is the purpose of the slices? Yeah, that's a great question.

Is it like a core? Is it analogous to a core? Similar, yes.

Okay. But, let's say you have... What was a good example here, right?

So I'm saying if each slice has 6K ingress TCAM, right? So if you distribute your access lists, for example, to different slices, you can scale it much higher, right? Okay.

Right? So this is per slice. But let's say you have a layer two configuration, and you have the trunk ports or access ports on every single slice, and you put the access lists into the SVI, then you have to program that access lists in the hardware for every single slice.

But if you separate it, you can scale it better. I see. In some other use cases, like for example if you have a cloud scale ASIC, and you have a dedicated packet buffer per slice, then you have to-- If you're designing it, you can go back and see how much packet buffer is available for that dedicated slice, for example.

But with this one, you don't need to worry about that part. You're just getting the benefit of having slices, right? So is it kind of like pipeline virtualization?

Like, you can just cut the pipeline up into different slices? Kind of, in the sense that you're increasing your scale, but you're not really giving up anything because the packet buffer is mainly shared for everybody. Okay.

Thank you. Now, you don't have a full scale across story, unless you have the optics to support it too. And we also have our coherent optics, which is 100% vertically integrated.

We developed their photonics inside house, and they really come handy with these 800 gig scale. We have two form factor, OSFP and QSFP, and you can reach up to 1,000 kilometers and higher. And the power budget for these coherent optics, it's actually pretty good.

This is 30 watt for the ZR+ at 800 gig, and a little bit lower, 28 watt, for ZR optic. And our platforms, the P200 platforms, the ones that we created for scale across, they can handle these in multiple ports. Usually, expectation is in the data center, you don't have to put them everywhere.

You probably need handful of them, but the platforms can support all of it, right? And if we want to take a look, see the ZR coherent optics. Yes.

Basically, you couldn't load a whole switch up with those because of the power, right? Well, you can with these. Okay.

Yeah, because this is a Nexus box, but we have the same box in the Cisco 8000, right? And for those service provider customers, sometimes they want to utilize all the ports for a long reach, right? So we've encountered that.

So we have two boxes with the P200 switches. We call the SP2R. There's a -Q and there's a -O.

-Q, we prioritize it for ACI spine, and then we'll prioritize the OSFP version for NX-OS. Okay? And they both support both of these optics that I just passed by.

If you take a look at the architecture, again, we support MACsec, but it's integrated into the ASIC, so there is no MACsec fire or anything like that on the platform, so everything directly connects to front panel ports. Okay? Now, this is a good example that goes back to talk about sustainability and what we have in mind when we're building these platforms.

6 terabits of forwarding, you need to have a modular chassis with four line cards. Of course, if you have line cards, you have to have fabric modules. And if you want to have MACsec supporting any line cards, you have to have MACsec PHYs.

So the system like that would end up having 92 ASICs. Mm. Okay?

Come to 2025. Last year, we were able to do it with a single ASIC, that single P200 ASIC that will pass it out. And you can see the difference between the numbers whenever it shows up.

It will show up. There you go. Very dramatic.

When it scale across, then it came out here. Took a long time. That's good.

So single ASIC, you can see- Deep buffers. Yeah. Deep buffers.

Okay. Now, speaking of modular chassis, not to spend too much time here, but I want to talk about the latest line card that we added to the portfolio, and that one is the 36 800 gig port line card. This one, the SP2R, and we'll take a look at that.

So this line card, it comes with two P200 ASICs, two of those P200s, whenever it shows up. A little bit delay, but that's okay. 4 terabits of back-end connectivity.

Again, you have line rate MACsec in all the ports because they're integrated into the ASIC, and each ASIC has, again, 144 megabytes of on-die packet buffer with 16 gigabytes of off-die. And you will need to have a newer version of fabric modules for these line cards because we have to have 130 lanes in the back as well. If we take a look at the architecture, again, relatively straightforward.

You have two P200 ASICs. Remember, P200 ASIC has 16 slices. Here, because we're not utilizing all the bandwidth of the ASIC, you have eight slices connected to the back-end fabric modules and six of them for front panel connectivity.

Okay? And this one shows the connectivity to the fabric modules. 8 terabit going to each fabric module.

Okay? Now, to sum it all up for the scale across story, again, we have the ASIC, we have the platform, we have the software, we have NX-OS, you can have SONiC, and if you want to use 8K, you can have open community SONiC as well. Plus our own optics that, again, it goes across.

One second. There you go. Okay.

Now, I have seven minutes. I'm going to talk a little bit about N19100 and the integration with Spectrum ASICs. Spectrum ASICs, well-known.

You have V2 version, and we built platform with two of them, Spectrum-4 and Spectrum-6. Spectrum-4 is equivalent to our G200 ASIC. 2 terabit of bandwidth.

You have 64 800G ports. But now you have only 256 max, so you can do breakout in half of the ports if you want to do 8 by 100. So you can get maximum of 256 ports.

One thing that's cool about Spectrum ASIC family is you can see in their data sheet as well, they have this flexible entries, the half a million flexible entries that it could be re-carved to different use cases. For example, you can allocate a lot to the MAC address table or access list table. And that's why if you look at Nvidia's data sheets, they have different routing profiles they can support with these.

Same with Spectrum-6. Spectrum-6 is twice as bandwidth. 2 terabit ASIC as well.

This one comes with 128 800G ports and 256 400G ports. And with the 512 max, they can get up to 512 interfaces. 6 terabit optics, you do 2 by 800G breakout.

Okay? So what we built with these, we have two platform. 2 terabit.

We call it N19164E-SNS4, that's Nvidia Spectrum-4. And this one also supports both NX-OS and SONiC. 6 terabit cages and also which is 128 800G ports, and that one is also 100% liquid-cooled.

Now, that one, the Spectrum switch, the liquid-cooled one, will be fitting into the MGX rack because it's more in line with Nvidia. 6 terabit switch would be standard for OR V3 rack. So we have both of them.

And of course, we have air-cooled version too. Now, real quick, I know this is probably repeated information for most of you, but SpectrumX adaptive routing integration, we do send-- Super NIC sends traffic. On the fabric side, we'll do a packet spray.

And like you said, when the NIC receives those packets, we reorder them or we do direct memory placement. So this is how SpectrumX adaptive routing is working. The reason why I brought it up, because you can choose to do SpectrumX solution or integrated end-to-end solution with the N9300 switches based on Cisco Silicon G200 or G300, or you can do it with N9100 platforms, which includes Nvidia Spectrum ASIC and end-to-end Nvidia solution.

So what does the customer get using the 9100 versus the 9300? So like what Richard mentioned, right? So we're looking at it as a fully integrated solution.

Mm-hmm. So if you have CCI engineers that are familiar with- To be able to talk to the NIC. Yeah.

I'm sorry? You need the SpectrumX to be able to talk to the BlueField NICs, the Nvidia BlueFields. You need the SpectrumX license if you want to do it on the N9300 series, which would enable the same behavior.

You don't require the- This one would recognize it by default, yeah. There is no license required. Mm-hmm.

So it's expensive to maintain similar products that have overlapping functionality? Yeah. I'll let PM answer that.

Not really. Again, we built platforms with both our A6 and merchant silicon before with Broadcom, and we're able to manage both of them. Not implying that you're not able to.

Yeah. Right? But it's another SKU.

It does cost more money. It costs more money than just one product line- That's true ... for a given function.

Yeah, of course. So you're making the decision to give customers choice? What?

Exactly. So there are three silicons out there, and we give a customer choice of with two of them. Yep.

Right. So just to sum it up, I only have one minute. If I want to sum up those two key elements, the optics and silicons into Nexus 1, we have our scale-out portfolio.

The blue ones are 800G based on 100G SerDes. 6 terabit interfaces. And we also have our scale-across platforms.

Both are 800G. And yeah, that's the AI platforms in a nutshell.