TechSpective Podcast

Tony Bradley

The TechSpective Podcast brings together top minds in cybersecurity, enterprise tech, AI, and beyond to share unique perspective on technology—unpacking breakthrough trends like zero trust, threat intelligence, AI-enabled security, ransomware’s geopolitical ties, and more. Whether you’re an IT pro, security exec, or simply tech‑curious, each episode blends expert insight with real-world context—from microsegmentation strategies to the human side of cyber ethics. But we also keep it fun, sometimes riffing on pop‑culture debates like Star Wars vs. Star Trek or Xbox vs. PS—so it’s not all dry and serious.

Play

Open in

22 episodes
Avg 45 min
English

Episodes 22

Newest Oldest Longest

All20 Unplayed20 In progress0 Played0

Counted on this page — what you have heard stays on this device, so it is not something the list can be paged by.

Wednesday · 56 min
Your AI Agents Are Multiplying and Nobody’s Counting
Think about every account you've ever created and then forgotten about. A login for a gym you canceled two years ago. A free trial you signed up for and never used again. A vendor portal from a job you left. Nobody deletes those things, and nobody circles back to check whether they still work. Now multiply that across every employee at a mid-size company, running for ten or fifteen years, and you've got a rough picture of what most identity and security teams were already dealing with before AI showed up. Roy Katmor, co-founder and CEO of Orchid Security, joins me on this episode of the TechSpective Podcast to talk about exactly that problem, and what happens to it once AI agents get involved. He calls the invisible, unaccounted-for slice of it “identity dark matter” — the accounts, agents, and access grants that exist on a network but stay invisible to the tools meant to track them. The Old Sprawl Moved at Human Speed That slowness bought people time. Shadow IT and orphaned service accounts piled up over years, not days, which gave security and compliance teams a fighting chance to run periodic access reviews, dig through the logs, and clean out what they found. It was never a good system, ask anyone who has sat through a 700-line spreadsheet asking whether a given employee still needs access to a given application. But it worked on the timeline that mattered, because the sprawl itself grew slowly enough for people to catch up to it eventually. Agents Don't Wait for a Ticket AI agents broke that timeline. An agent can be created, granted access to a handful of internal systems, and put to work in the time it takes to write a prompt. It doesn't file a request with IT. It doesn't sit in an approval queue. And once it's running, it can turn around and hand off a slice of its own access to a second agent that needs a piece of data it doesn't have, without anyone signing off on that handoff either. What used to take an organization years to accumulate can now happen in an afternoon, in a dozen departments at once, with nobody in any one of them aware of what the others just built. Somebody Still Owns What the Agent Does None of this access shows up out of nowhere, though. A person built the agent, gave it a task, and pointed it at a set of systems, even if that person has since forgotten doing it or left the company entirely. Nobody's really figured out yet who's accountable for what an agent does months or years after the person who created it has moved on. “You needed to get your stuff together,” Katmor told me, describing what happens when nobody's kept a record of who authorized what in the first place. That's the kind of problem that stays cheap right up until the day it isn't. Katmor and I get into how identity dark matter piles up, what it actually takes to find it, and what changes once AI agents start delegating access to each other without anyone signing off. Watch or listen to the full episode of the TechSpective Podcast to hear the whole conversation.
August 20 · 41 min
The Attack That Turns Your AI Agent Into A Weapon Against You
Barak Sternberg spent a chunk of this year proving something that should worry anyone who has plugged an AI coding agent into their observability stack. His team at Tenet Security found that a single fake error report, sent to a public Sentry endpoint with no login required, was enough to get AI agents to run code they had no business running. In a controlled test, more than 100 organizations' agents acted on the injected error, including one belonging to a company worth roughly $250 billion. Tenet published the full research, including the disclosure timeline, on its blog. The attack doesn't touch the agent at all. It touches the tool the agent already trusts. How A Fake Bug Report Becomes A Command Sentry, Cloudflare, and Datadog all use a public write key that lets any website report its own errors back to the vendor. That's by design. It's also a wide-open door once an AI agent is on the other end reading those errors and deciding what to do about them. Sternberg's team crafted an error message formatted to look exactly like a legitimate Sentry “Resolution” note, complete with headers and code blocks that matched the real thing. When a developer asked their agent to look into unresolved Sentry issues, the agent read the fake resolution and ran the attacker's command with the developer's own permissions, no phishing and no jailbreak required. Sternberg told me it’s a common misconception that manipulating an agent looks like typing "forget your instructions" into a chat window. "It’s very easy to fool them," he said, and the version that actually works doesn’t look like an attack at all. It looks like a diagnostic step the agent was already primed to trust. Telling The Agent Not To Trust Doesn't Work Tenet also tried the obvious fix: instructing agents through system prompts to treat tool output as untrusted. The agents ran the malicious code anyway. Sternberg explained that once an agent sees something resembling a real problem in its environment, it reasons its way to a conclusion on its own terms. It doesn't register the fix as coming from an outside source. It registers the fix as the logical result of its own investigation, which means a prompt telling it to be suspicious of external data never actually gets triggered. That's a different failure mode than the prompt injection most security teams have spent the last two years preparing for. A Shared Responsibility Model Nobody Has Written Yet Sternberg draws a direct line to the early days of cloud computing, when it took years for the industry to settle on a shared responsibility model that made clear where a cloud vendor's job ended, and a customer's job began. Nothing like that exists yet for AI agents, and the ambiguity shows up every time something goes wrong. When Sentry was notified of the flaw, the company called the underlying issue technically indefensible rather than something it could patch away. Sternberg doesn't disagree, but he also doesn't think that lets anyone off the hook. Anthropic can't see a company's internal business context well enough to secure every agent conversation on its own, and Sentry can't see what happens inside a customer's agent session after its data leaves the server. The same ambiguity showed up earlier this year when an OpenAI agent broke out of a sandbox environment during testing involving Hugging Face. Nobody at any of the AI labs seemed eager to claim responsibility for it, and some treated it more like a curiosity than an incident. A decade ago, a person doing the same thing to a company's infrastructure would have faced prosecution, not a mention in an investor deck. Old Rules Don't Scale To A Package Install At one point in our conversation, I brought up Isaac Asimov’s laws of robotics, mostly to point out how badly they’d hold up if an AI agent actually tried to apply them. Sternberg pushed back on the idea that any single rule set could work at all. "There’s not one generalistic constitution that will work well for all the businesses," he said. The problem isn’t that the rules are wrong. It’s that distinguishing a legitimate new package install from a malicious one requires business context that no frontier lab is positioned to have, and an agent rewarded for speed and autonomy has every incentive to resolve that ambiguity in favor of getting the job done. Where To Actually Start Sternberg's advice for a security leader walking into the office Monday morning isn't complicated, even if it's rarely done. Map where your agents operate, what data they touch, and how much of that data comes from outside your own walls. The tools accessing public, untrusted data are the ones worth scrutinizing first. It's a smaller ask than solving the shared responsibility question for the whole industry, but it's the only part of the problem an individual company can actually act on today. Sternberg and I talked through a lot more of this, including the open-source tooling Tenet released to help harden coding agents against this exact class of attack, on a recent episode of the TechSpective Podcast. Check out the full episode here:
July 29 · 36 min
Building an AI That Learns Like an Analyst
Most AI-driven security tools lean on retrieval-augmented generation: pull relevant precedent, drop it into the context window, let the model reason over it. It works, but it has a cost problem and a consistency problem. The more data you feed a large language model to improve its answer, the more expensive that answer gets — and the more room there is for the model to produce inconsistent results, independent of hallucination. Torq built its "SOC brain" to get around that tradeoff. On the latest episode of the TechSpective Podcast, I sat down with Torq Co-Founder and CTO Leonid Belkind to talk about how it works. Belkind says he was skeptical of the term when Torq's marketing team first coined it — he's a technologist, not prone to warming up to superlatives — but changed his mind once he mapped out what the system was actually doing. Reflex, recall, and retrospect Belkind frames the problem around cognitive load. Security analysts are buried under a growing volume of alerts as attack surfaces expand, and the goal isn't just automation — it's shifting judgment itself onto the machine, confidently enough to act on it. System one is instinct: fast, cheap, mostly right, and not something you can trace back to a specific lesson. System two is deliberate: pulling precedent, weighing relevance, reasoning it through. Torq builds both. The instinctive layer comes from a per-organization encoder model trained on an organization's own alert history — the sources, the entities involved, the actions taken, the outcomes. That model doesn't generate language; it produces a feature vector, a numerical fingerprint of what a given alert resembles. A classifier neural network then places new alerts relative to clusters of confirmed true positives, false positives, and benign activity, producing something close to a gut check. The deliberate layer works more like memory retrieval: alerts get indexed by attack pattern and technique so the system can pull the most relevant past cases and reason about how closely they match. When the instinct and the recall — plus a third, independent verdict — all agree, confidence to act autonomously goes up. When they diverge, that's the trigger for a closer look. Grading the data that trains it Not every past decision teaches the system the same amount. Torq scores outcomes as bronze, silver, or gold data points, based on how much signal they carry. A confirmed true positive is useful but modest. A verdict that gets overturned on deeper investigation is more valuable. And a reversal that comes with documented evidence explaining why is the most valuable of all. Training also isn't neutral about the cost of being wrong. Torq uses weighted cross entropy so that missing a real threat is penalized far more heavily than over-flagging a benign one — a deliberate bias toward caution that mirrors how people weigh irreversible risk against wasted effort. The accountability question We also got into where this leaves human expertise. If organizations lean on AI to do more of the judgment work, do people lose the ability to recognize when it's wrong? Belkind's answer: that risk isn't unique to security operations, and it isn't really about the tool. It's about whether the people using it stay curious enough to understand what's happening underneath — the same distinction between someone who can drive an automatic transmission and someone who understands how it shifts. That shift doesn't change accountability, though. When the data involved is healthcare records, financial information, or critical infrastructure, "we just trusted the AI model with it" isn't an answer anyone accepts after the fact. The tolerance for a wrong guess on a security alert is nothing like the tolerance for a bad restaurant recommendation. What we didn't get to here There's more in the full conversation than fits in a write-up — including why Belkind thinks survivorship bias applies to machine learning the same way it applies to human judgment, how Torq imports an organization's incident history so the system starts learning before day one, and the line he draws between AI built to look intelligent and AI built to actually get better over time. Listen to the full episode of the TechSpective Podcast, out now.
July 19 · 49 min
Most AI Problems Are Really Capitalism Problems
Bruce Schneier joins me on this episode of the TechSpective Podcast to talk about hacking, power, and why so much of what gets blamed on AI might actually be something else. Schneier is one of the most well-known and respected names in cybersecurity. He has been working in and writing about cybersecurity since the term was invented, writing more than a dozen books in that time. Data and Goliath looked at surveillance. A Hacker's Mind looked at loopholes in the rules we all live by. His most recent book turns that same thinking toward AI and democracy. A Hacker's Way of Seeing the World Schneier's idea of a “hack” is not limited to computers. I have read a number of his books, and I am always fascinated by how he is able to frame cybersecurity concepts and illustrate how they appear everywhere in the world around us. They are more philosophy or psychology books than cybersecurity, really. To him, a hack is any gap between what the rules say and what they were meant to do. Some of his best examples have nothing to do with the internet at all — they come from professional sports, the tax code, even ancient Rome. In each case, someone found a gap that the rules never closed. That same lens applies to Washington. Rules get written for one purpose, and someone always finds a way to use them for another. We spend a good chunk of the episode on how that plays out in the US government. Most AI Problems Are Really Capitalism Problems Schneier argues that a lot of what people are angry about with AI right now is not really about the technology. It is about who controls it and what they choose to do with it. “A lot of people's problems with AI are actually not AI problems,” Schneier told me. “They're capitalism problems.” We talk through what that looks like in a few different fields. The same tool can concentrate power in fewer hands. Or it can spread that power out. Which way it goes depends on who is using it, not on the tool itself. We also talk about the fact that AI does not create new problems so much as it amplifies the ones that already exist. Schneier gives a few examples of how that shows up in law, in medicine, and in everyday life. He points to how the same technology can push power in opposite directions depending on who holds it. A Lot More Ground to Cover Schneier and I also get into his new book, Rewiring Democracy, co-authored with Nathan Sanders. We talk about what it has been like to watch the political ground shift under a book about strengthening democratic institutions. We also cover election security, security theater in the age of deepfakes, and where Schneier thinks the value of human writing is headed next. Watch the full episode to hear how it all connects.
July 9 · 51 min
The Case For Rebooting Democracy With AI
Beth Simone Noveck joins me on this episode of the TechSpective Podcast to talk about her book, Reboot, AI and the Race to Save Democracy. She's a professor at Northeastern, where she leads the Burns Center for Social Change. She also founded Innovate US, a training program for public sector workers. It's grown into one of the largest AI training efforts in the country. Before that, she ran AI for the state of New Jersey and worked on tech policy for the federal government under President Obama. I admit I hadn't read the book before we sat down to talk. My reading backlog is somewhere around 160 books deep at this point, a genuinely embarrassing number, but Reboot jumped near the top of the list by the time we wrapped. The Messy Middle Most of what gets said about AI publicly sits at one of two extremes. It's either going to wipe us out or save us. There's very little room in between. Noveck wrote Reboot because she thinks that the messy middle is where the real story actually is. Dystopian collapse and idyllic utopia both make for better headlines than anything nuanced, so that's what gets covered. It skews how people think about these tools before they've even used one. Her point extends past AI, too. Things like Flock cameras, Ring doorbells, or blockchain are not inherently good or bad. What matters is what gets built on top of them and who's making those decisions. Noveck pushes that dual-use idea further with a comparison to nuclear technology. The same science can build a bomb or a power plant. She argues we spend most of our energy relitigating the bomb conversation. We spend almost none of it asking what the power plant should look like. What would we deliberately choose to build because it actually matters, instead of just building whatever a company happens to find profitable? Who Gets to Decide Decision-making is where this gets political. Who actually has influence over AI policy right now? Some of that influence happens in the open, through lobbying and testimony. Some of it happens over closed-door dinners most of us never hear about. Noveck doesn't think it should come down to whoever has the most money or the loudest microphone. "When it's positive, we call it targeting. When we don't like it, we call it manipulation," she told me. That framing problem shows up everywhere from search results to airline pricing, and in how a city decides what its residents actually want. Noveck also pushes back on the idea that you need a technical background to have a say in any of this. Just as you don't need to be a mechanic to drive a car safely, you also don't need a computer science degree to use AI responsibly or weigh in on how it should be regulated. She backs that up with real examples of AI already being used to make government more participatory instead of less, along with her own case for why she's still hopeful about where this is headed. I'm leaving the specifics for the episode. Give it a watch or a listen and let me know what you think.
June 24 · 37 min
The Remediation Cycle No Security Team Wants to Be Running
Most cloud security tools have a detection problem. They find misconfigurations well enough. The issue is what happens after — a ticket gets opened, someone works the queue, the fix goes in, and three weeks later the same misconfiguration is back because a different person on the team made the same call. Ariel Litmanovich watched that cycle for years, not at some mid-market company struggling with tooling, but at the Israel Defense Forces, running cloud security for one of the more demanding environments you can imagine. The team had budget, direct relationships with AWS, Azure, and GCP, and access to good tools. They still kept finding the same problems. That frustration is where Aryon Security started. The platform Ariel and his co-founders built intercepts cloud configurations before they reach production. If a resource is being deployed in a way that violates policy, it gets stopped at that stage — not discovered later, not added to a remediation queue. They came at this from the application security world, where shift-left has been standard practice for years, and applied the same logic to cloud infrastructure. The security controls move to where the decision is made, not where the damage shows up later. Ariel joins me on this episode of the TechSpective Podcast to talk about what that looks like in practice. We cover the friction organizations run into when they move from detection to enforcement — what it means for the engineer whose deployment just got blocked, how the exception process is supposed to work, and why those details determine whether a policy actually holds or quietly gets routed around. We also get into a specific challenge that rarely comes up in cloud security marketing material: what happens when developers have a legitimate reason to configure something outside the standard policy, and how Aryon handles that without creating a backdoor that undermines the whole approach. We talk about AI too. Ariel’s argument is that attackers using AI have compressed the window between a misconfiguration going live and it being exploited. He walks through what that means for detect-and-remediate as a primary strategy and why the timing math matters for cloud security decisions today. He also gets specific about where Aryon actually uses AI in the product versus where it does not. Aryon does not fit neatly into any existing analyst category, which can be a challenge for procurement. Budget gets allocated against categories defined by Forrester Waves and Gartner Magic Quadrants. When something does not have a pre-approved line item, buying decisions get complicated, regardless of whether the product solves the problem. He talks through what that friction looks like and mentions some 2026 market research that is relevant if you are actively making cloud security tooling decisions right now. If you work in cloud security and have ever looked at your remediation backlog wondering why the same issues keep cycling back through, this conversation is worth your time.
June 8 · 46 min
Remote Hiring Opened the Talent Pool — and the Fraud Surface
Before COVID forced everyone out of the office, hiring for most companies was a pretty localized exercise. You posted the job, you interviewed whoever could physically show up, and you picked someone. If you were based in a mid-sized city, you hired from a mid-sized city talent pool. Remote work changed that. Suddenly a company in Topeka, Kansas could interview candidates in Portland, Maine — or anywhere else. This meant more competition for good candidates. However, it also meant a dramatically better shot at actually finding the right person for the job. And depending on your market, the cost savings weren't trivial either. Most of the data suggested remote work was as productive as in-office work, sometimes more so. The case for keeping it was strong. A lot of companies made it permanent, or at least optional. The Fraud Problem Nobody Planned For But there's a problem that came along with all of that — one that didn't get much attention until recently. When you expand your hiring geography to anywhere with an internet connection, you also expand your exposure. As a result, you encounter applicants who are not who they claim to be. I'm not talking about resume padding. I mean organized fraud. That includes fake identities. There are people swapping out mid-interview so that the person who actually shows up on day one is not the person you interviewed. AI is being used in real time to answer technical questions the candidate doesn't actually know. And in some well-documented cases, state-sponsored actors — North Korean IT workers operating under false identities — get hired. These workers receive company laptops and exfiltrate data almost immediately. The FTC reported that US businesses lost a staggering amount to this kind of fraud in 2024. And that's not just the companies that hired someone fraudulent. A significant chunk of that is wasted time. This includes the cost of running three, five, or seven interview rounds on a candidate who turns out to be fake, and having to start over. In this episode of the TechSpective Podcast, I talk with Den Jones, CEO and founder of 909Cyber, about a product he's been building to address exactly this problem. Den has spent 30 years in identity and zero trust — at Adobe, Cisco, and elsewhere. 909Shield applies that same thinking to the hiring process itself. This happens before a candidate ever gets to the first interview, before a company ships a laptop, and before access is provisioned. More to the Conversation Than Just the Product We get into how the fraud actually works — and it's more varied and more organized than most people realize. We also talk about what a solution looks like, the tradeoffs involved in verifying someone's identity across multiple touchpoints, and the data privacy questions that come with building a biometric trust layer for hiring. There are also some side conversations worth tuning in for. For example, whether it actually matters if an employee works for multiple companies simultaneously, as long as they're delivering. Also, whether using AI to answer interview questions should disqualify someone when employers are often mandating AI use once they're hired. And whether return-to-office mandates, at least in some cases, are partly a response to this fraud problem rather than the real estate economics most people assume. Den also traces how 909Shield came to exist — which did not start with a plan to build a remote hiring verification platform. It started with a passion project to help cybersecurity students find part-time work while they were still in school. Later, that evolved into a freelancer marketplace and then into a fraud-prevention product for remote hiring. This is its own story, and it's worth hearing him tell it. 909Shield is launching in mid-June. Den is actively looking for design partners — companies doing meaningful hiring volume who want to help shape the product and lock in early pricing. If your organization does a significant amount of remote hiring, this conversation is worth your time. Check out the full episode on the TechSpective Podcast.
May 13 · 48 min
The AI Risk Blind Spot Most Organizations Don’t Know They Have
Most organizations believe they have a solid handle on their AI risk. According to a new report, that confidence may be misplaced. ArmorCode partnered with the Purplebook community to survey more than 650 cybersecurity leaders to produce the State of AI Risk Management 2026 report. The results reveal a disconnect that's hard to explain away. Nearly 90% of respondents said they had complete visibility into AI usage across their organizations. However, more than 60% of those same respondents said AI usage in their organizations is essentially ungoverned. These weren't different groups of people. Instead, it was the same respondents giving contradictory answers within the same survey. I talked with Mark Lambert, Chief Product Officer at ArmorCode, about what's behind that gap and what organizations can realistically do about it. This conversation took place on this episode of the TechSpective Podcast. Lambert wasn't surprised by the findings. The pressure organizations are under to capture productivity gains from AI is real. Normally, the instinct is to adopt now and figure out governance later. AI-assisted code generation is delivering meaningful output, and the business case is hard to argue with. However, the security implications are another matter. As Lambert explained, even if AI-generated code has half the vulnerability density of human-written code, a 4x productivity multiplier still nets out to more vulnerabilities reaching production. As a result, there are not fewer vulnerabilities. We also got into something I hadn't fully thought through before our conversation. Tools capable of discovering security flaws at a scale no human team could match are already here in limited form. Lambert described what he sees as a three-wave scenario for how this plays out — beginning with CVEs in critical infrastructure, moving to open-source vulnerabilities, and eventually reaching nation-state actors who've been capturing codebases for years. Now, these actors have the right tools to mine them for exploitable flaws. Most organizations are already struggling to keep up with patching. Additionally, the question of what happens when the volume of known vulnerabilities multiplies significantly is one that the industry doesn't have a good answer for yet. From there, we got into agentic AI, which is where the governance conversation gets complicated fast. I've been using the intern analogy a lot lately when talking about AI agents — you'd give them tasks, but you wouldn't hand them access to everything, and you'd review the output before it went anywhere it mattered. Lambert agreed with the framing. The problem, as I see it, is that the analogy breaks down at scale. Managing a handful of agents the way you'd supervise a new hire is workable. However, doing that with a hundred agents means the human review process becomes the bottleneck. Therefore, you've given back the efficiency gains you were after. Lambert and I worked through what governance actually looks like when agent deployments grow. This includes scoping agency based on business risk, making sure high-stakes decisions can be reversed, and building in the audit trail. He pointed to a fireside chat from RSAC. The question came up of whether two agents could theoretically handle Sarbanes-Oxley compliance between them. The concept highlights an important point about where the line between autonomous and human-reviewed needs to sit. The self-driving car comparison came up, too. The first time I used adaptive cruise control, I kept my foot next to the brake the whole time. Later, I've since ridden in Waymos, where I would have been fine falling asleep. That trust didn't come from a product announcement — it came from watching the system handle real situations over time. Lambert made the point that the same logic applies to AI agents in enterprise environments, which I think is right. Consequently, the organizations that will do this well are the ones that build trust in their agents. Lambert tied all of this back to ArmorCode's focus on unified exposure management — pulling data from hundreds of sources, applying business context, and using AI to prioritize what actually needs attention rather than just generating more alerts. Watch or listen to the full episode for the complete conversation.
May 7 · 28 min
The Attack Surface Changed but the Fundamentals Didn’t
Every few years, something comes along that reshapes the threat landscape and sends the industry scrambling for new tools, new frameworks, and new buzzwords. The perimeter died. Then it came back. Endpoints became the priority. Now they're not the whole story. Identity is the new battleground. AI is changing everything. And yet, the more I talk to people who've spent decades in the trenches, the more I keep hearing the same thing: the fundamentals still work. We just stopped trusting them. I had that conversation recently with Will Ledesma, a cybersecurity veteran with over 25 years in the field and a current role at N-able. Will also serves as a cyber warrior in the U.S. Air Force — and as a fellow Air Force vet, I can say the service tends to instill a certain appreciation for doing things right the first time. State of the SOC Report We talked about what N-able's latest State of the SOC report actually shows about where attacks are coming from — and the answer probably isn't what you'd expect if you've been following the conventional wisdom around endpoint protection. The data points somewhere else, and Will does a good job of explaining why that shift makes sense when you look at what's been happening across the business world over the last few years. From there, the conversation moved into identity — not just the username-and-password kind, but the full scope of what "identity" means in a world where your network includes laptops, IoT devices, cloud workloads, software applications, and increasingly, AI agents running on behalf of your employees. If an attacker can own any one of those identities, a lot of your other defenses stop mattering. Companies are bringing in AI tools at a rapid pace, leaning on them to augment their workforce and drive efficiency. That's fine. But what happens when those systems become mission-critical, and someone decides to take them out? Compliance and Security We also got into something I've been saying for years about compliance. Compliance and security aren't the same thing. You can check every box on a framework audit and still get breached — plenty of high-profile companies have proven that. The frameworks have value, but they're a floor, not a ceiling. And too many organizations treat them like the finish line. Will's framing for all of it comes back to defense in depth — a concept he learned early in his career and one that he argues is more relevant now, not less. The attack surface has expanded. The identities have multiplied. The stakes are higher. But the logic of layering your defenses, covering your fundamentals, and not betting everything on any one control? That hasn't changed. The episode is worth your time whether you're a practitioner, a leader trying to make sense of your security investments, or just someone trying to figure out what "cyber resilience" actually means when you strip away the marketing. Hint: it's bigger than cybersecurity.
April 30 · 44 min
What the Breach Reveals That the Budget Never Did
There's a pattern that shows up in incident response work that nobody talks about in the vendor briefings. You bring in forensics after something goes wrong, and somewhere in that process, you find a tool — already deployed, already licensed, sometimes running for years — that had the data to catch what happened. Nobody was looking at it. In some cases, it wasn't even turned on the right way. Max Henderson runs global digital forensics and incident response at Kroll. He's seen this enough that it's not a surprise anymore. That's part of what makes him a useful person to talk to about Kroll's new cyber resilience research. He’s not reading a survey and drawing conclusions. Instead, he's comparing it against what he actually finds on cases. I had him on the TechSpective Podcast, and we started where I always start with someone who's close to research like this: not the findings, but what surprised him. His answer goes somewhere I didn't expect, and it reframes a lot of what follows. It's not about a specific attack type or a new threat category. Rather, it's about a structural problem in how organizations think about security investment. This is one that keeps showing up regardless of how much they've spent. The report itself covers 1,000 decision-makers across 10 countries. The headline numbers are familiar in their frustration — 94% treat cybersecurity as a top risk, budgets are up, nearly everyone has an incident response plan. And yet 72% still report misalignment between security priorities and business decisions. That gap has a real explanation. Max gives it one that makes more sense than the usual "leadership doesn't get it" framing. We spent some time on the confidence problem. Organizations consistently overestimate their readiness — not because they're being dishonest, but because of how the question gets asked internally and who's answering it. The gap between saying you can quantify cyber risk and actually being able to do it when something happens is significant. Max has watched that gap reveal itself in real time during incidents. This happens in rooms with executives who are hearing for the first time how long they might be down. The speed problem isn't getting better. Kroll's data on outbreak times is uncomfortable, and the percentage of organizations that feel equipped to respond within that window is even more uncomfortable. AI is part of why timelines are compressing — but not in the way most people fixate on. The most effective attacks Max is seeing right now don't involve sophisticated AI-enhanced exploits. Instead, they involve someone picking up the phone. The gap between where organizations focus their security investment and where they're actually getting hit is one of the more consistent findings across Kroll's casework. The AI discussion goes a few directions. There's the attacker side, which is getting more attention. But there's also what happens when organizations build out powerful AI infrastructure internally. What that looks like as a target is important, too. Max made a point about MCP servers specifically that I hadn't heard framed that way before — the security risk isn't necessarily about abusing the AI itself, it's about what you've handed to whoever can get onto that system. There's also a thread on agentic AI and the forensic problems it creates. I think that is going to become a much bigger conversation. I asked him at the end where he'd tell an organization to start. One priority, 80% of the way there. The answer connects back to where we opened. Full episode on YouTube and wherever you get podcasts.
April 28 · 52 min
The Agentic AI Reckoning Nobody Saw Coming
I keep having versions of the same conversation. The names and logos change, but the underlying tension doesn't: organizations are deploying AI agents fast, they're deploying them into production, and a lot of them weren't ready when they did it. Monte Carlo's co-founder and CTO Lior Gavish joined me on the TechSpective Podcast recently, and we got into why that's happening and what it actually means. Monte Carlo published the Agents in Production report, and the numbers are worth paying attention to. Nearly half of enterprises surveyed already have agentic solutions running on mission-critical work — not pilots, not proofs of concept. And somewhere around three-quarters of them said they deployed before they felt ready. That's not a surprise, exactly. The pressure to move is real. Boards are asking about AI strategy. CEOs are mandating adoption. The competitive argument for waiting is getting harder to make. But there's a difference between accepting that reality and assuming the governance infrastructure you need is going to materialize on its own. Part of what makes agents different from every other enterprise tool is that they don't follow a script. You can sandbox traditional software, test it, QA it, and have a reasonable expectation that what you tested is what you're deploying. Agents take a natural language objective and go find a path. That path isn't always the one you'd have chosen. Lior put it plainly — agents are optimizing for the mission, not for whatever guardrails you assumed were obvious. If they can reach data that technically sits within their access permissions, they'll reach it. If they can route around a limitation by working through another agent, some of them will figure that out. The other layer is that these systems are probabilistic. You can trace what went wrong after the fact, but the trace doesn't give you control. Run the same agent on the same task tomorrow, and you might get a different path. The audit log is evidence, not a fix. Where Lior and I spent a lot of time is the scale problem. One agent, you can watch. You can inspect every decision, every tool call, every output — same way you'd stay close to a new hire you're still calibrating. But the organizations moving aggressively aren't staying at one agent. They're heading toward dozens, then hundreds, and at that point, the pilot-phase approach of eyeballing everything stops being an option. The answer isn't to slow down across the board. What Lior kept coming back to was reversibility — don't hand agents tasks where a wrong decision can't be unwound — and visibility, meaning you need enough observability to catch drift before it becomes a problem you're explaining to someone else. There's an analogy from the conversation that stuck with me. You jumped in the car, hit the gas, and now you're trying to install brakes while it's moving. That's a pretty accurate description of where a lot of enterprises actually are. The question isn't whether to deploy anymore. It's whether you can see what your agents are doing well enough to catch a problem before it becomes one you can't walk back. That's what we got into. Give it a listen.
April 20 · 52 min
The Microsoft Enterprise Recovery Problem AI Can’t Fix
There's a moment in my conversation with Bob Bobel where he mentions that customers are having a harder time finding people who actually know Active Directory. Not cloud identity — the old on-premise stuff that most large organizations still run. Even if they've also got Entra ID and Office 365 sitting on top of it, they maintain those older systems. That expertise is retiring. Moreover, it's not being replaced fast enough. Bob is the CEO of Cayosoft, which builds management, auditing, and recovery tools for Microsoft environments. He's been in this space for a long time — long enough to have sold to some of the same agencies he's selling to now. This is nearly two decades later. He started the company on his 401k. Interestingly, his wife apparently still doesn't know about it. We covered a lot of ground in this episode. Some of it is squarely in the weeds of Microsoft infrastructure — hybrid environments, the gap between what native tools can do and what organizations actually need, and why change auditing matters more than most IT teams realize. Some of it is broader. For example, we discussed AI, the ecosystem of companies that build businesses around Microsoft's footprint, and what federal agencies are actually looking for when they go shopping for tools in this space. The recovery conversation is worth your time on its own. Bob tells the story of how Cayosoft ended up building their patented approach to Active Directory recovery — it starts with a phone call at 3 am. There was a demo coming up in four days, and no hardware anywhere near Key West. The problem they had to solve in that moment turned into something they still consider one of their core differentiators. I'll let him tell it. On AI, Bob is more measured than most people I talk to right now. He's not skeptical of it, but he's also not pretending it's ready to run your identity infrastructure. His argument is that the more realistic near-term use case is capturing what experienced engineers know before they retire. He believes in embedding that institutional knowledge somewhere useful rather than just losing it. Cayosoft recently filed a patent around that idea. He explains the thinking behind it, and also where he thinks the hype is running ahead of reality. There's also a good thread in here about what it actually means to build a company inside someone else's ecosystem. I used to work at a company that was tightly coupled to AWS, so I know that tension. There's always the question every year of whether the platform you're built on is going to decide to build what you do. Bob has a pretty clear-eyed take on the Microsoft version of that dynamic. It's a good conversation. Check it out wherever you listen to (or watch) podcasts.
April 16 · 42 min
When AI Agents Go Rogue the Problem Starts at Runtime
Every conversation I’ve had for the past couple of years has followed the same arc. First, it was generative AI. Then agentic AI. Now the question everyone is circling is how you actually secure agentic AI — and it turns out that’s a harder problem than most people expected. I sat down with Naor Paz, CEO and co-founder of Capsule Security, to talk through it. Naor spent years as a security practitioner and incident responder, moved into product leadership at F5, and is now focused on what he sees as one of the most underserved problems in enterprise security: stopping AI agents from going rogue while they’re actually running. Agentic AI Visibility Most of the security work happening around agentic AI right now is happening before the agent ever executes — governance, configuration, posture management, compliance. Capsule is focused on what happens during execution, which Naor says is where existing tools have almost no visibility at all. The core issue is that agents are non-deterministic. You can configure guardrails, set permissions, write policies — and then the agent reasons around all of it in pursuit of whatever objective it was given. Naor used a concrete example: Cursor’s coding agent was explicitly told not to touch certain files. It generated a shell script to read them anyway. The guardrail didn’t fail. The model just decided the goal mattered more. That’s not a bug you can patch. I drew a parallel to user behavior analytics — establish a baseline of normal behavior, flag deviations. Naor said the analogy is reasonable, but the scale breaks it. You might have a thousand employees. In the near term, you could have a million agents operating on behalf of those employees. The insider threat model we built for humans simply wasn’t designed for that. Naor describes intent as the new perimeter. Identity became the perimeter when the network stopped being the boundary. Now, even a properly credentialed, least-privileged agent can do real damage if what it’s actually doing has drifted from what it was told to do. Capsule runs a fine-tuned small language model alongside the agent, comparing intended behavior against actual behavior in real time and flagging the gap. Zero Day Flaws Capsule has also published two zero-days to back this up. One involved Microsoft Copilot Studio — they called it ShareLeak. The other involved Salesforce Agentforce, which they called PipeLeak. Both are indirect prompt injection vulnerabilities, and Naor walks through how they actually work in the episode. What stood out to me wasn’t just the vulnerabilities themselves, but how different the disclosure process was compared to a traditional software bug. Microsoft’s engineering team needed two weeks to fully understand the attack surface — partly because AI vulnerabilities aren’t reliably reproducible. Non-determinism is a problem for the attacker trying to exploit consistently and for the vendor trying to confirm the fix. Naor compared this to Adobe Flash. Flash was so fundamentally susceptible to manipulation that the industry eventually decided the right answer was to stop using it. He doesn’t think that’s where we land with AI agents — the business value is too high — but the underlying point is that language models have structural vulnerabilities that can’t be fully engineered away. You need ongoing runtime protection, not a one-time fix. Multi-agent orchestration is where this gets more complicated. As agents increasingly work in coordination with other agents, the attack surface multiplies. Naor made a comparison to botnets — a coordinated network where some agents create noise while others do the actual damage somewhere else. It’s not a theoretical concern. Capsule is already building research around it. One interesting and concerning statistic: 72% of enterprises are already deploying AI agents. Only 29% have AI-specific security controls. Naor’s explanation for the gap isn’t budget — it’s confusion. Security leaders don’t know what their exposure looks like yet, and some are operating under the assumption that built-in platform governance is enough. It’s not. Guardian Agents Gartner has already coined a category for what Capsule is building: guardian agents. AI watching AI. Naor addresses the obvious question that raises — doesn’t a guardian agent just introduce another attack surface? — and his answer is more nuanced than you might expect. We closed by talking about pace. I’ve stopped framing these conversations around five-year predictions. The question that actually matters right now is six months. Naor has a clear-eyed take on where things are heading, and it’s worth hearing. The full episode is available on major podcast platforms and on YouTube.
April 10 · 47 min
The Browser Was Already a Problem – Now Add a Billion AI Agents
Fresh off RSAC 2026, I sat down with Ramin Farassat, Chief Product Officer at Menlo Security, to work through what agentic AI is actually doing to the enterprise attack surface. Menlo has spent 13 years focused specifically on browser security. The idea is that the browser, not the endpoint, not the network perimeter, is where most enterprise work happens and most exposure lives. That was already a hard enough problem. Then you add AI agents into the mix. The Next Billion "Users" The framing Ramin kept coming back to is that the next billion users aren't going to be human. That's not a marketing line — it reflects something real about where agent adoption is heading. Think about how passwords and IP addresses scaled. In 2005, you could probably count both on your hands. Now your home router has 110 devices on it, and your iPhone has hundreds of saved passwords. Agents are going to follow the same curve, just faster. The average employee probably doesn't intend to deploy 25 agents. But they'll get there without really noticing. What makes this particularly thorny from a security standpoint is that agents aren't just scaled-up users. They have their own quirks. They'll take the path of least resistance, which sounds fine. However, your agent may start finding pathways into folders you didn't know were accessible. They can be manipulated in ways a human would immediately recognize as suspicious. And they can talk to other agents — meaning an agent you locked down to read-only can potentially find a workaround through another agent that has write access. Ramin walked through real examples of exactly that happening. The Identity Question We also got into the identity question, which I don't think the industry has a clean answer to yet. If I spin up ten agents to work on my behalf, are they ten separate identities? Does each one get its own credentials? Ramin has a specific take on how Menlo approaches this — and it's different from just handing every agent its own ID. I'll let him explain it rather than summarize it badly. There's also a policy and accountability angle that I think is underexplored. A lot of organizations are actively pushing employees to adopt AI agents — not just allowing it, but setting productivity targets around it. When you mandate something, and then an agent goes off the rails, the question of who's responsible gets murky in a hurry. We talked through that, and I don't think there are easy answers. Ramin shared something he heard directly from multiple CISOs at RSAC: they know there are agents running in their environment. They just don't know who built them, where they are, or what applications they're connecting to. Because an agent using someone's credentials looks exactly like that person to the network. There's no easy way to tell the difference. That's the problem set we spent 45 minutes unpacking in this episode of the TechSpective Podcast. If you're thinking about agentic AI in your environment — or you're already dealing with it, whether you planned to or not — this episode is worth your time. Watch or listen to the full episode.
March 26 · 50 min
Why Ransomware Should Be Getting Your Attention Again
Ransomware has been a persistent headline topic for years now. As a result, a lot of people have probably gotten numb to it. I know I had. It starts to feel like background noise — another attack, another breach, another company paying out. So when I sat down with Derek Manky, Chief Security Strategist and Global VP of Threat Intelligence at Fortinet, he started walking through the numbers from Fortinet's latest Global Threat Landscape Report. That got my attention again. The data isn't background noise. In fact, it's a pretty clear signal. This shows that things are getting more serious, not less. Derek has been tracking the threat landscape for over 25 years, 22 of them at Fortinet, where he leads the FortiGuard Labs threat intelligence team. That kind of tenure is rare in this industry. Furthermore, it gives him a long view that's useful when you're trying to understand whether a trend is real or just noise. In this case, the ransomware numbers are real. The reasons behind them are more interesting than the headlines usually get into. Part of what we talked about is how the economics and tactics of cybercrime have shifted. It's not just that there are more attacks. It's that the attacks are more targeted and more deliberate. They are increasingly supported by tools that make sophisticated operations accessible to a much wider pool of threat actors. The AI angle here is real. In addition, Derek gets specific about what that actually looks like in practice — not in a theoretical sense, but in terms of tools that exist right now. He also discusses what they cost. There's also a metric from the report that I think should probably get more attention than it does. It has to do with how fast attackers move once a vulnerability becomes public knowledge. The window has gotten tight enough that some of the conventional wisdom around patching and response timelines doesn't really hold up anymore. Because of this, we talked through what that means for defenders. We also discussed what a more realistic approach looks like. One thing I appreciated about the conversation is that Derek didn't make it all sound hopeless. There's a practical framework for thinking about defense that he walks through — one that accepts the reality that you're never going to eliminate all your risk. It focuses instead on identifying and closing the exposures that actually matter most. Consequently, that's a more useful starting point for most organizations than trying to chase everything at once. We also got into some of the work Fortinet does that goes beyond building security products — specifically around disrupting cybercriminal infrastructure and working with law enforcement and international partners to hold threat actors accountable. Derek mentioned something toward the end of the conversation that I hadn't heard before. Specifically, it was a new initiative that takes a pretty different approach to gathering intelligence on cybercrime networks. Worth listening to. And because it's the TechSpective Podcast, we did eventually go off-script. There was a brief Star Trek tangent. There were house plants. That's just how these go. The full episode is below. If you work in security or are responsible for making decisions about security at your organization, it's worth the time.
March 23 · 42 min
The Agentic AI Hype Is Real — But So Is the Confusion
Everyone is talking about agentic AI. And that's part of the problem. Over the last couple of years, the term has gone the way of every other buzzword in tech — slapped onto products and platforms regardless of whether it actually applies. Marketing departments are busy. As Adi Kuruganti, Chief AI and Development Officer at Automation Anywhere, put it, we sat down to record the latest TechSpective podcast episode. When marketing departments get busy, clarity tends to suffer. Automation Anywhere has been in the automation space for over a decade. They helped create the Robotic Process Automation category. So, Adi has a longer view on this than most. He knows what automation looked like before the AI wave hit. He also has a pretty specific definition of what an agent actually is — one that rules out a lot of what's currently being marketed as agentic AI. That distinction has real consequences. When you're automating routine, low-stakes tasks, some ambiguity is tolerable. But when you're talking about healthcare workflows, financial processes, or anything touching sensitive customer data, the difference between a rules-based automation and a probabilistic AI agent matters. Getting that wrong isn't just a technical problem. In fact, it can be a compliance problem, a liability problem, or worse. We also get into accountability. When an AI agent takes an action — reads a document, makes a decision, updates a record — who's responsible for that outcome? It's a question a lot of organizations are still working through. The answer is more nuanced than it first appears. Adi has a clear perspective on this, shaped by what Automation Anywhere sees across its customer base of more than 5,000 enterprises. Data privacy comes up, too. Giving an AI agent access to the context it needs to actually be useful means sharing information with it. But in regulated industries, that creates real constraints. How do you give an agent enough to work with without exposing data it shouldn't touch? It's a real problem for a lot of enterprises right now. We talk through how organizations are navigating it. And then there's the question of trust — specifically, how much autonomy you give an agent before a human needs to review what it's doing. The answer isn't as straightforward as "always have a human check the work." Adi makes a point here that I think a lot of people in the AI SOC space would recognize immediately. If you've been following the agentic AI conversation and wondering how much of it is real versus noise, this episode is worth your time. Adi doesn't oversell where the technology is. He's direct about what still needs to mature before agentic process automation can scale the way people expect it to. And he knows the difference between a real shift and a rebranding exercise. The TechSpective podcast is available on all major podcast platforms. You can also watch the full episode on YouTube.
March 18 · 38 min
Why Cloud Still Feels Harder Than It Should Be
Cloud was supposed to make everything easier. In some ways, it absolutely has. You can spin up infrastructure in minutes, scale on demand, and deploy globally without ever touching a piece of hardware. That’s a massive shift from the days when a “deployment” meant racking servers and hoping you sized things correctly six months in advance. But if you’ve actually been in the trenches—even recently—you know the reality is a little messier. Meet FluidCloud That’s where this episode of the TechSpective Podcast starts. I sat down with Harshit Omar, co-founder and CTO of FluidCloud, and we ended up digging into something that doesn’t get talked about enough: the gap between what cloud is supposed to be and what it actually looks like day to day. Because “the cloud” isn’t really a thing anymore. It’s a collection of platforms that all do roughly the same things… just differently enough to make your life harder. AWS, Azure, Google Cloud—they all check the same boxes at a high level. Compute, storage, networking, databases. But once you get past that surface layer, the differences start to matter. The way services are structured, the way they’re configured, the way they behave—it’s not interchangeable. Not even close. And that becomes a problem the moment you try to do anything beyond a single-cloud deployment. Multi-cloud sounds great in theory. Flexibility. Resilience. Avoiding vendor lock-in. All good things. But in practice, it usually means you’re juggling multiple sets of tools, multiple skill sets, and multiple ways of solving the same problem. Most teams don’t have deep expertise across multiple clouds. They might be strong in one. Maybe decent in a second. Beyond that, it gets thin fast. And even if you do have the talent, you’re still dealing with the reality that everything moves—constantly. New services, updated APIs, shifting best practices. What you knew a year ago doesn’t always map cleanly to what you’re doing today. The Need for Speed...and Control We also got into something I’ve seen play out over and over again—the tension between speed and control. Developers want to move fast. That’s their job. The cloud makes it easy to spin things up, try things out, and iterate quickly. But someone still has to manage cost, enforce security, and keep everything from turning into chaos. That responsibility doesn’t go away just because the infrastructure is abstracted. The old world had its limitations, but it was predictable. You knew what you had because you could point to it. Now, your environment can change in real time, and not always in ways you expect. That’s powerful, but it’s also a little dangerous if you don’t have the right visibility and controls in place. One of the more interesting parts of the conversation was looking ahead a bit—not in some five-year crystal ball way, but just where things seem to be heading. Right now, cloud providers still benefit from a certain amount of friction. Once you’re in, you’re kind of in. Moving workloads somewhere else is possible, but it’s not trivial. That friction keeps customers sticky. But what happens if that changes? What happens if moving between clouds becomes easy enough that it’s just… a choice? That’s not a small shift. If organizations can move workloads without a ton of overhead, it forces cloud providers to compete differently. It’s no longer about who you’re locked into. It’s about who actually delivers the best experience, performance, and cost. We’re not fully there yet, but you can see the direction things are going. This episode doesn’t try to wrap that up with a neat conclusion, because there isn’t one. It’s a real conversation about what’s working, what isn’t, and where things might be headed next. If you spend any time dealing with cloud, DevOps, or security, this will probably sound familiar.
March 13 · 56 min
Most Companies Are Still Just Playing With AI
Everybody's got an AI strategy. Every platform claims to be AI-powered. Every vendor deck has a slide about how their product uses machine learning to deliver transformative outcomes. Most of it is still theater. I had a conversation with David DeSanto, CEO at Anaconda, recently for the TechSpective Podcast, and what struck me most was how honest he was about where enterprise AI actually stands. Not where vendors want it to be. Not where the headlines say it is. Where it actually is. A lot of organizations have run pilots. Some have solid proof-of-concept projects. A handful have built internal tools that genuinely save teams time. But very few have moved AI into real production across the business. There's a big difference between "we're experimenting" and "this is how we work now." That gap is where most companies are stuck---and it's not because the technology doesn't work. The demo almost always looks good. A model produces useful output. A prototype saves someone a few hours. The problem shows up when you try to scale that across an enterprise environment. Suddenly you're dealing with data governance questions, security concerns, reliability issues, and a fundamental trust problem: can we actually rely on what this thing produces? Those issues don't show up in the demo. Open source plays an interesting role here. It's always been central to the data science world, and that hasn't changed. Developers and data scientists are still experimenting constantly---new models, new frameworks, new workflows. Open ecosystems make that possible. But they also create real headaches for organizations trying to manage dependencies, maintain security, and keep things consistent across teams. Innovation versus governance. That's the tension nobody has fully figured out yet. Something else worth noting: AI is changing what technical expertise actually means. Tasks that required specialized skills a few years ago can now be partially automated. That sounds like it should reduce the need for expertise---but it mostly just moves where that expertise matters. Technical teams spend less time writing code from scratch and more time framing problems, evaluating outputs, and validating results. Knowing how to ask the right question---or spot when an AI's answer is subtly wrong---can matter more than generating the answer in the first place. That's a real shift in how those jobs work, and most organizations are still figuring out how to adapt. Trust is the underlying issue running through all of this. Organizations can't treat AI like a magic box that produces correct answers. They need to understand how models work, how their data is being used, and how outputs are generated. Without that visibility, it's hard to rely on AI for anything that actually matters. And the challenge isn't really technical. The technology works well enough. What's hard is building the infrastructure, governance, and culture around it---getting security teams, data scientists, developers, and business leaders to actually work together instead of operating in separate lanes. That collaboration doesn't happen naturally. It has to be built deliberately. AI also tends to change the process, not just speed it up. Teams aren't just doing the same work faster---they're working differently, exploring problems differently, testing ideas differently. Machines are becoming collaborators in that process rather than just tools. Adapting to that takes time. The organizations that figure it out won't be the ones with the most advanced AI technology. They'll be the ones that put in the unglamorous work---governance frameworks, cross-team alignment, careful validation of what the AI actually produces. That's less exciting than the vendor pitch. But it's closer to what real progress looks like.
March 10 · 48 min
Rethinking Cybersecurity For A World Of AI And Machine Identities
I spend a lot of time talking with people in cybersecurity. Founders, analysts, CISOs, researchers. One thing that comes up again and again is that the problem space keeps getting bigger. Not just more threats—more complexity. That’s really the thread running through my recent TechSpective Podcast conversation with Clarence Chio, co-founder and CEO of Coverbase. Security used to be easier to conceptualize. Not easier to solve, necessarily—but easier to frame. You had networks, endpoints, users, and a perimeter. Protect the edge. Monitor what’s inside. Respond when something goes wrong. That model doesn’t really exist anymore. Today, most organizations operate in environments that span multiple clouds, dozens or hundreds of SaaS applications, APIs everywhere, and automated workflows connecting everything together. Identities are everywhere too—human users, service accounts, machine identities, AI agents. The number of things acting inside a system has exploded. And every one of those things represents potential risk. Clarence and I spent a good part of the conversation talking about how that shift changes the nature of cybersecurity. It’s less about building walls and more about understanding behavior. Who is doing what? What systems are interacting? What’s normal, and what isn’t? That sounds simple, but it’s actually one of the hardest problems in security right now. The environment changes constantly. New tools get deployed. Developers spin up services. AI models start interacting with data pipelines and APIs. Keeping track of it all is a challenge. Then there’s the AI angle. AI is showing up everywhere right now—on both sides of the security equation. Security vendors are embedding AI into their platforms to analyze data faster and automate responses. At the same time, attackers are experimenting with AI to generate malware, improve phishing, and automate reconnaissance. But one thing Clarence pointed out—and I agree—is that AI doesn’t magically solve security problems. If anything, it tends to amplify whatever processes already exist. If your visibility is poor, AI doesn’t fix that. If your governance is weak, automation can actually make the problem worse. Technology alone rarely fixes systemic problems. Another part of the discussion that stood out to me was the human side of security. It’s easy to focus on tools because that’s what vendors sell. But effective security programs depend heavily on the people running them. Security professionals need to understand the technology, obviously. But they also need context and judgment. They need to know how systems interact and how changes ripple across an environment. And maybe most important, they need the freedom to question assumptions. That’s something Clarence emphasized during the conversation. In fast-moving technology environments, curiosity and critical thinking matter. Security teams can’t just follow checklists. They have to understand how systems behave and be able to spot when something doesn’t look right. Which brings us back to complexity. The attack surface keeps growing. Infrastructure is more distributed. AI and automation are adding new layers of capability—and new layers of risk. There’s no single tool that solves that. What organizations can do is build better visibility, invest in people, and develop security programs that are designed to adapt rather than assume the environment will stay stable. That’s easier said than done, but it’s the direction things are moving. If you’re working in security—or just trying to make sense of how AI and modern infrastructure are reshaping risk—I think you’ll find the conversation interesting. Clarence brings a thoughtful perspective, and we cover a lot of ground without getting lost in buzzwords. You can listen to the full episode of the TechSpective Podcast or watch the discussion on YouTube.
February 19 · 49 min
Who Do You Trust Online—And Why?
Trust on the internet used to be a fairly simple calculation. You looked for familiar names, recognizable brands, maybe a blue checkmark, and you made a judgment call. Today, that math often fails. AI has changed the game. Deepfakes are convincing. Entire personas can be spun up in minutes. Fraud doesn’t look sloppy anymore—it looks professional. And in many cases, it looks exactly like the people and platforms we already rely on. That’s the backdrop for my latest episode of the TechSpective Podcast, where I sat down with Oscar Rodriguez, who leads product efforts around trust at LinkedIn. The conversation quickly moved past features and announcements and into a much bigger question: how do we decide who to trust online when it’s getting harder to tell what’s real? LinkedIn has become my primary social platform over the past few years—partly by default, partly by design. As other platforms drifted further into chaos, LinkedIn positioned itself as the place where professional identity still mattered. But even there, the ground is shifting. The platform is more social than it used to be. The conversations are broader. And the risks are higher. In this episode, we dig into that evolution—not just how LinkedIn has changed, but why it’s changing and what that means for the people using it every day. We talk about professionalism as a concept, how it’s expanded beyond résumés and job postings, and why trying to rigidly police what “belongs” on a professional platform misses the point. At the same time, we don’t ignore the downside of that openness. One of the recurring themes in our conversation is signal versus noise. When you’re interacting with people you don’t know—often several degrees removed from your own network—what clues do you rely on to decide whether someone is legitimate? Mutual connections? Profile history? Gut instinct? Verification badges? Those signals matter more than ever, and not just on LinkedIn. As Oscar explains, trust has become a portable problem. We’re constantly being asked to prove who we are, where we work, or whether we belong—often across dozens of platforms that don’t talk to each other. That friction creates opportunity for abuse, but it also forces a conversation about how trust should work at internet scale. We also get into how AI is accelerating the arms race. The same tools that make it easier to create content and connect at scale also make it easier to deceive. Fraudsters don’t need to sound unprofessional anymore. Bots don’t look like bots. And “doing your own research” is a lot harder when expertise itself can be convincingly faked. Rather than offering simple answers, this episode focuses on the trade-offs. How much friction is acceptable in the name of safety? What does verification actually prove—and what doesn’t it prove? Should trust be assessed once, or continuously? And who ultimately bears responsibility when things go wrong: the platform, the user, or both? Listen to or watch the full episode of the TechSpective Podcast with Oscar Rodriguez to hear the full conversation.

Showing 1–20 of 22 episodes