Bhaskar Sunkara grew up in Delhi, India, and moved to the states when he started working. He has lived in San Fransisco for several decades now, and has spent a lot of his professional life building systems (infrastructure, observability and now, analytics). His prior startup, AppDynamics, was eventually acquired by Cisco. In general, he stays curious about how things work, and likes to deconstruct systems to figure out how they work. Outside of tech, he is a big sports fan, enjoying football, baseball, cricket and basketball. In fact, he grew up watching Michael Jordan and the bulls.

Bhaskar noticed that business teams were drowning in dashboards, and as such, were not sure how to take the next steps in the business. He and his team realized that what people needed was not a retroactive view, but a proactive one - something more akin to a 24x7 analyst.

This is the creation story of Bicycle AI.

Sponsors

• Unblocked
• TECH Domains
• Mezmo
• Braingrid.ai

Links

• https://bicycle.ai/
• https://www.linkedin.com/in/bhaskarsunkara/

Irina Nazarova grew up in Russia, and has lived in Portugal, Turkey, and now, San Francisco. She got a computer science degree, but felt like an imposter in the dev world. She went on to get an economics degree, and went to work for JP Morgan. Feeling little reward from her work, she read the lean startup and jumped out to build her own, and eventually joined Evil Martians. Outside of tech, she is a person who loves hiking, traveling, and old school film and photography. She enjoys working with old film, where there is high touch, and you have a limited number of takes.

Irina is the CEO of Evil Martians, a well known design and engineering consultancy. During the time of the company, she and the team noticed that websocket solutions don't guarantee delivery. They decided to build a new solution, one that does guarantee delivery, through automatic recovery of messages during connection issues.

This is the creation story of AnyCable by Evil Martians.

Sponsors

• Unblocked
• TECH Domains
• Mezmo
• Braingrid.ai

Links

• https://anycable.io/
• https://evilmartians.com/
• https://www.linkedin.com/in/nonconstant/

Ramiro Roballos grew up in Buenos Aires, and 6 or 7 years ago, moved to Miami and now lives in Buffalo, NY. His path to entrepreneurship has been different, as he started out as a musician, and then an orchestra conductor for several years. He eventually got into building how companies, starting his own music school and his own orchestra. Eventually, he got his MBA, worked for McKinsey and some startups before doing his own. Outside of tech, he is married to a cellist, and keeps playing music for fun. He also enjoys Formula 1, and watches every change he gets.

Ramiro went through the immigration process in the US, and was very disappointed in the quality of the service, given the importance of this process in determining a pillar life outcome. He felt there should be a better way, one that has excellent service and quality, and centralizes the expansive process into one platform.

This is the creation story of Tukki.

Sponsors

• Unblocked
• TECH Domains
• Mezmo
• Braingrid.ai

Links

• https://tukki.ai/
• https://www.linkedin.com/in/ramiro-roballos/

Today, we are dropping another episode in our series The AI Control Loop, How enterprises govern the AI they've already deployed - sponsored by our friends at Wallarm.

Wallarm is the AI Control Platform for Enterprise AI, protecting every AI workload, API, and application in production, giving CISOs the governance they need and CIOs the speed they demand. Organizations choose Wallarm for a complete inventory of APIs, AI agents, and AI apps, patented AI/ML-based threat detection and blocking that operates at production traffic speeds.

In today's episode, Craig Thomas, Sr. Solutions Engineer at Wallarm, returns to the show to dive into why runtime behavior is the critical blind spot, and what CISOs should demand if they want to move from policy to control.

Questions

• Security teams are used to detecting incidents and responding after the fact. Why is that model becoming insufficient for AI-driven systems?
• Building on that, when we talk about response today, enforcement often means actions like restarting pods, rotating credentials, or shutting down services. Why can those measures come too late in an AI environment?
• So if traditional response isn't enough, why does AI behavior require controls that operate much closer to runtime?
• And when people hear "runtime enforcement," they may think of existing security controls. What changes when enforcement happens at the kernel level rather than only at the network, identity, or application layer?
• Can you make that tangible for us? What does it actually mean to revoke or contain a compromised AI session without disrupting the broader deployment?
• How does that kind of real-time containment change the risk equation for AI agents that have access to sensitive data, external services, or production workflows?
• With that in mind, what are some examples of AI behaviors that organizations should be able to stop immediately?
• Of course, security teams also don't want to become a bottleneck. How do organizations balance strong enforcement with the need to keep AI development and deployment moving quickly?
• And once organizations have the ability to discover, observe, and enforce AI behavior in real time, how does that change accountability at the enterprise level? What does good governance look like from there?

Links

• https://www.wallarm.com/
• https://www.linkedin.com/in/cu-craigthomas/

Full Abstract

This episode examines what is actually missing in AI security today. Craig Thomas, Sr. Solutions Engineer at Wallarm, dives into why runtime behavior is the critical blind spot, and what CISOs should demand if they want to move from policy to control.

CIOs and CISOs have moved past debating whether AI security matters. The question now is what to actually do about it, and most organizations are finding that their existing tools answer a different question than the one AI is asking.

Traditional security tools were built around access: who can reach a system, what credentials they present, what traffic looks like at the perimeter. AI shifts the problem to execution: what a system does once it has access, whether that behavior matches what the business intended, and how you know when it doesn't. Most current tooling has no answer for that. It can tell you what is deployed and what is configured. It cannot tell you what your AI is actually doing at runtime, on whose behalf, or whether any of it violates the policies you thought were in place.

