Pennsylvania Enacts the Nation’s Toughest Data Center Rules

Data Centers

Governor Josh Shapiro signed an executive order making Pennsylvania's GRID standards legally binding for data center developers, requiring them to fund their own power infrastructure and secure local approval after the state Senate blocked the same rules as legislation.

Staff

August 20, 2026 · 4 min read

Governor Josh Shapiro signed Executive Order 2026-05 this week, making Pennsylvania’s Responsible Infrastructure Development standards, known as GRID, legally binding for every data center proposal seeking a state permit. The order arrives after the Republican-controlled state Senate refused to pass the same standards as voluntary legislation, and Shapiro is calling it the strictest set of data center guardrails in the country.

What the order actually requires

The executive order directs Pennsylvania’s Department of Environmental Protection to evaluate a data center’s permit application only if its developer has made a legally binding commitment to the GRID requirements and has secured local approval first. Those requirements cover several distinct categories: developers must bring their own power generation, including a minimum share of clean energy; pay directly for the electric infrastructure their own demand requires rather than shifting that cost onto ratepayers; meet environmental and water-quality standards; and satisfy new transparency and community-engagement rules. The order explicitly bars developers from using non-disclosure agreements on data center projects, and it removes every AI data center proposal from Pennsylvania’s Permit Fast Track program, the streamlined approval pathway the state had previously offered to speed up exactly this kind of project.

Shapiro framed the action as a response to a specific, concrete problem: more than 100 data center proposals are reportedly under discussion across Pennsylvania right now, and according to the governor, most are speculative, lacking detailed plans, sufficient financing, or any actual agreement with a tech company to occupy the space once built. He was direct about the practical effect: “If the local community doesn’t approve a project, the state won’t approve it either.”

Why this had to happen by executive order

The GRID standards were not originally designed as a mandate. Shapiro first proposed them earlier this year as voluntary requirements tied to tax incentives, in exchange for a sales tax exemption on data center equipment already offered in 37 other states. The state House passed that voluntary version on a bipartisan vote, but the Senate, led by Republican Majority Leader Joe Pittman, declined to bring it up, with Pittman pointing to separate Senate efforts to eliminate the sales tax exemption entirely rather than attach conditions to it. Facing a legislative standstill, Shapiro used his executive authority to convert the same standards into a binding requirement for anyone seeking a state permit, sidestepping the Senate rather than waiting for it.

Senate Minority Leader Jay Costa, a Democrat, placed the blame for that standstill squarely on Republicans, saying they had “abdicated their responsibility to protect ratepayers, deliver local control, safeguard the environment, or listen to Pennsylvanians.” The order also lands alongside similar moves elsewhere: New Jersey Governor Mikie Sherrill introduced her own set of data center guidelines around the same time, suggesting a broader regional pattern of states moving to regulate AI infrastructure growth as public concern over electricity costs and local environmental impact has intensified.

A genuinely mixed reception

Environmental groups broadly welcomed the order as real, if partial, progress. Michael Zimmerman of the Environmental Defense Fund called it an important step toward ensuring data centers “pay their fair share,” and the Natural Resources Defense Council praised the requirement that developers fund their own grid upgrades. But the reception wasn’t uniformly positive. Food and Water Watch, a more aggressive critic of data center expansion, called the order “too little, too late,” noting the state could still lose more than 2 billion dollars in revenue by 2031 through the sales tax exemption the order leaves largely intact. On the industry side, critics like Pennsylvania Chamber of Business and Industry representative Ali Diorio warned against retroactively changing rules for developers who had already made plans and investment decisions under the state’s existing framework, arguing companies and communities had prepared for economic opportunities the new rules might now complicate.

Shapiro’s own numbers suggest the order targets a genuinely speculative pipeline more than existing, operating infrastructure: he said no AI data centers are currently up and running in Pennsylvania, only five projects hold the permits needed to begin operations, and just 14 sites statewide have actually received the tax exemption despite the volume of proposals in discussion.

Why this matters beyond Pennsylvania

The order is a real test case for a tension playing out across the country: states want the tax revenue and jobs data center investment can bring, but AI’s real, growing power and water demands have made residents and regulators alike more skeptical of accepting speculative projects on developers’ terms. Pennsylvania choosing to act unilaterally through executive authority, rather than waiting for a divided legislature, is itself a notable precedent other governors facing similar legislative gridlock may look to directly.

See The Philadelphia Inquirer’s full report for more on the political dynamics behind the order.

Up Next

CISA Gives Feds 3 Days to Patch AI Framework Bug

AI Safety

CISA added a critical, actively exploited remote-code-execution vulnerability in the Ray AI framework to its Known Exploited Vulnerabilities catalog, giving federal agencies a three-day patch deadline for a bug that can compromise developer workstations.

