Volodymyr Sydorenko lives in London, and collects mechanical keyboards. His most unusual hobby is that he does clay sculptures of characters, or random people at times. He has 2 cats, and likes to spend time outdoors. In fact, in 3 weeks time from this recording, he will traveling to Switzerland to do the Via Ferrata. To add to all of this, he has started to write children's books and hopes to publish them someday.

Vitalii Sydorenko currently lives in Lisbon, Portugal. He is into sports, loves to hit the gym and regularly tracks his calories. Last year he started playing tennis and finds that he can't stop. He enjoy hiking, which is great in Lisbon. And in the past, he spent many years building startups, exiting, and also in venture capital

You may have noticed that Volodymyr and Vitalii have the same last name... that is because they are brothers. As kids growing up, they did a lot of boxing together, as well as cling to classic films like Back to the Future.

Fourteen years ago, Volodymyr got interesting in building solutions, and realized he could only get so far by himself... so he decided to build a team to deliver these solutions. Two years ago, Vitalii and Volodymyr started to consider all the of the shifts in the SDLC, and what that meant for the current business. Vitalii decided to bring his prior startup and VC experience and join the team.

This is the creation story of Gearheart.

Sponsors

• Unblocked
• TECH Domains
• Mezmo
• Braingrid.ai

Links

• https://gearheart.io/
• https://beyondthewow.io
• https://codestory.co/podcast/e6-jon-darbyshire-smartsuite/
• https://www.linkedin.com/in/gearheart/
• https://www.linkedin.com/in/vitalii-sydorenko-%F0%9F%92%AA%F0%9F%87%BA%F0%9F%87%A6-24b4ba35/

Tim Lidman lives in Denver, CO. He has had an unconventional path to being a Tech CEO. In fact, He moved from London to Sweden when he was 18... to try to be a heavy metal rock star, trying to make it big as a drummer. To earn extra income, he got into tech sales - which went really well. Eventually, he worked with WebEx (around the time it got bought by Cisco), for Success Factors (when they got bought by SAP), and then eventually, doing his own startup (which eventually got bought by Accenture). Outside of his professional life, he is married with 2 girls. From his music years, he extracts skills that drove his success to date, which is the ability to product development and execution down the same way you do music.

In the days of his first startup, Tim's solution was used by consulting firms to power client engagement. Post exit, while overseeing things at Accenture, he noticed that the whole industry was powered by Microsoft files (PowerPoint, Excel, Word, etc.) - IE, driven manually. He started to wonder if he could codify the consulting process, to remove the manual burden.

This is the creation story of Clyde.

Sponsors

• Unblocked
• TECH Domains
• Mezmo
• Braingrid.ai

Links

• https://meetclyde.com/
• https://www.linkedin.com/in/timlidman/

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.

We all know that you can't secure what you can't see, which is why AI discovery is a first principle for AI security, but what's really required for AI discovery? It's more than just LLMs and agents. Today's episode is entitled AI Discovery isn't just AI, and joining us is Tim Ebbers, Field CTO at Wallarm. Tim and I discuss the real requirements for AI discovery, and why the connections between assets and infrastructure are part of the puzzle.

Questions

• Security teams often say, “You can’t secure what you can’t see.” In the context of AI, what exactly do they need to see?
• What supporting infrastructure matters most when mapping AI risk, such as APIs, cloud services, Kubernetes workloads, data stores, identities, and external integrations?
• Where does shadow AI typically appear first inside an enterprise environment? How can it be prevented?
• How do relationships between assets change the risk picture? For example, why does it matter which API an agent can call or which data source a workflow can reach?
• What makes AI discovery harder than traditional application or cloud asset discovery? What are the similarities and differences?
• How should organizations prioritize what they find? Is every AI asset equally risky?
• What does “continuous discovery” mean in a world where AI services can be deployed, connected, or changed in minutes?
• Once an organization has visibility into its AI footprint, what’s next? What are the biggest gaps in today’s AI security programs?

Links

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

Full Abstract

Most security teams know that you can't secure what you can't see. In the context of AI, that rule turns out to be a lot harder to satisfy than it sounds.

AI discovery isn't just a matter of cataloging your LLMs and agents. The real picture includes the APIs those agents call, the data sources they reach, the infrastructure they run on, and all the AI that got deployed without anyone telling security. Building that picture requires understanding relationships, not just inventories, because risk doesn't live in assets in isolation. It lives in what those assets can do together.

In this episode, Tim Ebbers, Field CTO at Wallarm, examines what a complete AI control loop actually requires at the discovery stage: what needs to be visible, why the connections between assets change the risk calculation, where shadow AI tends to appear first and how it becomes unmanaged risk, and what makes AI discovery structurally different from traditional cloud or application discovery. It also looks at what organizations should do once discovery is in place, and where the biggest gaps remain in AI security programs today.

If your team is building toward continuous AI governance, this is where that work starts.

Gregory M. Kurtzer is a veteran open-source pioneer, technologist, and entrepreneur with over 25 years of experience in high-performance computing (HPC) and large-scale enterprise infrastructure. He first gained widespread industry prominence as the co-founder of CentOS Linux, which grew into one of the world's most ubiquitous enterprise operating systems, and he later created other foundational open-source projects like the Warewulf cluster management toolkit and the Singularity (now Apptainer) container system.

