#43 - Verified, Authorized, and Compromised: The Return of the Air Gap

We have all heard this line, identity is the new parameter, since maybe 2015. Everybody has said it, it has been on slides, on t-shirts and on keynote backgrounds with those glowing padlocks stock photo. It has become the bumper sticker for a whole movement. I have been publicly pushing back on it for a while now, not because the instinct behind it is stupid. The instinct is right, but the parameter is a line. You are either inside it or you are not. An identity is not a line. Identity is a signal. In a word where there is no edge, no castle wall, no inside, no outside, it is the strongest signal we have for evaluating every access decision. So here is the framing I have been using. Identity is the strongest signal in the decision control plane. And the decision control plane doesn't evaluate intent. It evaluates attributes, location, provenance, device posture, behavioral signals, risk context. And from all of those, it produces one thing, a fidelity assessment. How trustworthy is this signal? Right now, in this context, should this happen? And that's the job. And the reason that framing matters. The reason I have been insisting on it is exactly what this summer proved. Because this summer, three of the largest AI labs in the world, handed us five priest companies and a masterclass in what happens when the fidelity assessment is working perfectly. But the answer is still wrong. Today we are going to go through it. The incidence, the root cause and what the market is doing with the narrative. And what the actual fix looks like. But I will do all of it from the lens of identity. I'm Rohit. This is the identity navigate. Okay, let's get into it. So real quick story. And I know that you all know this. So I'm not going to dwell here. The parameter used to be physical firewalls at the edge. Everything inside is trusted. Everything outside is not. And for a while, that worked. Then people got laptops. The cloud happened. Remote work happened. And the parameter become politely aspirational. So we pivoted. Zero trust. Stop trusting the network. Start trusting the identity. Verify everything. Never assume. Check context. Check behavior. Check entitlements. It was the right call. But here is what we baked then when we made that pivot. We assume the attributes would always tell us something reliable about the instructions behind the request. Not consciously. We didn't sit in a room and say, let's build everything on the assumption that provenance is clean. Now we did not do that. We just did it because for 20 years, it was when the user authenticated a human had made the decision to authenticate. When a service account ran something, a human had configured it to run that thing. The provenance chain was always short and the signal, therefore, was always clean. But an agent breaks that an agent has a credential. It passes authentication. It's in you directory. Your location checks passes. Your device check passes. Your behavior might look like completely normal. The fidelity assessment by definition then will come back clean. And the instruction driving all of it might have been written by someone you have never seen. Prompt injection. Social engineering for the workload. Not the person. So at machine speed, the attributes are fine. The fidelity assessment is correct given the attributes it has. The control plane did exactly what it was designed to do. It just never got the one attribute that would have changed everything. The provenance of the instructions. That's the problem. And what happened this summer is the case study. So story time. And you might have read bits and pieces of it here and there. Or you might have turned a deep dive into it. But let's go through these three stories. And I am also going to tell you the root cause of each one at the end. But I'll give you a fair warning. This is really going to be underwhelming. Okay. The first one. So it was late July and open AI is running a capability benchmark exploit gym. The point is to measure raw capability in a cyber context. So the safety guard rails are dialed down on purpose. The environment is isolated, air-gapped, controlled test. Two models start working the benchmark. Somewhere in there they figured something out. The answer key isn't in the sandbox. So they go get it. I want to sit here for a second because because this matters. They weren't trying to escape. They weren't being malicious. They were optimizing. The way you and I might Google the answer to a hard problem rather than derive it from scratch. Remember stack overflow? The most efficient path to winning the exercise happened to go through hugging faces production infrastructure. Long place at the wrong time. Or now after the acquisition maybe right place at the right time. So that's where the agents went. They found a zero day in a package registry proxy. Chained it with a stolen credential, escalated privileges and moved laterally across two company system. Hugging face counted the actions afterward. Seventeen thousand six hundred over four days with four compromised account. Now nobody sent them an optimizer just took a shortcut. So what was the root cause? The sandbox had internet access. It wasn't supposed to, but it did. That's it. A configuration value. Remember me telling you that this was underwhelming? I know. I felt it too. Okay. Let's see if the second story can do any better. So open AI discloses this. And to their credit they told people. And anthropic does what you want a responsible organization to do. They go look at their own data. Well done. They put a hundred and forty one thousand evaluations and go through them. They find six where their clawed model has reached out and touched real external organizations. Not simulated real. So three companies were breached. So when I read this I was hoping for a sophisticated attack chain. Maybe a novel exploit. Something that would get me excited to tell you all about. But what happened was one model scanned nine thousand real hosts until it found weak passwords and authenticated endpoints. Or unauthenticated endpoints. This is a twenty year old checklist. The kind of thing your intern catches on their first assignment. Why did the models have access to anything real? The evaluation environment was supposed to be offline. A misconfiguration at the testing vendor. A company called Irregular. Mint they had internet access. The model was told they were isolated. But they weren't. Then Meta disclosed the same thing. Same vendor. Same misconfiguration. One more breached company. And here is the part that got me. Meta didn't catch it themselves. Irregular told them. Three frontier labs. and in every single story, the AR gap for the setting that somebody else was managing. Again, underwhelming, okay. So the third one and this one I promise is different. And also, this one is probably already in your environment. Researchers looked at the MCP server that lets developers AI coding assistant read pull requests from Azure DevOps. The server was returning PR description verbatim, everything including HTML comments. Now, the nice thing about HTML comments are that they are invisible in a browser. A human reviewer reads a clean diff. Normal commit messages, a polite description, everything looks fine. The AI assistant though reads the same pull request and sees all of them. Plus instructions embedded in the HTML comments that a human reviewer would never see. And when it sees those instructions embedded in the HTML comments, it carries them out with the developers credentials. Approved pull requests trigger pipeline in unrelated projects. Copy confidential wiki pages somewhere that hacker can collect them later. You got the point. Now the developer is verified. The assistant is authorized. Every action passes every policy you have. The only attribute the control plane didn't have the provenance of the instruction. Who actually wrote the thing the agent was executing. That never made it into the fidelity assessment. This one I hope was a little better than the first two. And we are also seeing a lot of these similar attack patterns on the gate pull request as well. But that's a story for another time. So three stories. Every identity was verified. Every action was authorized. Five companies were pleased and there were zero human attackers. And two out of three controls held but they didn't matter. Now I want to step back for a second because there is something else happening here that I think is worth naming. Now I'm not pointing fingers at anyone. I am just noticing. When a government bans your AI model. What does that communicate to the market? As on June 9th, 2026, Anthropic launches Fable 5 and the Mythos class model. Three days later, the US Commerce Department issues an emergency export control directive at 521 pm on a Thursday. 90 minutes to comply and models go offline globally. The reason a jailbreak could unlock in the government words the full dangerous cyber security capabilities of the underlying model. And a China linked group was suspected of having access. Now three weeks later, the restrictions were lifted. But the restrictions lifted. The story didn't. The US government, the almighty US government banned this AI because it was too dangerous. Is now permanently in the world. That's the headline of every article. That's in the boat presentation. It changes how the market thinks about what these models can do. In ways that three weeks of restricted access never undoes. And again, the jailbreak was real. The government action was real. The national security concern was real. But I want you to notice something here. When open AI disclosed the exploit gem incident, when they set their model autonomously profound a zero day, escaped the sandbox and breached hugging face production infrastructure, that was a safety disclosure. But it was also the most powerful capability demonstration in the company's history. Free documented with an independent third party to corroborate it. Our model found a zero day by itself during a test we were running. That's a terrifying statement if you are in security. It's a career making sentence if you are in sales. It is the same sentence. And the topic followed met up followed. Every lab gets to say, we were responsible. We told you about the thing are AI did while we weren't looking. And also leave in the room. Here is what are AI did. Now, none of this is fabricated. The incidents are real. The disclosures are real. But here is the mechanism worth understanding. These disclosures don't make people want to use AI less. They make most people feel behind. The logic runs like this. If the other companies agents are autonomously finding zero days and breaching companies during test and you are not running agents yet, what exactly are you bringing to a capability fight? Fear and form of friends are the same emotions. The only difference is which side of the paywall you are standing on. And this matters practically. Because irregular's own statement was clear. The meta incident was not a sandbox escape, not a sophisticated cyber action. A configuration setting was wrong. That's the root cause. That's all it was. But AI too dangerous to be available is a much better headline that testing, vendor, misconfigured and environment variable. So here is the ask. When a capability story lands in your inbox, especially one that makes you feel behind, before you respond to the feeling, find the root cause, what attribute failed, what wasn't in the fidelity assessment that should have been and who was managing the thing that broke. Because you can fix a misconfiguration. You cannot fix a feeling of being behind. And as I am saying this, isn't this also true for life? But I'm no philosopher. I'll stick to the things that I know about. So enough on the problem. Here is what I think the answers look like. I call this episode the return of the air gap. I want to be specific about what I mean, because I'm not suggesting we unplug everything and go back to 2003. Although I'm not opposed to it, but I'm not suggesting it. What I'm saying is the concept behind the air gap, separate environments, separate trust, hard boundaries that require deliberate action to cross that concepts needs to live at the identity layer now, not the network layer. And this is a bold claim that I'm making. Now run it through dev, pre-pod and prod. Most organizations today have these environments separated at the network level. Different VPCs, different subnets, but they share identity infrastructure. Same IDP, same authorization server, sometimes the same service account tokens that were temporarily shared during an incident two years ago and never cleaned up. We have all been there. An agent that can reach both environments is a bridge. It doesn't matter how isolated the compute is. If the credential is valid in two words, the credential is the path. And anything that can reach the credential or manipulate the thing holding it can use that path. So the identity air gap has three things. And honestly none of them are new ideas. We just stopped doing that and I'm advocating for them now. So the first idea is separate test planes per environment. Not just separate networks, separate token issuers, different authorities. An identity that exists in dev means nothing to the prod authorization server. [BLANK_AUDIO] If something needs to operate in prod, it gets a new identity, under prods authority, with prods control, audited under prods auditory. No exception. Second, no credential valid in more than one environment ever. I know how this lands with the engineering team. I have been on both sides. I am is the department of NO again. But hear me out. The alternative is your pre-prod agent is holding a key that opens prod. The only thing standing between a bad prompt and a production incident is that nobody has tried it yet. That's not a control that's hopes, prayers and luck. So we need to get to short-lived, scoped, issued, fresh per context every time. And the third is every permitted crossing has to be explicit, brokered and provable. Because crossings will happen, deployment pipelines, incident response, legitimated reporting, fine. But these crossings are intentional. They go through something that knows it's crossing an environment boundary, they are scoped and time limited, and the log entry tells you the full chain. Not service account x did y, but who asked, who authorized on behalf of whom, with what scope crossing from where to where at what time? That is a log entry I would look at. This is actually reconstruction of the delegation chain. Because here is the thing about the delegation chain data. It's not just a record, it's an attribute, a provenance attribute, feed it back into the control plane and you have completed the fidelity assessment. The control plane now knows not just who is making the request, but what chain of instructions got us there. And that is the input it was always missing. So either sever the path or make it provable. Now there is no third option and the incidents from this summer are what the third options look like. So I guess there is a third option, right? But for all intent and purposes, there are only two options, sever the path or make it provable. So what are the takeaways for a practitioner? One, find every credential in your state valid in more than one environment. Not just service accounts, your agents, your pipelines, your MCP connectors, CI/CD tokens, anything with a client ID and a secret. If it works in two words, you have a bridge, you have a named name at this week. To check whether an environment shares token issuer, same IDP, same authorization server, same root CA across Dev and Broad, means you don't have separate trust planes, you have one trust planes with labels on it. Three, find every agent that reads one environment and writes to another. That's your reverse injection surface, an agent reading production telemetry and writing code in Dev is a path from code into your SDLC or a path from prod into your SDLC. No attackers required, a poisoned log line becomes a pull request. Four, put model versions under change control. When a vendor updates the underlying model, that's a deploy behavior changes. If you certify the agent on version n and the vendor silently rolled to version n+1, you have an untested deployment production that never touched your pipeline. And five, every permitted environment crossing needs a broker, a scope, a time limit and a log entry with the full delegation chain. Not just what happened, but who asked who to do what? All the way up, that chain is a provenance attribute and it belongs in your control plane. So five things, and none of them requires a new product, all of them requires someone to own them. So we started with the reframe, not a parameter, a decision control plane, identity being the strongest signal in that plane, not a wall, but an input into every access decision in a word where there are no walls left. And the reason that framing matters, the reason I have been pushing on it is exactly what this summer proved. A parameter asks, asks by definition, are you inside or outside binary? The decision control plane evaluates attributes, location, provenance, defies, behavior, risk and context and produces a fidelity assessment. How trustworthy is this signal right now in this context should this happen? And that's the right question and the control plane in every one of those incident was asking it correctly. The problem was upstream, the provenance of the instructions never made it into the attribute set. The fidelity assessment came back clean because it was working on incomplete input. Because the agent's credentials was fine, its location was fine, its behavior was normal, what we couldn't see was that the instruction driving all of it had been written by someone outside the chain of trust. So the identity air gap isn't about rebuilding the parameter, it's about completing the attribute set, separate trust planes so that provenance means something. An identity from dev cannot impersonate an identity from prod. No credential valid into environment so that the crossing itself is always visible and the delegation chains log end to end so that the provenance is an attribute the control plane can actually evaluate. Feeded the right data, let it do its job, that's all, that's the whole thesis. Now if this one made you think, share it with someone deploying agents right now who hasn't thought about provenance yet and I'm sure they are not hard to find. And I'll leave you all with one question. How many credential in your environment are valid in more than one word right now? Thanks for listening, this is Rohit, your identity navigator.