TechSpective Podcast

Amihai Niederman joins me on this episode of the TechSpective Podcast to talk about what happens to identity security once AI agents start outnumbering the humans on a company's network. He's the co-founder of NewCore, a startup betting the answer isn't another tool bolted onto what companies already run. It's a rebuild. That bet is worth taking seriously. The identity stack most companies run today wasn't built for this problem. It was built for a much smaller one. Identity Grew Up As An IT Problem For most of its history, identity has been treated as plumbing, not protection. Active Directory sat inside the network. If it got breached, the conversation was about how someone got past the firewall. Identity itself wasn't seen as the thing that failed. That framing made sense when the network was the perimeter. It stopped making sense once everything moved to the cloud. Identity providers became the real gatekeepers. Stealing a password turned out to be a lot easier than breaching network hardware. The industry responded the way it usually does. It bolted on point solutions, one after another, each one solving a piece of the problem on its own. NewCore talked to more than 100 CISOs while building its product. The average company, they found, runs 8.3 identity tools. That's a vendor number, worth taking with a grain of salt, but the picture rings true. A pile of tools from different makers, held together, hoping the seams don't split. Agents Break The Math, Not Just The Tools None of that was built with AI agents in mind, and that's where the trouble really starts. An agent isn't just a faster version of a person logging in. Amihai draws a real line here. A lot of what gets called an agent today is really a power tool, with a person still making every meaningful decision. It only becomes an agent once you hand it a full task and let it decide which tools to use, in what order, on its own. At that point it stops being a stand-in for a human. It needs its own governance. That distinction matters because of scale. Agents can work something like 100 times faster than a person, and they never log off. That's not a modest bump in the number of identities a company has to manage. It's closer to 100 times as many. A ninth tool doesn't fix a jump that size. Amihai compares it to converting a gas engine to run on electricity. You can't patch your way there. Most companies are handling this the sensible way for now. Deploy one agent. Watch it closely. Adjust, then repeat. That works fine at a ratio of one agent to one human. It falls apart once the ratio flips, and the flip is coming faster than most rollout plans assume. The Resistance Isn't Where You'd Expect It The instinct is to assume the hardest part of an identity rebuild is convincing a CISO to hand someone new the keys to the whole environment. It usually isn't. CISOs already live with what's broken in their current stack. They know exactly what they're trying to fix. The real friction shows up everywhere else in the company. Old identity connections nobody wrote down. Employees who need a new authenticator app. A migration slow enough that nothing breaks along the way. That's the harder, less glamorous problem. It's also the one that will decide whether identity security catches up to what AI agents are about to demand of it. There's more to this conversation than fits here. Where identity security goes as the ratio of agents to humans keeps climbing. A sharp comparison involving stoplights and self-driving cars. How NewCore is thinking about protecting actual people while building for a mostly agentic future. Catch the full episode on the TechSpective Podcast:

Nicole Beckwith joins me on this episode of the TechSpective Podcast to talk about a problem most of the security industry still hasn't fully reckoned with. Beckwith runs security engineering and operations at Cribl, and before that she spent years in law enforcement and digital forensics, which is the lens she uses to explain why the way we've built detection for the last couple of decades is running out of road. Matching Isn't the Same as Understanding For as long as I've covered this industry, detection has mostly come down to matching something you already know is bad against something showing up on your network: a hash tied to known malware, an IP address tied to known bad infrastructure. It's a yes or no answer, and for a long time that was good enough, because attackers weren't changing their tooling anywhere near as fast as they're changing it now. That model is breaking down. Polymorphic malware changes its own hash per victim. Phishing infrastructure gets built fresh, one URL at a time, sometimes one top-level domain at a time. By the time a hash or a bad domain makes it into your threat feed, the attacker who used it has often already moved on to the next one. Beckwith put it plainly: the bottom layers of the pyramid of pain, the framework the industry has used for years to rank how much damage a given detection actually does to an attacker, are “essentially just on fire right now.” An Indicator Only Proves Someone Was There Beckwith's law enforcement background gives her a useful way to explain what's actually missing. An indicator, she says, is a single piece of evidence, the equivalent of a fingerprint on a glass or a license plate written down at the scene. It puts someone there. It doesn't tell you what they did once they arrived, who they were working with, or why. “It's a fast, cheap triage of known bad,” is how she describes it, and that's the right job for it. The mistake is treating a triage tool like it's the whole case. Behavior is a different kind of evidence. An attacker can swap a hash in seconds, but if they want credentials, they still have to do the things credential theft requires, and those actions leave a pattern an indicator alone was never built to catch. Why This Is Harder to Fake, and Harder to Buy This is also where a lot of vendor marketing falls apart. Walk any security conference floor this year and nearly every booth claims some version of AI-powered, behavior-based detection. Beckwith has spent enough time doing exactly that to know most of it is still a rules engine underneath, with a model bolted on for the pitch. Real behavioral detection takes the unglamorous work of engineering telemetry, mapping it to actual attacker tactics, and tuning it against your own environment instead of shipping something generic and calling it AI. That work doesn't show up on a slide, which is exactly why most vendors skip it. Beckwith gets into a lot more of this on the episode, including what this shift means for who gets hired into a SOC and how she personally judges whether a vendor's AI claims hold up. Watch or listen to the full conversation on the TechSpective Podcast.

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.

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.

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: