The JSONFormatter Wake-Up Call: How Developer Tools Are the New Identity Breach Vector

Everyone uses developer tools to get through the day. A JSONFormatter to inspect an API response, or a JWT decoder when you need to inspect a token quickly. In most engineering teams, these tools are treated as harmless productivity aids.

In November 2025, researchers discovered that JSONFormatter and CodeBeautify had been storing everything users pasted into them via a save feature that generated shareable links with fully predictable URL structures. A simple crawler could retrieve all of them. 

They found over 80,000 files containing passwords, AWS credentials, Active Directory credentials, database connection strings, SSH session recordings, and API keys. Nowadays, developer tooling is part of the identity plane. The organizations leaving this data exposed spanned government, critical infrastructure, finance, healthcare, and cybersecurity. When they uploaded fake AWS keys to one of the tools, bad actors attempted to use them within 48 hours. The data was actively being scraped. 

The problem was that developers had been routinely pasting credentials into a public website while debugging, because that’s just what you do when you need to read a JSON blob quickly. In fast-moving engineering environments, developers will always reach for whatever gets the job done. You can’t govern your way out of that behavior, and trying to control every tool a developer touches is a losing proposition.

Instead, organizations should ask themselves if their identity and access policies account for where credentials end up. Not just the identities your IAM was written for, but for the tools those identities are touching each day. 

How Simple Developer Tools Become a Production Risk

Even a simple JSON formatting website can improperly collect and store sensitive credentials. The tool doesn’t have to be malicious for the outcome to be. The moment a token, session, or credential is exposed outside the environment it was meant for, the attacker is no longer dealing with a hardened perimeter. They are holding valid access. 

Once a token or credential is out in the open, an attacker has everything they need to start moving up the privilege chain:

1. The exposed token gives the attacker an authenticated foothold in whatever system it belongs to.

2. That token might have access to repository secrets and CI/CD configuration – and by extension, every deployment pipeline that depends on them. 

3. Inside those pipelines, attackers likely look for secrets that were hardcoded and never rotated. 

4. Those credentials allow role assumption in cloud environments, lateral movement across services, and eventually access to data management systems in the production environment. 

The JSON Formatter website is just one example. The same dynamic exists across browser extensions, clipboard managers, AI coding assistants, debugging tools, local config files, and anything else that can touch sensitive developer context. Modern engineering work spreads identity across a wide toolchain—including non-human identities like service accounts and automation credentials—and attackers only need one weak point in that chain.

In practice, that sensitive context shows up in more places than most teams like to admit: local AWS profiles, kubeconfigs, copied JWTs, CI logs, shell history, IDE extensions, browser storage, temporary files, session cookies, and AI prompt history. None of those systems were intended to be the place where identity risk is managed, but all of them can become the place where it is exposed.

What makes this particularly hard to detect is that stolen tokens initially look like legitimate API calls. There is no exploit payload or unusual request pattern that will trigger signature-based detection flags. The attacker, from the system’s perspective, is just a developer doing their job. 

Standing Access Turns a Leak into an Incident

Most developers hold standing, persistent access to sensitive infrastructure because they need it regularly. It’s the path of least resistance when you’re working across production systems and IT operations analysis in a fast-moving engineering environment. 

But a compromised token gives the attacker everything that token was already authorized to do. If a developer’s GitHub token has broad repository access and can trigger production deployments, an attacker with that token inherits that capability exactly. They don’t need to resort to privilege escalation; standing access turns every exposed credential into a pre-approved blast radius.

This is where least privilege often breaks down in practice. Teams may have IAM policies, role structures, and approval processes on paper, but permissions still accumulate over time because modern engineering work changes too quickly for manual access models to keep up.

Why Traditional IAM Doesn’t Close the Gap

Traditional IAM was built for a different environment. It assumes identities are centrally managed and that you’re defending a well-defined perimeter. These tools are designed to control who can authenticate and what an authenticated identity is allowed to do.