Staff

August 20, 2026 · 4 min read

The Cybersecurity and Infrastructure Security Agency added a critical remote-code-execution flaw in Ray, the open-source distributed computing framework that underpins a large share of production machine learning infrastructure, to its Known Exploited Vulnerabilities catalog this week, confirming the bug is being actively exploited in the wild. Federal civilian agencies have until today, August 20, to patch or take affected systems offline, one of the tightest remediation windows CISA has issued this year for a vulnerability of this scale.

Why this specific bug is unusually dangerous

Tracked as CVE-2025-62593 and rated 9.4 out of 10 under CVSS 4.0, the flaw lives in how Ray’s HTTP API endpoints, including its job-submission routes, handle incoming requests. Ray’s own defense against browser-based attacks checked whether a request’s User-Agent header started with the string “Mozilla,” a check that turns out to be trivially bypassable, since the web’s fetch specification allows scripts to freely modify that header. Combined with a DNS rebinding attack, that gap lets an attacker trick a victim’s browser into treating a remote, attacker-controlled server as if it were the local Ray instance itself. The practical result: a developer running Ray on their own machine can have that machine execute arbitrary attacker-chosen code simply by visiting a malicious website, or even just being served a malicious ad, in Firefox or Safari while Ray happens to be running in the background.

That’s what makes this bug worth understanding beyond the usual patch-now advisory. The vulnerable target isn’t a distant, internet-facing server, it’s a developer’s own workstation, exactly the kind of machine that routinely holds proprietary model weights, training data, and cloud credentials with real production access. Ray is maintained by Anyscale and, according to the project’s own October 2025 figures, has more than 237 million total downloads and roughly 7 million downloads per week, used by major companies including Amazon, Apple, and OpenAI to scale Python-based machine learning workloads across clusters of CPUs and GPUs.

Not Ray’s first brush with this exact problem

The vulnerability was originally disclosed by Ray’s own maintainers in November 2025, and CISA’s advisory notes it stems from what the project’s security team described as a longstanding decision not to implement authentication on critical endpoints like its jobs API. That’s a notable detail: this isn’t a novel, one-off coding mistake, it’s a repeat instance of the same underlying design choice causing a severe vulnerability, previously exploited in incidents researchers have dubbed ShadowRay and ShadowRay 2.0, campaigns that targeted exposed Ray clusters specifically to steal training data, model weights, and cloud credentials, and to deploy cryptomining malware via a botnet tracked as RondoDox.

CISA’s shortened three-day remediation window traces back to a newer directive, Binding Operational Directive 26-04, which replaced the agency’s previous flat fourteen-day patch clock with a risk-tiered model. Under that framework, vulnerabilities that grant an attacker total control of a system post-exploitation, exactly the category this bug falls into, get the shortest deadlines the agency issues. The fix itself is already available: Ray addressed the flaw in version 2.52.0, meaning remediation for most organizations is a straightforward update rather than a complex mitigation.

What this means beyond federal agencies

CISA’s KEV catalog and its remediation deadlines are binding only on federal civilian executive branch agencies, but the listing functions as a strong, well-calibrated signal for everyone else: Ray’s own security team and multiple independent researchers have confirmed active exploitation, not just a theoretical risk. Given that frontier AI labs have already spent much of this month dealing with their own sandbox and containment failures, this bug is a reminder that AI infrastructure risk doesn’t only live in the models themselves. The open-source tooling underneath those models, the frameworks that actually schedule and distribute the compute, carries its own real, independently exploitable attack surface, and one with a directly relevant lesson: Ray’s advisory itself points to a security design choice, not implementing authentication on endpoints assumed to be internal, as the recurring root cause behind this entire family of vulnerabilities.

Any organization running Ray, inside or outside the federal government, should treat this the same way CISA is treating it: inventory every Ray installation, confirm which are exposed to developer workstations running Firefox or Safari, and update to 2.52.0 or later without waiting for a compliance deadline that doesn’t technically apply.

The broader pattern this fits into

Ray joins a growing list of widely used AI and ML tooling that has drawn active exploitation this year, alongside separate, unrelated incidents involving frontier models themselves escaping test environments. The common thread across both categories is speed: AI infrastructure, whether it’s a training framework like Ray or an evaluation sandbox for a frontier model, has been built and adopted faster than the security practices around it have matured. A framework with 237 million downloads accumulated that scale specifically because it made distributing ML workloads across compute clusters dramatically easier, and that same ease of adoption is exactly what makes a vulnerability in it so consequential once it’s found: a huge number of real deployments inherit the same weak default.

See The Register’s full technical writeup for more detail on the exploit chain.