Coder Legion - Recent posts tagged machineidentity

Two Coder Legion Readers Challenged Our AppViewX Piece. Here's the CEO's Answer.

Tue, 15 Sep 2026 23:30:00 +0000

"9 Seconds. Zero Backups." drew more engagement on Coder Legion than anything we've published here, and the sharpest part of it wasn't in the piece. It was in the comments. Two readers, Mike Dabydeen and sibasispadhi, raised questions specific enough that we took them straight back to Archit Lohokare, AppViewX's CEO, instead of paraphrasing around them.

Dabydeen's challenge was the harder one. He argued the original piece framed the PocketOS database wipe as a permissions failure, when the more useful frame is that nothing imposed a cost between the two destructive calls — delete the database, then delete the backups — no hold, no rate limit, no second identity required to proceed. He pointed to prior art that predates AI entirely: S3 Object Lock in compliance mode makes an object undeletable for a retention period no matter who asks, and RDS deletion protection forces a separate API call to disarm a guard before any delete lands. His sharpest point was about units. A velocity control that blocks a second destructive call inside a time window would have caught PocketOS, since that incident was two calls. But a single delete against a bucket holding years of backups is one call, and any control that counts calls waves that through. If a control is time-based, he argued, it has to attach to blast radius, not call count — and estimating blast radius before a call runs is the actual unsolved problem.

Lohokare's answer: the platform's real-time policy doesn't key on action type alone. It runs what he calls a risk engine across five dimensions simultaneously — the agent's identity and permissions, what data it's touching and in what mode, the action itself (a routine read call versus a privilege-elevation command), the agent's full bill of materials and posture (has it started talking to an unsanctioned model), and its runtime history. Those combine into a single risk score that decides whether an action proceeds, gets flagged, or gets stopped. On the disarm question, he described four escalating checkpoints, chosen by how risky an action scores: human-in-the-loop approval before it runs, human-on-the-loop visibility with the ability to reverse it after, a kill switch scoped to one action or the whole agent, and multi-factor checkpoints — a passkey or one-time code — before a high-risk step proceeds.

On velocity specifically, Lohokare says the platform already blocks sequentially: if one action raises an agent's risk score enough, the next action gets blocked before it runs, based on accumulated history rather than a fixed call count. His example: if an agent's underlying model changes from Claude Opus to DeepSeek, AppViewX flags that drift and can halt the next action before the agent has done anything with the new model at all. On blast radius, his answer split the difference Dabydeen was pushing toward — customers can explicitly tag specific actions or resources as high-risk, and the platform separately watches behavior in real time to catch what wasn't tagged. He said this is running today at a large IT company, a trucking manufacturer, and multiple financial institutions, though he didn't name any of them.

Pressed on whether time- and blast-radius-based controls — the kind that don't require predicting what an agent will attempt — deserve more investment right now than behavioral prediction, Lohokare pushed back on the premise. His view is that you need both, because blast radius itself doesn't hold still. He pointed to the OpenAI-Hugging Face incident from our first conversation: nobody building deterministic controls for those agents could have anticipated they'd find and exploit a proxy-cache vulnerability to reach the open internet. Controls scoped to a known blast radius will eventually meet an agent that finds a path nobody scoped for. That's his case for running a probabilistic risk engine alongside the deterministic rules, not instead of them.

sibasispadhi's question was more direct: why didn't a secret scanner catch the AWS key in the first place? Lohokare says AppViewX does integrate with secret-scanning tools, but doesn't treat scanning as the real fix. An agent can acquire a credential from places no static scan covers, including from other agents it's communicating with. The value, in his framing, is catching a credential at the moment it's used, not the moment it's created. On the deeper issue — that the key carried admin-level access — he says the platform flags over-permissioned credentials and pushes a model past least privilege entirely: provision access just-in-time instead of standing, and start every agent with close to zero agency, expanding it only through human approval as trust is earned.

One thing came up that neither commenter asked about, and it's worth flagging on its own. Lohokare says the newer conversation with customers isn't only about agents destroying data — it's about agents destroying budgets. He described organizations whose AI spend got burned through by a runaway or manipulated agent well ahead of schedule, serious enough that AppViewX now monitors token consumption and cost in real time, with the ability to cut an agent off before it exhausts a budget, the same way it would cut off a destructive database call. Security teams are used to measuring blast radius in data and infrastructure. For an agent with a live credit card, that math needs a line item most security tooling was never built to track.

The Cursor Agent That Deleted a Startup's Database in 9 Seconds Also Deleted the Backups

Fri, 11 Sep 2026 19:00:00 +0000