In 2020, Gregory founded his current venture, with the goal of modernizing infrastructure stacks for the cloud and AI era. He and his team recognized that traditional enterprise infrastructure was too fragmented and ill equipped to handle the next generation of data intensive computing.

This is the creation story of CIQ.

Sponsors

• Unblocked
• TECH Domains
• Mezmo
• Braingrid.ai

Links

• https://ciq.com/
• https://rockylinux.org/
• https://www.linkedin.com/in/gmkurtzer/

Today, we are continuing our series, entitled Developer Chats - hearing from the large scale system builders themselves.

In this episode, we are talking with Pavel Shchekotov, Founding Engineer of specializing in voice-first, conversational AI products. Pavel is going to take us through his experience as an agency founder, leading into building voice driven, consumer AI.

Questions

• Today you're building AI-native consumer products around conversational interfaces and user engagement. How has that journey shaped the way you think about product engineering?
• What did those agency years teach you about product development that most engineers never learn?
• What convinced you that voice could be the primary interface rather than just another feature?
• What are the hardest engineering and product challenges that emerge when conversation itself becomes the product?
• What’s one problem that seemed trivial on paper but became surprisingly difficult at scale?
• What did you learn about technology adoption, trust, and user behavior from building for a demographic that much of the tech industry tends to ignore?
• How do you decide whether a startup problem should be fixed, optimized, or completely reimagined?
• What does being a Founding Engineer actually look like day-to-day, and how is it different from being a senior software engineer?
• Where do you think people are overestimating AI today, and where are they still underestimating it?
• Looking forward three to five years, what do you think the most important category of AI-native consumer product will be—and what capabilities will those products need that don’t exist yet?

Sponsors

• Unblocked
• TECH Domains
• Mezmo
• Braingrid.ai

Links

• https://www.linkedin.com/in/pavel-shchekotov/

Sushma Vadlamannati is originally from India, and moved to the states over 25 year ago to pursue her bachelors in at Texas Women's University. She comes from a nontraditional founder background, spending 15 years in the Fortune 100 companies, leading large programs with large budgets. About 5 years ago, she started advising startups and angel investing, which led her into the startup world. Outside of tech, she has 2 daughters and loves to do arts and crafts. In fact, she uses scrap material she finds at home to build miniature scenes and creations.

Sushma is very familiar with the startup scene in Texas. As such, she has a keen understanding of the recurring problems for startups - the local talent pool. In addition to this, she noticed the disconnect between schools, workforce opportunities, and students/workers themselves. She decided to pivot into to building this intelligence layer.

This is the creation story of zScale.

Sponsors

• Unblocked
• TECH Domains
• Mezmo
• Braingrid.ai

Links

• https://zscalecapital.com/
• https://www.linkedin.com/in/sushma-vad/

Today, we are kicking off a new series entitled 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.

Today's episode is entitled AI Security is API Security, and joining us is Tim Erlin, VP of Product Marketing at Wallarm. We discuss the foundational link between AI security and API security, digging into the role that APIs play in the dev, deployment, and operations of AI. We explore how they contribute to the risk profile of AI transformation projects, and how securing APIs is critical for successful AI transformation.

Questions

• When people hear “AI security,” they often think first about models, prompts, or training data. Why do you argue that AI security starts with APIs?
• Where do you see organizations underestimating API risk as they move AI projects from pilot to production?
• How does the rise of AI agents change the stakes for API security compared with traditional application architectures?
• What are the most common API security assumptions that break down once AI systems begin taking action autonomously?
• Wallarm’s ThreatStats research points to APIs as a major overlap point for AI vulnerabilities and exploited vulnerabilities. What does that tell us about where attackers are likely to focus?
• How should security leaders think differently about authentication, authorization, and API abuse when the “user” may be an AI agent rather than a human?
• What is one practical step teams can take today to strengthen API security before AI adoption expands further?
• Once you accept that AI security depends on APIs, what do organizations actually need to discover before they can protect it?

Links

• https://www.wallarm.com/
• https://www.linkedin.com/in/tim-erlin/

Full Abstract

In the first episode of the AI Control Loop series, Tim Erlin, VP Product at Wallarm, examines why AI security and API security are the same problem approached from different angles, and what organizations need to discover before they can protect either one.

Every AI model needs data to act on. Every AI agent needs services to call. Every AI workflow needs integrations to function. The connective tissue running through all of it is APIs, which means the security posture of any AI system is inseparable from the security posture of the APIs underneath it.

That link is not theoretical. APIs are already the most targeted attack surface in enterprise environments, and AI is making that problem significantly larger. Agents that act autonomously on behalf of users do not just consume APIs the way traditional applications do. They discover them, invoke them dynamically, chain them across workflows, and do all of it at a speed and scale that makes human review impractical. The authentication assumptions, rate limiting strategies, and abuse detection models that worked for human-driven API traffic were not designed for this, and the gaps are not subtle.

Most organizations moving AI from pilot to production are underestimating how much of their AI risk surface is actually API risk surface. Shadow APIs that were never inventoried, overpermissioned integrations that made sense for a human user but not for an autonomous agent, authentication patterns that cannot distinguish a legitimate AI session from an abused one. Securing AI at the foundational level means answering the API question first: what APIs does the AI touch, what can it do through them, and what would an attacker be able to reach if any part of that surface were compromised.