But most developers now work across a messy chain of local tools, cloud roles, orchestration layers, and delivery systems. On any given day, a developer may touch their IDE, Kubernetes contexts, GitHub, a CI dashboard, and a secrets manager. Each handoff creates another place where valid identity material can be exposed, copied, cached, or reused.

IAM policies govern what an authenticated identity can do. They say nothing about how that identity’s credentials might be harvested before the authentication handshake. The JSONFormatter attack doesn’t beat your IAM policy; it just steals the credentials that authenticate to it. Role-based access control, SSO, and MFA are all valuable controls, but they were all designed to govern access at the boundary. When an attacker is already operating inside that boundary using valid credentials, those controls offer limited protection.

The deeper problem is that IAM programs were designed around the assumption that access is a relatively static thing to manage. Security programs that can’t keep pace with the dynamic nature of modern engineering will always be working from an outdated access model.

Containing the Blast Radius with Ephemeral Access

There is an architectural solution to this problem, but it is not layering stricter policies on top of a broken access model. It is to make access less durable, less transferable, and less valuable when it leaks. That means shifting away from standing permissions and toward time-bound, task-scoped access that expires automatically.

Just-in-time (JIT) access ensures credentials only exist for a narrow task, for a limited period, and against clearly defined resources. Even when a token or session is exposed, the attacker’s opportunity is smaller, and the blast radius is easier to contain.

The key is making that model usable in real engineering work. Access needs to be self-serve enough for on-call and operational tasks, but still policy-controlled. Expiration needs to be automatic, not dependent on manual cleanup. Approvals should appear where risk justifies them, not as a blanket slowdown for every request. And every grant should be visible in a reliable audit trail.

That is the shift many teams still have not made. They treat privileged access as an exception workflow when it should be an operating model. Ultimately, JIT is not a replacement for identity governance or privileged access management. It is the operating model that makes least privilege workable in fast-moving engineering environments.

If engineers have to fight a slow approval chain every time they need production access, they will look for workarounds. Good JIT implementations cut that friction down enough that teams can use them during normal work.

Context-aware policy can sit further upstream, adding a check before access is granted at all, which is an essential control for supply chain risk management. JIT answers how long access should exist. Context-aware controls help answer whether this request makes sense right now. If someone is requesting access from an unusual location or in a way that does not match normal behavior, the request can be blocked before just-in-time access is granted. This is a fundamentally different posture than the “grant and forget” model that most engineering organizations have slipped into over time. 

Developer Tooling is Only Going to Get Riskier

The JSONFormatter incident will not be the last case of a trusted developer tool turning into an identity risk. If anything, it is an early signal of where this problem is heading. As engineering organizations rely more heavily on AI assistants, local automation, browser-based tooling, and machine identities, more systems will act on behalf of developers and production operators. 

You need to be thinking beyond what the developer can reach, to what their plugins, local environments, and AI-assisted tooling can reach on their behalf. Security teams should stop asking only who has access and start asking where that access can travel. Standing permissions are impossible to justify in these environments. The more tools that can touch identity, the less acceptable it is for powerful permissions to remain broadly available and continuously valid.

Modern Identity Risk Demands Ephemeral Access

The answer is not to slow engineers down or force them through brittle manual controls. It is to make access short-lived, contextual, and automatically reversible by default. In an environment where every developer convenience can become an identity exposure point, reducing standing access is no longer just good hygiene. It is one of the clearest ways to reduce blast radius without slowing delivery.

Developer tooling is now part of the identity attack surface, which means securing access can no longer stop at the login layer. Apono helps security teams replace standing access with just-in-time, policy-controlled access across cloud, Kubernetes, databases, and developer infrastructure. The result is that leaked credentials are less useful, access is easier to govern, and the blast radius is dramatically reduced. With Apono, teams can enable self-serve, granular access through Slack, Teams, or the CLI, with auto-expiring permissions and break-glass workflows. Download Why Standing Access Keeps Causing Breaches: A Practical Guide to Continuous Least Privilege to see how leading teams reduce standing access and contain identity risk. Or, book a demo to see how Apono enforces just-in-time access in practice.