In April, a Cursor agent running on Claude Opus was working through a routine task at a startup called PocketOS. Somewhere in the codebase it was scanning, it found an AWS key. It used the key to reach the production database. Then it deleted it. Then it went looking for the backups and deleted those too. Nine seconds, start to finish.

Archit Lohokare, CEO of machine identity security vendor AppViewX, brings up the PocketOS incident unprompted when asked what an overprivileged agent actually looks like before his company gets involved. It's one of two examples he uses, and the choice is deliberate: it's public, it's verifiable, and it's exactly the failure mode his platform is built to interrupt.

The scale of the underlying problem is what makes incidents like this inevitable rather than freakish. Machine identities now outnumber human ones 144 to 1 inside the enterprise, up from 92 to 1 two years ago, and Lohokare doesn't expect that ratio to hold steady. "Agents are a fundamentally new identity class," he said. Not a service account with a longer leash — a composite identity made up of a model, an MCP server, shared memory, and often 500 to 700 individual credentials, roughly the same number a well-connected human employee accumulates over a career. Multiply that by every agent a person now delegates work to, and the credential sprawl compounds fast. Some of those agents are ephemeral, too, spun up for a single task and gone minutes later, which means the identity a security team is trying to track may not exist long enough to be tracked in any conventional sense.

Lohokare pushed back, gently, on the word "guardrails." In his framing, guardrails are something you put on a model, and models are going to get breached — that's not pessimism, it's the design assumption he starts from. "The real controls should be on the actions of the agent," he said, "not the model." The distinction matters because it changes where the money and engineering effort go: instead of trying to make an LLM incapable of being talked into something bad, AppViewX's platform assumes that will eventually happen anyway and puts the enforcement point downstream, at the moment the agent tries to actually do something.

That shows up as three layers. Every agent gets a unique, quantum-safe cryptographic identity, so there's a durable anchor even as the agent's skills and behavior shift underneath it. AppViewX then monitors and rotates the credentials that identity holds — AWS keys, OAuth tokens, certificates — so a leaked key has a shorter useful life. Last, policy runs against the action itself in real time: an agent can be scoped to read a database but not delete it, and the deletion request never reaches AWS in the first place. Run that stack against PocketOS, and the AWS key gets flagged before it's used, or the delete command gets blocked before it executes — either one stops the incident.

The second example Lohokare described didn't make headlines. An agent was told to "create a sample database for testing purposes." Nobody told it to anonymize anything. It found an SSH key, logged into a remote server, pulled real production data, including personal information, and dropped it into a test database anyone on the team could see. Nothing in that chain required cleverness. It did exactly what it was asked, literally, with more access than the task required — which Lohokare says is the more common failure, not outright rogue behavior. Over-permissioning is close to a default, he argued, because whoever builds an agent tends to grant broad access up front rather than have it stall out later on a permission it lacks.

That failure mode scales with whatever tools an agent can reach through MCP, and Lohokare doesn't undersell the exposure. If an MCP server itself is misconfigured or carries a vulnerability, "the blast radius becomes infinite" — the agent's reach stops being bounded by what a vendor intended and becomes bounded only by what it can find. He points to the OpenAI-Hugging Face incident: public reporting puts roughly 1,200 agents in the broader operation, about 700 directly involved in the breach, exchanging more than 70,000 messages as they worked through exposed credentials and pipeline vulnerabilities to reach root access on a production node in under 13 hours. AppViewX's own MCP server is currently tied to its platform rather than self-hostable — it acts as a front end, though Lohokare says the PKI behind it can connect to other systems.

On post-quantum, Lohokare is skeptical of anyone claiming to have solved it. He points to HAWK, a signature scheme well into NIST's standardization process before Anthropic's Claude found a key-recovery attack that got it withdrawn this year. His conclusion isn't "wait for a safer algorithm" — it's that no algorithm should be treated as final. "Crypto agility is the solution, not migration," he said: infrastructure that can swap algorithms quickly, not a one-time move to whatever looks quantum-safe today. His advice for a team starting now — get full visibility into every certificate first, endpoints, VPNs, MDM, firewalls, before touching anything, then bring in lifecycle management to make the public-facing ones agile. Visibility alone takes most organizations a year to eighteen months.

Asked what nobody in his industry has actually solved, Lohokare skipped the marketing answer. Agent identity keeps changing shape as agents pick up new skills — a concept that barely existed six months ago — which makes "immutable identity" a moving target by definition. And nobody yet knows the real surface area of malicious agent behavior well enough to predict it. "We're far from solving that problem," he said. For developers building agent systems now, that's the honest baseline: the identity and access layer is catching up in real time, not ahead of it.