That gap is where most AI security programs stall. There is no shortage of governance frameworks, compliance checklists, and vendor claims. What is missing is operational control: the ability to see AI behavior as it happens, enforce policy at runtime, and produce evidence that holds up when an auditor or a board asks for it. The four capabilities that define a closed AI control loop, discover, observe, enforce, govern, are well understood as a category. Getting all four working together in production is where the real work begins.

John Wright grew up in Arkansas, when his family moved from Wisconsin for his Dad's job. He was influenced heavy by his father, who became an entrepreneur with several successful exits. As a kid, he got to see the ups and downs, and how you ride the roller coaster of being a business owner. Outside of tech, he is an active sailor and certified instructor in yacht racing.

Growing up with a family of wood workers, he also likes to build things and make stuff with his hands. Finally, he lives in sobriety and recovery from past addiction, and is active in this community of people.

In the past, John and his team built a platform around email, which they sold in 2001 to a company that is now apart of Google. Post that, he started to noticed the proliferation of SMS in the messaging world, in similar patterns as to what email did - and they decided to build a platform to serve the enterprise in this capacity.

This is the creation story of TrueDialog.

Sponsors

• Unblocked
• TECH Domains
• Mezmo
• Braingrid.ai

Links

• https://www.truedialog.com/
• https://www.linkedin.com/in/johnnwright/

Ajay Kulkarni grew up in tech, as his father was a tech entrepreneur selling PC's in the early 80's. He went to college in MIT, and eventually founded a startup that was acquired by GroupMe (while it was being acquired by Skype... while they were being acquired by Microsoft). He's always been attracted to building things, so startups are right up his alley. Outside of tech, he is married with 2 young kids. He is a big exercise guy... he loves to run, swim and track his steps. Additionally, he loves music - to listen, and to play guitar, piano and drums.

Ajay and his co-founder met 30 years ago at MIT. They reconnected after years of doing their own thing, starting to dig into the iOT world. In doing this, they built a database because they the best solution to store this data... and in doing so, they unlocked their next venture out of this necessity.

This is the creation story of Tiger Data.

Sponsors

• Unblocked
• TECH Domains
• Mezmo
• Braingrid.ai

Links

• https://www.tigerdata.com/
• https://www.linkedin.com/in/ajaykulkarni/

Today, we are dropping another episode in our series The AI Control Loop, How enterprises govern the AI they've already deployed - sponsored by our friends at Wallarm.

Wallarm is the AI Control Platform for Enterprise AI, protecting every AI workload, API, and application in production, giving CISOs the governance they need and CIOs the speed they demand. Organizations choose Wallarm for a complete inventory of APIs, AI agents, and AI apps, patented AI/ML-based threat detection and blocking that operates at production traffic speeds.

In his follow up appearance on the Code Story podcast, Tim Ebbers, Field CTO at Wallarm, discusses why detection alone is insufficient for AI-driven systems, what real enforcement looks like at the runtime level, and what accountability becomes possible once all four stages are in place.

Questions

• Security teams are used to detecting incidents and responding after the fact. Why is that model insufficient for AI-driven systems?
• What does “enforcement” usually mean today, and why can actions like restarting pods or rotating credentials come too late?
• Why does AI behavior require controls that operate closer to runtime?
• What changes when enforcement happens at the kernel level rather than only at the network, identity, or application layer?
• Can you explain what it means to revoke or contain a compromised AI session without touching the broader deployment?
• How does real-time blocking change the risk equation for AI agents that access sensitive data, external services, or production workflows?
• What kinds of AI behaviors should organizations be able to stop immediately?
• How do teams balance strong enforcement with the need to avoid slowing down AI development and deployment?
• Once organizations can discover, observe, and enforce AI behavior, what does accountability look like at the enterprise level?

Links

• https://www.wallarm.com/
• https://www.linkedin.com/in/tebbers/

Full Abstract

Tim Ebbers, Field CTO at Wallarm, discusses why detection alone is insufficient for AI-driven systems, what real enforcement looks like at the runtime level, and what accountability becomes possible once all four stages are in place.

Detection tells you what happened. It does not stop it. For most security incidents, that tradeoff is manageable. For AI systems that can access sensitive data, call external services, and trigger downstream actions at machine speed, the gap between detection and response is where the damage happens.

The enforcement model most security teams operate today was built for a slower threat. Restarting pods, rotating credentials, and updating policies are all responses to something that has already occurred. Against an AI agent that can exfiltrate data, invoke a production workflow, or violate a compliance boundary in the time it takes to page an on-call engineer, that response model is not enforcement. It’s cleanup.

Closing that gap requires controls that operate at the layer where AI behavior actually executes, not at the perimeter, not at the identity layer, not at the application boundary. Kernel-level enforcement changes what is possible: a compromised session can be revoked by user identity or trace ID, connections can be terminated at the workload level, and enforcement can happen without a pod restart, a deploy cycle, or any impact to the broader environment. That is what it means to complete the AI control loop. Discover what is running, observe what it is doing, enforce what it should not be doing, and govern with evidence that the enforcement worked. Organizations that can only do the first two are solving half the problem.