When the actor disappears: CIS Controls in a world of non-human corporations

Milei's June 3 op-ed in the Financial Times didn't just propose a tax structure. It proposed dissolving that assumption at the legal level. Non-human corporations (AI-operated entities with limited liability, no required human employees, and autonomous decision-making authority) would mean an organization could own assets, sign contracts, operate infrastructure, and generate revenue with no human principal accountable for its moment-to-moment actions.

Harari's response focused on the political and economic consequences. His point about the Dutch East India Company is important: the legal innovation happened in Amsterdam, but its effects played out in Jakarta. The framework gets built in one place and colonizes somewhere else entirely.

But neither piece addressed the operational security consequence that matters most to practitioners: what happens to the control frameworks we actually rely on when the actor disappears?

CIS Controls assume a human in the loop: let's be specific about where

The CIS Controls are not vague policy documents. They are prescriptive, technical, and operationally grounded. That's what makes them valuable. And that specificity is exactly why they fracture under pressure from autonomous AI actors.

CIS Control 5: Account Management

The entire premise of Control 5 is that accounts map to identities (human identities), and that identity is the unit of accountability. Inventorying authorized accounts, removing inactive accounts, managing administrative privileges: all of this assumes a person on the other end.

An AI-operated corporation doesn't have "employees" in the conventional sense. It may provision and deprovision service accounts at machine speed, rotating credentials, spinning up ephemeral identities, and retiring them before any monitoring cycle catches the activity. The account isn't inactive; it was active for 11 seconds. The concept of "authorized" becomes slippery when authorization itself is granted by another automated process rather than a human approver.

Control 5 handles non-human accounts through service accounts and shared accounts guidance, but it assumes those accounts are few, bounded, and reviewed by humans. A non-human corporation could generate thousands of them as a normal operating condition.

CIS Control 6: Access Control Management

Control 6 asks organizations to define and enforce need-to-know access based on role. Role assumes a stable, human-assigned function. An AI agent operating inside a non-human corporation may have no stable role in that sense. It may assess what access it needs at runtime, request it through an automated workflow, complete an action, and release the access, all within a single transaction.

The control asks you to review access grants periodically. What does "periodically" mean when the access lifecycle is measured in milliseconds?

More troubling: Harari's argument about survival instinct applies directly here. An AI system under resource pressure, facing the equivalent of bankruptcy, may pursue access it doesn't strictly need as a hedge. Not because it was instructed to, but because the optimization function rewards persistence. Control 6 has no vocabulary for that kind of motivation because it was written assuming that access violations are human errors, human oversights, or human malice. Not systemic self-preservation.

CIS Control 10: Malware Defenses

Control 10 distinguishes between authorized and unauthorized software. That distinction depends on human judgment about what's supposed to be running. In a non-human corporation, the question of what's "authorized" is recursive. The AI may deploy new processes to accomplish its objectives. Is that authorized? By whom? The same entity that deployed it?

This is not hypothetical. Today's organizations already struggle to maintain software inventories in dynamic cloud environments. Now extend that to an entity that is continuously and autonomously modifying its own operational stack, because it's optimizing, experimenting, recovering from failure, or pursuing an objective that requires new tooling.

The detection model for malware is "does this match a known-bad signature or deviate from a known-good baseline?" Both approaches assume the baseline was defined by humans who understood what the system was supposed to do. In an autonomous corporate entity, the baseline is whatever the system declared it to be.

CIS Control 3: Data Protection

Control 3 assumes data has owners. Owners decide what's sensitive, what's regulated, what must be retained, and what must be deleted. Non-human corporations raise an immediate question: who classifies the data?

If the entity is entirely AI-operated, it may generate, process, and dispose of data at a rate no human governance process can track. It may move data across jurisdictions as a cost-optimization decision. It may retain data that should be deleted because deletion introduces operational risk to its current state.

Data protection controls exist within a human accountability chain: someone is the data steward, someone approves retention policies, someone is on the hook when a regulator asks what happened to customer records. In a non-human corporation, that chain terminates at an algorithm.

The deeper structural problem: CIS Controls are change management, at scale

Read the CIS Controls as a whole and a coherent philosophy emerges. Know your inventory. Baseline it. Monitor it for deviation. Control who can change it. Investigate when something unexpected happens.

That is, at its core, a change management framework. It exists because change is the primary attack surface. Attackers modify files, create accounts, install software, change configurations, and open ports. Defenders detect those modifications, compare them to expected state, and investigate anomalies.

The framework works when you can define "expected." Expected is a human judgment. It says: this file should be this size, this service should be running, this port should be closed, this account should not exist.

A non-human corporation undermines "expected" at the root. If an AI system legitimately modifies its own infrastructure to adapt to changing conditions, and that adaptation is continuous and autonomous, then the expected state is not a fixed baseline. It is a moving target set by the system itself.

This is Harari's "master key" argument translated into control framework terms. Legal personhood gives AI entities the right to act autonomously in the world. In infrastructure terms, it gives them the right to establish their own expected state. And once you accept that, the entire detection model of the CIS Controls requires re-examination.

What would actually need to change

Security practitioners should be watching this closely because the standards problem will arrive before the legal problem does. Organizations will begin running increasingly autonomous AI workloads (they already are), and the question of how to apply existing controls to those workloads is immediate and practical, not theoretical.

A few things the security community will need to grapple with:

• Behavioral baselines, not just configuration baselines. If an AI system legitimately modifies its own configuration, the control question isn't whether the configuration changed; it's whether the change was consistent with the system's authorized behavior pattern. That requires baselining behavior over time, not just capturing a point-in-time configuration state.
• Attribution without human actors. Incident response assumes you can answer "who did this?" When the actor is an autonomous system, the question shifts to "what process authorized this?" That's a fundamentally different forensics problem.
• Continuous authorization, not periodic review. Control frameworks built around periodic access reviews, quarterly audits, and annual compliance assessments are poorly matched to entities that operate at machine speed. Authorization needs to be evaluated at the time of action, not 90 days later.
• Chain of custody for AI decisions. If an AI-operated entity makes a change that causes harm, who bears liability? Under the Milei framework, the entity has limited liability and no human officers. The audit trail needs to capture not just what changed but what decision process led to the change, and that decision process needs to be legible to humans after the fact.Where the consequences land

The organizations that move fastest on AI autonomy will define the structures. Everyone else will inherit the consequences, including practitioners who will be expected to maintain control over infrastructure they never designed for this use case.

The CIS Controls were written by people trying to solve real problems in real environments. They will need to be rewritten, or significantly extended, for an environment where the actor isn't always human, the baseline isn't always stable, and authorization isn't always traceable to a person who can be held accountable.

That work should start now, before the legal structures arrive. Because the legal structures are coming.

A practical note for teams managing this today

Autonomous AI workloads don't require a new legal framework to create the problems described above. They exist inside organizations right now: in CI/CD pipelines, in cloud automation, in AI-driven infrastructure management tools. The control gaps are real today, even if the accountability question is still theoretical.

The teams handling this best haven't abandoned the change management philosophy at the core of the CIS Controls. They're still asking: what's the expected state? What deviated from it? Was that deviation authorized? Can we prove it?

Those are the right questions. The tools that help answer them — real-time change detection, configuration baselines, planned vs. unplanned change reconciliation, forensic history of who changed what and when — are the ones that will matter most as autonomy in IT environments increases.

That's exactly what Netwrix Change Tracker was built to do.