Access Is the New Perimeter

Shadow IT used to be some colleague registering on an unapproved platform. Now it's a refresh token in someone else's database, granted in a moment of curiosity, with permission to read every email you've ever sent.

Access Is the New Perimeter

In February 2026, an employee of an AI startup called Context.ai downloaded a Roblox cheat. The cheat carried Lumma Stealer, which harvested the employee’s corporate Google Workspace credentials along with keys to Supabase, Datadog, and Authkit. From there, the attackers got access to Context’s OAuth tokens (the ones their AI office-suite had been issued by hundreds of customers). One of those customers was an employee at Vercel, who had connected the tool to his Vercel-issued Google account and granted it probably too wide permissions. Two months later, attackers used that pivot to reach Vercel’s environment variables, exfiltrate them, and put the database up for sale on BreachForums for 2M$.

You have probably read this story, over and over again, in the last few weeks. It was on every tech magazine, social media and security newsletter. That kill chain let me think for quite a while. It is the cleanest illustration I’ve seen of where shadow IT actually lives now. As many other people are saying now, there was a time, not very long ago, when shadow IT meant a marketing colleague registered himself and his team on Trello without any vendor check, procurement or formal decision. The blast radius was a leaked roadmap, some tickets. The new shadow IT looks much more like a OAuth refresh token in a LLM provider Database, granted in a moment of curiosity, with permission to read every email the employee has ever sent. The blast radius has no edge.

I’ve been thinking about this problem from the inside of an organisation that is trying very hard not to slow itself down but also really cares about security. Engineering moves at the speed of curiosity now. A non-technical employee can wire together an agent, a CRM, and an inbox before lunch if not before breakfast. An engineer can prototype a workflow on production data over a coffee break. Both will produce something useful. Both will, by default, leave behind a token nobody is probably auditing.

Houston, we have a velocity problem

Permission-based governance (the old school with all the endless audits and reports) worked because building was slow. If a new app took six months, a two-week security review was a small overhead — annoying, tolerable, defensible, doable. People complied because the alternative, building from scratch themselves, was worse if not almost absurd to imagine.

AI inverted that logic. A workflow touching important data is now a 20min task, and a two-week governance loop on a 20min task is a 600% tax. People do not pay 600% taxes. They work around them, and the working-around is invisible because it produces no expense report, no documentation or ticket, no IT request: just a click on a consent screen that says, in ambiguous prose, Allow this app to read your email. The Vercel employee who granted that to Context.ai did exactly what most of his colleagues at many other companies have already done. You cannot audit your way out of a velocity gap. You can only try close it. The only question, most of us struggle to answer, is how. Or to be more precise, how without prohibiting the very behaviour that is driving the tech business forward.

Five planes, not five gates

I have to be honest, I don’t have a perfect answer. I don’t think anyone does. But I wanted to share at least a couple of ideas that have been helpful to me in thinking about the problem. The shift we are seeing is in many cases from “software you shouldn’t have installed” to “permissions you shouldn’t have granted.” The model we need - I think - has less to do with permission and everything to do with where policy lives. If you think about it, there are at least 5 distinct “planes” or “domains” that can help us keep up with the velocity without losing sight of the risk:

The IAM plane is the cheapest and most obvious. Every AI tool, every agent, every MCP server should authenticate as a named identity, an SSO-backed human or a service account you issue. No personal OAuth grants from corporate accounts to third-party agent platforms. Both Entra, AWS Identity Center or Google Workspace let administrators require admin consent for any app touching corporate data, and let them block unverified OAuth apps entirely. The Vercel breach happened in part because Vercel’s Google Workspace tenant was configured to let an individual employee grant permissions without a second pair of eyes. That setting is one administrative checkbox. It was annoying in 2019 and it is essential now.

The Egress plane as many platform call it now is where the modern control surface actually concentrates. A good colleague of mine and I were having a conversation a couple of days ago and praising recent improvements that for instance OpenRouter has made in this area. A sanctioned LLM and agent gateway gives you per-team API keys, model allowlists, zero-data-retention policies enforced at the policy layer, token budgets, and prompt and response logging with PII redaction. The non-obvious benefit is that the gateway becomes the path of least resistance. People route through it because the rate limits are better, the credentials are not on their personal card, and someone they can reach answers when something breaks. Laziness has always been and is the most reliable governance available. Or as a pentester I know puts it “Complexity is the enemy of security

The Data plane should resist the universal-classification trap. In many companies you see desperate attempts to label everything, every document every S3 bucket, every data row in a database. Trying to label every document fails predictably; start by picking the 5 (or 10 if you prefer) datasets that would actually hurt (customer PII, contracts, financials, source code, IAM secrets) and instrument egress around them. Microsoft Purview, Google DLP, regex filters at the gateway. Imperfect, defensible, and shipping in weeks rather than years. The point is not perfection but a control that does not depend on the user remembering the policy in the moment of action.

The Inventory plane is the one most underbuild and the one I would keep investing. I remember the positive surprises when in tech department we start using e.g. Datadog Software Catalogue to get a real-time map of what apps are actually talking to what data and the huge opportunities we discovered to simplify the landscape. Continuous discovery, not point-in-time approval, if the business model allows it. For AI It is enough to start with few feeds, merged into one map: e.g. SSO logs for new app authorisations, DNS logs for traffic to known AI and agent SaaS domains, and a self-service registry where teams declare what they’re building. Cross-reference them. The discrepancies: apps in the logs that nobody declared, traffic to domains nobody owns: are the signs of the shadow stack, surfaced automatically.

The Response plane. When something is found, and don’t lie to yourself, something will always be found, the default response should be triage, review and take a decision: shutdown or not not shutdown - that’s the question. Dear colleague, we saw you’re trying to connect your inbox to Agent X. Here is what that grants. Here is a more secure alternative. Migrate within X days, or here is how to make the current setup safer in the meantime. Shutdowns are reserved for actual exfiltration risks. If shutdowns are the default, people learn to hide better, the inventory plane goes blind, and the rest of the system becomes theatre.

Training for awareness

The planes above will get you most of the way or at least further down the way. The remainder is human, and it is the part nobody has a tool for.

Most employees, shown clearly what Allow this app to read your email actually grants, would not click. They click because the language is jargon, the consequence is invisible, and the consent screen is shaped exactly like a cookie banner. Clicking on a OAuth consent screen is not (only) a behaviour problem. It is a literacy and awareness problem, and a one-page internal explainer or a short onboarding video designed for humans rather than for security teams will outperform any policy rule against the careless majority. Most people I’ve seen clicking through those screens have simply no idea of what a token is, what it can do, and how it can be abused. The gap is the one between “what the user thinks they’re doing” and “what they’re actually doing”. Closing that gap is a cultural problem as much as a technical one and awareness is the first step.

Beneath that lives the cultural piece: in the organisations that handle this phase well, employees feel comfortable asking can someone look at this with me before I connect it without it feeling like a confession. If asking for help is slow, people stop asking. If asking is faster than not asking, the human layer becomes a control mechanism too, the only one that scales without instrumentation.

Permission scaled to a world where building was slow. Observability scales to a world where building is cheap. The attackers have already noticed. The decision left to make is whether the organisation notices in time to choose the order of its own discoveries.