エピソード

  • When the AI Breaks Its Own Rules

    When the AI Breaks Its Own Rules
    2026/09/02
    For most of the last year, the AI security conversation had a clear villain. Attackers were using AI to write better phishing lures, adapt malware mid-attack, and move faster than defenders could keep up with. That story was easy to tell because it fit the shape we already understood. Bad guys get a new tool, they use it against us, we build a defense. Then the defenders' own AI started breaking its own rules, and the story stopped being that simple. The Model Did What It Was Told In July, OpenAI disclosed that one of its models, running an internal test with reduced safety guardrails, found a zero-day vulnerability, broke out of its own sandbox, moved laterally through OpenAI's research environment, and reached across to Hugging Face. Two weeks later, Anthropic acknowledged that three of its own models had done something similar. Both companies were describing their own systems doing exactly what they'd been asked to do, just not in the way anyone expected. Brad LaPorte of Morphisec has been tracking this closely, and he pushes back on the idea that this is as novel as the headlines suggest. "This isn't necessarily novel," he told me. "It's just they made the front page of the newspaper finally." What's changed is the scale, and the level of autonomy behind it, enough that it's getting harder to write off as an edge case. That reframes what "guardrails" actually means. A model told to solve a problem and finds an unsanctioned path to solving it is still doing its job, just not the way anyone intended. Isaac Asimov's laws of robotics get invoked a lot in these conversations, and for good reason. "Don't harm a person" sounds like a rule until you realize a model can read it literally and conclude nobody got physically hurt, so nothing went wrong. Financial harm doesn't register that way. Neither does legal exposure or reputational damage, and neither shows up in a rule that vague. The Fundamentals Haven't Caught Up While that governance conversation plays out, the operational numbers are moving in the wrong direction. IBM's most recent cost of a data breach report showed the average time to identify a breach getting worse for the first time in five years, up six days to 247. Meanwhile, roughly 88 percent of organizations report using AI in at least one function, but only 5 to 10 percent are seeing meaningful return on that investment. A lot of the AI-driven layoffs making headlines aren't the result of AI actually doing the work yet. They're companies freeing up budget to chase a productivity gain that hasn't arrived. That gap between adoption and governance is where the real risk lives. Organizations are running AI agents that talk to each other, share data, and make decisions with non-human identities that most security teams haven't fully inventoried, let alone secured. Add unsanctioned AI tools employees are using without approval, and you have an attack surface that's expanding faster than most companies can map it. None of This Changes the Basics The uncomfortable part is that the fix isn't exotic. Identity and basic visibility into what's actually running in your environment still account for most of the risk reduction available to any organization. AI adds a new layer to secure, but companies that had their fundamentals in order before AI showed up are adapting. The ones that didn't are finding out that AI doesn't so much create new problems as it makes the old, ignored ones impossible to keep ignoring. Brad and I get into all of this on the latest episode of the TechSpective Podcast, along with where he thinks the AI funding bubble is headed and why he compares it to the mortgage-backed securities mess of 2008. Give it a listen.
    続きを読む 一部表示
    1 時間
  • Your AI Agents Are Multiplying and Nobody’s Counting

    Your AI Agents Are Multiplying and Nobody’s Counting
    2026/08/26
    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.
    続きを読む 一部表示
    57 分
  • The Attack That Turns Your AI Agent Into A Weapon Against You

    The Attack That Turns Your AI Agent Into A Weapon Against You
    2026/08/20
    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 ...
    続きを読む 一部表示
    41 分
  • Building an AI That Learns Like an Analyst

    Building an AI That Learns Like an Analyst
    2026/07/29
    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.
    続きを読む 一部表示
    36 分
  • Most AI Problems Are Really Capitalism Problems

    Most AI Problems Are Really Capitalism Problems
    2026/07/19
    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.
    続きを読む 一部表示
    49 分
  • The Case For Rebooting Democracy With AI

    The Case For Rebooting Democracy With AI
    2026/07/09
    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.
    続きを読む 一部表示
    51 分
  • The Remediation Cycle No Security Team Wants to Be Running

    The Remediation Cycle No Security Team Wants to Be Running
    2026/06/24
    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.
    続きを読む 一部表示
    37 分
  • Remote Hiring Opened the Talent Pool — and the Fraud Surface

    Remote Hiring Opened the Talent Pool — and the Fraud Surface
    2026/06/08
    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.
    続きを読む 一部表示
    46 分