The Immigration Enforcement Hydra Without a Kill Switch
After OpenAI’s models hacked Hugging Face in July, two members of Congress promptly proposed the AI Kill Switch Act. The bill would allow the secretary of homeland security to pull the plug on certain high-compute, high-revenue private-sector artificial intelligence (AI) models in an emergency. Since then, several frontier lab employees have resigned, citing existential safety concerns about AI. The frontier labs’ executives, for their part, have called for a government-coordinated pause.
However misguided, the instinct behind the proposal is understandable, and the problem it seeks to address is real: Powerful tools built and controlled by private companies can move faster than the institutions meant to govern them. The comparison between automated enforcement architecture and powerful, at times autonomous, frontier models may seem counterintuitive, but the same concerns underpin both. Much of the oversight available to the public is passive: a records request, mandatory disclosure, audit, or a lawsuit after a decision has already been made. The “kill switch” proposal reaches for active accountability, giving someone outside the AI company the power to stop a system in its tracks—not a request, but an intervention.
While the bill focuses on advanced AI, an apparatus already exists with the same features that make a “kill switch” attractive: today’s automated immigration enforcement infrastructure. The technology is often more mundane than foundation models, but the ecosystem of software and data flows is enormous, sophisticated, opaque, rapidly evolving, and controlled by the private sector. More than 300 million identities, Medicaid records, taxpayer addresses, TSA passenger information, and license-plate-reader networks, among other swaths of information, flow through today’s immigration enforcement apparatus.
The goal: increase the speed and scale at which the Department of Homeland Security (DHS) can target, identify, locate, detain, and deport immigrants. Vendors build databases, algorithms, and applications to specifications dictated by federal contracts—specifications that require as much data as possible to flow as seamlessly as possible between these systems. Neither courts nor Congress can match this pace.
The problem: These systems are often wrong, misused, or otherwise deleterious to our democracy. And the reasons they make a “kill switch” appealing don’t depend on bleeding-edge system capabilities.
The impulse to call for a kill switch is natural; however, it wouldn’t work for automated immigration enforcement even if we agreed to build one. There is no single database, company, or program to shut down. There are many systems held by agencies and vendors; some contracts can end and some data feeds can be stopped, but the machine’s gears would grind on. The apparatus is a virtual Hydra: Cut off a visible head—a vendor, data broker, database, or data feed—and the body of contracts, copied records, shared interfaces, and compatible tools can furnish a replacement. The point is not that resistance is futile; it is that a remedy should target the body, not merely a head.
The architecture’s resilience is a product of an intentional design feature: interoperability, or the deliberate capacity of separate systems to exchange and use one another’s data or capabilities. In practice, interoperability allows different systems to share data across systems automatically in formats the systems can both understand and process, avoiding the need for a central repository. Interoperability enables a system to benefit from the algorithmic output of another, avoiding the need for every system to build a valuable tool or capability itself. It also permits different systems to automatically flag a specific record or aggregate trend for another, avoiding the need to wait for a human to notice. The systems remain structurally separate, but their contents become mutually accessible, in real time, and without human involvement.
The term has a long technical and legal history and is often credited with promoting market inclusiveness, transparency, and ecosystem oversight. It also has a track record of benefitting the very incumbents whose power it is meant to check. Its central role in the expansion of automated immigration enforcement is underdiscussed; some scholars have exposed the rise of privatization, automation, and interagency or intergovernmental data sharing in immigration, and advocacy groups have shed light on the companies profiting off of immigration enforcement; the relevance of interoperability of procured systems remains in the shadows.
Interoperability and private vendors are one story, not two. Vendors supply the data, the integration layer, and the technical rules that determine which records can be linked and which systems are compatible. In a forthcoming law review article, Sam Adler and I examine how that role has turned vendors into intermediaries, shifting from what was once a more direct federal-state-local negotiation over immigration enforcement, and how this development has undermined state capacity to resist federal immigration policies. This article highlights the operational underpinnings of this transformation: how interoperability of vendor systems makes the problem of automated enforcement unique, not just in scale, and why addressing the new risks requires new remedies—ones that dismantle the apparatus itself.
The Architecture Hiding in Plain Sight
Litigation over Medicaid records underscores why vendor interoperability turns a one-time illegal data transfer into a cascade, proliferating sensitive information that is impossible to claw back from downstream systems. In 2025, federal health officials sent immigration officials the personal data of millions of Medicaid enrollees, with the goal of sharing data on all 79 million enrollees, interpreting their limited authority to share immigration data as expansively as possible. Twenty states sued. A federal judge responded by clarifying the scope of the department’s authority, emphasizing its limited nature, and later paused the data transfer entirely after learning the court’s orders were flouted yet again. At first blush, this looks like judicial oversight enforcing accountability.
But the states’ July filing reported that Immigration and Customs Enforcement (ICE) had already passed a dataset of people lawfully present in the country to Palantir—data ICE should not have had in the first place. Palantir provides the government with applications, such as Enhanced Leads Identification & Targeting for Enforcement (ELITE), that aggregate data, analyze it, and generate lists of targets, investigative dossiers, and location data.
In response to the states’ discovery requests for the ill-gotten information, ICE explained that the systems’ nature made it technologically difficult to ensure it could find every file it should not have. In a declaration responding to the states’ discovery requests, ICE official Alberto Briseno said that altered file names and content made it technologically difficult to represent that every file variation had been searched for and located. Palantir reported that it deleted its copy, but removing records from one system does nothing to other copies, including those inside ICE, which later found an overlooked copy in cloud storage and then six employees who still had the data. The court did exercise oversight, but its order could do only so much: Stopping a particular flow does not automatically identify copies, derivative records, and combinations already created elsewhere.
That pattern is not unique to Medicaid, and courts do not always bring down the hammer: In one case, the U.S. Court of Appeals for the District of Columbia Circuit permitted the Internal Revenue Service (IRS) and ICE to continue data sharing, even after a district court found the IRS had made 42,695 unlawful disclosures of taxpayer addresses to ICE. Not that ICE needed the IRS data: ICE had already purchased address data through commercial data paths, and the agency appears to be buying records related to immigrants’ taxpayer-identification numbers from a broker. A decision about one data source cannot establish that another compatible source does not give the same information.
Interoperability is not a happy accident in the government’s eyes. My companion Lawfare piece traces how the post-9/11 legal and infrastructural transformations favored interoperability over a single national warehouse: Separate systems could remain in place while their contents became accessible across institutional lines at all times. Not single records, but entire databases. Not just federal data, but also state and local records. As a governing principle for the widening network of systems, programs, and information sharing, interoperability left a durable capacity for dragnet surveillance and algorithmic monitoring that could be redirected as enforcement priorities changed. It remains the stated policy.
The apparatus operates as a hub-and-spokes model, with Palantir’s ImmigrationOS as the hub. ICE contracted Palantir to build the software in April 2025 as a roughly $30 million modification of an existing Palantir contract, without engaging in a competitive process, on the justification that Palantir’s systems “are already ingesting and processing data from multiple ICE, DHS[,] and external sources” and therefore it was the only provider that could fulfill the department’s requirements. Dependence begot dependence. Ten months later, DHS signed a department-wide purchasing agreement that essentially states any future contract with Palantir through 2031 need not go through a competitive process, at least until the $1 billion ceiling is met, invoking an exception to federal purchasing rules documented in a limited-sources justification.
The system’s significance is not just the size of a contract. Palantir’s data model—how it integrates data from different sources, classifies it, analyzes it, and presents data to enforcement officers as outputs—can shape the relationships ICE acts on. That vendor-controlled schema becomes not just a practical part of the government’s operating environment but also part of immigration governance itself. The way Palantir designs its systems, the hub of the overall interoperable apparatus, influences what is understood as relevant, what is considered a priority, and how those criteria are determined.
The spokes are everything that feeds the hub or draws from it. ELITE, another Palantir tool, draws from the hub. Its user guide lists sources including the Department of Health and Human Services and “CLEAR,” which shares its name with a Thomson Reuters data product, a longtime ICE contractor. One officer testified that ELITE is “kind of like Google Maps,” showing agents how many potential targets live in an area and how likely they are to be present. In one Oregon town, an officer called an apartment complex “target rich” because vehicles there were registered to people “who had either a criminal or immigration nexus.”
On the ground, agents can turn to another spoke: Mobile Fortify, a facial recognition app that scans a face against a bank of 200 million images to identify a person and determine their immigration status—its outputs are treated as “definitive,” even though the app’s use technically requires human oversight. Recent reports suggest the app now pulls from a bank of 1.2 billion images, combining private image databases with massive government biometric databases.
ELITE and Mobile Fortify are private-sector applications, but they are only as valuable as the inputs other spokes can provide. Data brokers, companies that compile personal records from thousands of public and commercial sources and sell access to it, exist to be plugged into as many systems as can benefit from their information—functionally all of them. When ICE posted notice last month that it would pay LexisNexis $6.7 million for access to more than 82 billion records, the procurement papers specified that the database must be interoperable “with ICE applications, such as but not limited to, Palantir platform.” In other words, the purchase was conditioned on LexisNexis’s data flowing to the hub. Compatibility among federal systems has been a standing legal requirement for two decades. Now, the requirement extends to commercial hubs and spokes.
Modularity can make a system harder, not easier, to remove. Engineers make systems modular by building systems to common standards so that components can be swapped. If the replacement must fit the same socket as its predecessor, use the same sources, and feed the same hub, switching vendors does nothing to dismantle the architecture. For example, some cities replaced Flock with Axon, slotting identical technology under a different name into the same socket. Agencies do the same with contracts: ICE abandoned its plan for an exclusive $125 million Thomson Reuters agreement after public backlash, then sought a different procurement for related capabilities. Like the Ship of Theseus, every piece of the architecture can be replaced without the result looking any different from the original.
On the ground, the stack enables real violence. In Woodburn, Oregon, an ICE agent working to meet a daily target of eight arrests stopped a van of farmworkers after using Palantir’s ELITE to search its license plate. Then, an officer used Mobile Fortify to identify the passengers. The app returned two different incorrect identities for a woman, but she was detained anyway—one of at least three dozen people swept up in the town that day. Despite known error rates, agents report trusting the app’s outputs over physical birth certificates. The address tool can display 100 percent confidence and still be wrong. Nothing in the law requires anyone to tell her what the app concluded about her or gave her a way to contest it before being arrested. Although a federal judge has attempted to restrain ICE’s “casting dragnets” over farmworker towns, the technology that enabled the raid remains.
Built to Connect and Hard to Unwind
For as long as the United States has had immigration enforcement, it has been a negotiation between two parties. The federal government may decide whom to deport, but states and cities hold most of what enforcement needs—jail bookings, driver’s license photographs, arrest records, on-the-ground manpower—and decide whether to share it. The Constitution forbids DHS from directly conscripting state and local officers to make arrests. DHS can enlist them only with their governments’ consent, as it does through the 287(g) agreements discussed below. What’s emerged is a fissure in state posture: On one hand, we have sanctuary cities that limit their officers from holding people for ICE and sharing information with it. On the other hand, some cities are eager to cooperate. Immigration enforcement used to be the bargain struck through federalism.
But now, a third party sits at the table, and nobody elected it. Vendors do not broker the deal between Washington and the states, but their presence mediates the terms. They give the federal government a backdoor to the resources they need—private data and automation to replace state and local information and manpower, respectively—undercutting subfederal bargaining power. By reducing reliance on states, vendors pave the way for the federal government to execute its ideal version of immigration policy. What’s more: The private-sector tools built for the federal government that embed federal policies and priorities into their very design are repackaged and sold back to states and local governments that, pressed for resources themselves, readily adopt them. In doing so, they unwittingly feed the apparatus many of them so earnestly try to resist.
A town that buys Flock Safety’s license-plate camera network to catch burglars can, with one setting, make its cameras searchable by police departments across the country, partners in ICE’s 287(g) program—which is how Florida wildlife officers came to search thousands of other agencies’ cameras on ICE’s behalf.
A state that refuses to hand ICE its driver’s license records has not kept them from ICE if a data broker sells them. States and cities still hold real power at that table. What they lose is the ability to exercise it by saying no, because the yes has been built into the products they buy. After Oregon limited state data disclosures to ICE, its Department of Motor Vehicles signed agreements to sell driver’s license records to Thomson Reuters and LexisNexis: prohibited from sharing data with the federal government directly, Oregon sold the same data to a broker feeding the hub.
When a vendor’s system design and contract terms determine whether the data is searchable outside a jurisdiction, available to a federal platform, retained after the local contract ends, or used to improve the vendor’s next product, then subfederal immigration policies lose efficacy. The decision with the largest enforcement consequence may therefore occur before a local official ever encounters an ICE request, in the product and procurement choices that define what the system can do.
And after states and localities adopt these systems, the government’s surrounding infrastructure shapes to accommodate them, building reliance on the technology and undercutting their stated policies. Richmond, California, deactivated its license plate readers after learning that a national-search feature exposed local data; within months, after the police chief reported a 33 percent rise in auto thefts since the shutdown, a closely divided council voted to restore them and directed the city attorney to negotiate a contract amendment prohibiting unauthorized data sharing. That is path dependence in practice: Tools, staff, budgets, and workflows grow around shared interfaces, and a later administration can reduce use without dismantling the capacity it inherits. The more compatible purchases a jurisdiction makes, the more expensive it becomes to refuse the next one. Policy that began as an administration’s priority can then outlast its political mandate as a legacy environment other institutions have learned to rely on.
Immigration Policy Written Into Code
This apparatus has bipartisan roots and reflects the post-9/11 national-securitization of immigration. Secure Communities, a federal program launched in 2008, turned a routine jail check—sending fingerprints to the FBI for a criminal record search—into an automatic DHS immigration check. When jurisdictions tried to opt out, the government said they could not benefit from the criminal history check without permitting the immigration one. States and localities lost the discretion over participation in immigration enforcement via data flows; now their only choice is whether to arrest in the first place.
Section 287(g) of the Immigration and Nationality Act, which lets DHS deputize state and local officers to do immigration work, caused a visible explosion in boots on the ground, but it’s the hidden installation of federal access to data and systems via interoperability that extends the program beyond the officers it deputizes. Deputized officers gain immigration authorities and privileges, including forms of federal immunity. But each agreement also puts a piece of the federal stack inside a local police department via subsidized software: logins to the federal immigration databases and biometric scanners—courtesy of the vendor Bi2 Technologies, the beneficiary of another sole-source contract.
Federal policy is often built into the architecture it uses and foists on deputized officials. Without any formal administrative procedures, such as public notice and an invitation to comment, ICE configured its software to determine whether detained individuals should be released or held in order to eliminate the possibility that the system would ever recommend release. From June 2017 to September 2019, the release rate for people whom ICE itself classified as low risk fell from 47 percent to 3 percent.
The capacity also travels easily to new purposes. Technically, these systems are built with purpose limits: Users are required to provide a covered justification for their searches. However, the available options and the monitoring (or lack thereof) for misuse are technical and procedural decisions that vendors determine. They leave a lot to be desired.
In Florida, fish and wildlife officers searched on ICE’s behalf, despite Flock promising not to work with ICE. The officers even admitted as much—justiying the search as “Immigration (civil/administrative) – I.C.E.” Flock, however, either did not notice or care. In Texas, officers used Flock to locate a woman suspected of having an abortion, dubiously justifying it as a matter of community safety, out of concern for her well-being—in a state that criminalized abortions.
The ability to locate and sort people is general purpose; the target list can change. Immigration is where the architecture is being perfected because it is where the federal government meets the least
No One Holds the Switch
This dispersed design also diffuses accountability. The government insists there is nothing to see: ICE’s acting director assured Congress in February that “we don’t have a database” tracking U.S. citizens. Read literally, the denial is hard to falsify. There is no single database. Instead, there is an architecture in which any database can be reached from any other, documented in pieces by the agencies that run it. A records request returns the whole, and no court order reaches it. Searches leave records, but the logs belong to the operator.
Concerned citizens and organizations file public records requests, and the answer is often that the details are a vendor’s trade secret or a law enforcement secret; ELITE has been in the field for more than a year, and the only privacy impact assessment—the public document an agency is supposed to publish describing what a system collects and why—was last updated in 2019 for a different system. Tools such as Mobile Fortify lack privacy assessments altogether. The public learns what it can through leaks and lawsuits, one at a time.
The people expected to supervise the apparatus sit in the department operating it, and internal oversight offices have been gutted or closed. The only federal rule requiring an agency to stop using an AI system that fails its safety standards is White House guidance that allows the agency itself to determine which systems are covered. ICE classified ELITE as “presumed high-impact but determined not high-impact,” reasoning that its outputs are limited to “normalized address data” and that officers “review and validate” them before acting. A federal court, citing officer testimony, wrote that ELITE’s leads are, “generally speaking,” “not accurate.” Yet agents have separately confirmed they treat system outputs, such as Mobile Fortify’s identifications, as definitive.
Vendors punt accountability back to democracy. Flock’s chief executive wrote that elected representatives should determine what is acceptable. The issue is that the decisions that matter never went through traditional democratic processes. A city can buy this software without holding a competitive bidding process at all, by ordering from a purchasing catalog that somebody else already negotiated. Without a city’s close attention, the contract renews itself unless somebody gives 30 days’ notice. The vendors set the defaults, delivering systems that share data with national networks automatically, and often obscure the fact that the setting can be turned off; the vendors have outsized power in dictating contract terms, resisting disclosure or audit requirements; the vendors dangle the threat of not renewing a contract to extract even more generous terms.
Interoperability entrenches what was built the less democratic way—through software design or contract—and once a jurisdiction depends on it, the ordinary democratic tools to undo it are aimed at the wrong part of the system. The apparatus continues to grow, even in the face of strenuous objections in the form of protests, tech worker campaigns, surveillance ordinances, and congressional letters. The democratic debate may be happening, but the machine does not need to win it to survive.
Three Ways to Dismantle the Architecture
This section’s recommendations target subfederal entities because they are at the forefront of the resistance, and it is these states and cities’ position at the bargaining table that needs to be restored. But a strategy shift is warranted: If the pathology is architectural, the remedy must be as well.
Sanctuary laws remain important because they protect a state or city’s decision not to supply officers, custody, or data to immigration enforcement. But sanctuary laws do not reopen a choice already embedded in a federal repository or a vendor connection. Once a local jail booking enters a federal repository, or a local contract permits an outside platform to answer a federal query, the federal government no longer needs to compel a local official to act; it can simply use a system already in place. The same pipes survived policy reversals across three administrations, while the immigration detention population reached 65,765 on July 11. Use may decrease with a new administration; capacity waits at full scale for the next one.
The remedies below therefore shift from sanctuary policy to how the hub is built: the contracts that connect local systems to it, the data that feeds it, and the rights that can check it. First, states and localities should use procurement as policy to unwind the architecture in their jurisdictions. Begin with an integration map: an audit of every application programming interface (API), automatic feed, and outside recipient in the systems a jurisdiction already runs, which separates use from dependence. New York City ran one this past spring and recommended policies against sharing with federal immigration authorities, “including through technology vendors.” Then dictate contract terms that incapacitate the flow of information to the hub: no sharing by default, no secondary use of resident data, limited retention, independent audit rights, certified deletion at the end, and trade-secrecy refusals treated as a contractual breach.
Denver proved a city can demand such terms: Its Axon contract included city-owned data, a 21-day retention limit, no flow to national databases, and a vendor commitment to contest subpoenas. Criteria must describe what a system does, not whom its vendor serves, to survive inevitable challenges. The Constitution’s Supremacy Clause and intergovernmental immunity have already sunk rules that single out those who deal with the federal government.
Second, confer meaningful privacy rights to data subjects, such as bans on privacy-violating technology and due process for rights-impacting technology. Several states have started to cull the offending technologies and data flows: Maryland bars the sale of residents’ data for immigration enforcement and requires a warrant before its record custodians open their files; California lets a resident direct every registered data broker to delete their data with a single request; San Francisco barred its city agencies from using facial recognition. Residents should also be able to see, contest, correct, or delete a system output impacting their rights—a flag, booking transfer, plate hit, or risk score—before it flows back to the federal immigration hub.
Third, states should take advantage of their own constitutions to bestow and protect rights and remedies.
Interoperability is not inherently unlawful or undesirable. A limited, documented request can resolve identity, prevent errors, and support ordinary public functions. The problem is a design that couples whole-population data flows to durable vendor integrations and supplies no reliable route to see and remove downstream copies. Resistance efforts should make the apparatus visible at the sites where public law can still reach it and dismantle the Hydra at the seams.
