The AI Divide Will Be About Permission, Not Access
What Corporate Restrictions on AI Agents May Tell Us About the Future of AI Capability
Published:
On X and other social platforms, I have seen variations of the same argument: powerful coding agents should not be made available to everyone inside a company. The reasoning is usually that less experienced users may expose credentials, approve dangerous commands, install an untrusted tool, connect a malicious MCP server, or let an agent make changes they do not understand.
I cannot verify the individual stories attached to those posts. A claim that one CTO blocked a company-wide rollout may be accurate, exaggerated, incomplete, or invented. A social-media anecdote is not evidence of a broad trend.
The argument is still worth examining because its underlying logic does not depend on any one anecdote being true. If an ordinary private company has rational reasons to limit who may use an AI system with access to code, credentials, networks, and tools, larger institutions will have at least as many reasons to control more powerful systems.
That does not mean AI will disappear from public use. A more plausible division is subtler: almost everyone may have access to an AI assistant, while only selected people and organizations are permitted to use AI with the authority, data, tools, compute, and autonomy needed to change the real world.
The future divide may not be between people who have AI and people who do not. It may be between those allowed to use AI as an adviser and those allowed to use it as an operator.
Companies Have Rational Reasons to Restrict Agentic AI
A conversational model that answers questions is one thing. An agent that can inspect repositories, modify files, run commands, browse the web, call external services, and act through organizational accounts is something else.
The security architecture of current coding agents already reflects that distinction. Anthropic documents Claude Code as read-only by default, with explicit permission required for actions such as editing files and executing commands. Its security guidance also describes sandboxing, restricted write scope, network controls, trust checks for new codebases and MCP servers, and organizationally managed settings. Anthropic's Claude Code security documentation explains those controls.
OpenAI likewise warns that prompt injection can cause an agent to disclose private data, call tools in unintended ways, or take actions that do not match the user's intent. Its guidance recommends constraining tool access, treating external content as untrusted, and adding human approval at consequential steps. OpenAI's agent safety guidance describes these risks and mitigations.
NIST's Generative AI Profile treats generative-AI risk management as an organizational responsibility across design, development, deployment, use, and evaluation rather than as a problem solved by telling individual users to be careful. NIST publishes the profile as a companion to its AI Risk Management Framework.
From a company's perspective, the concern is therefore not irrational. A single mistake can expose confidential information, damage production systems, create legal liability, or make it impossible to determine who authorized an action. The more capable the agent, the more seriously an organization must consider permissions, isolation, logging, approval, and recovery.
The mistake begins when this real security problem is reduced to a crude social category such as “engineers may use it” and “non-engineers may not.”
The Correct Boundary Is Capability, Not Job Title
Engineering status is a weak proxy for safe use. An experienced engineer with unrestricted production credentials can cause far more damage than a non-engineer working inside a read-only, disposable environment. A careful beginner can operate safely within a narrow boundary. A senior specialist can behave recklessly when the boundary is absent.
The relevant questions are more concrete:
- What data can the system read?
- What files, accounts, and services can it modify?
- Can it reach the public network?
- Can it install or invoke third-party tools?
- Can it access secrets or production credentials?
- How long may it run without review?
- Which actions require explicit approval?
- What is the maximum blast radius if it fails or is manipulated?
- Can its actions be audited and reversed?
These are system-design questions. They apply to every user, including experts. The proper response to agent risk is not to reserve powerful tools for people with the right title. It is to separate capabilities, grant the minimum necessary authority, and increase review as the consequences of an action increase.
A company can give many employees access to an AI that summarizes documents, searches approved knowledge, or drafts work without giving those same employees permission to deploy code, read all customer records, or transfer funds. The model may be similar while the operational authority is not.
This distinction matters because the useful power of an AI system is not determined by the model alone. It is produced by the combination of model capability, private data, tools, credentials, compute, runtime duration, and permission to act.
Larger Institutions Will Have Even Stronger Incentives to Control Capability
The same reasoning scales beyond one company. Cloud providers, large corporations, governments, research institutions, and critical-infrastructure operators face larger consequences when a system is misused or compromised. They also possess more valuable data, more powerful tools, and more capable infrastructure.
Their incentives are mixed. Some are plainly protective: prevent fraud, cyberattacks, data leakage, unsafe scientific assistance, or uncontrolled access to critical systems. Others are institutional: reduce liability, satisfy regulators, preserve commercial advantage, protect national capabilities, and maintain control over scarce infrastructure.
No secret agreement is required for these incentives to produce a hierarchy. Each organization can make a locally reasonable decision—verify identities, restrict tools, keep the strongest systems in controlled environments, require monitoring, reserve exceptions for trusted partners—and the combined result can still be a world in which meaningful AI capability is concentrated.
This is not only a hypothetical pattern. Anthropic's published Responsible Scaling Policy materials describe access controls tailored to deployment context and expected users, along with a tiered access system for cases where safeguards may need to be adjusted. The proposed process includes enhanced due diligence based on partner trustworthiness and the claimed benefit of the use case. Anthropic publishes the current policy and safeguard updates here.
That policy is aimed at managing extreme-risk capabilities, not at removing ordinary AI access from the public. It should not be misrepresented as proof that broad restriction is inevitable. It does, however, demonstrate the basic mechanism: as capabilities become more consequential, access conditions can become more differentiated, identity-dependent, monitored, and negotiated.
The Divide May Appear as Capability Tiers
The simplest picture of an AI divide is binary: some people have AI and others do not. I do not think that is the most likely outcome. AI services are too useful, too commercially valuable, and too widely distributed for ordinary access to vanish easily.
A tiered structure is more plausible:
- public conversational AI with standard safeguards and limited tools;
- paid individual systems with larger limits, memory, and controlled actions;
- enterprise systems connected to internal knowledge under identity, audit, and retention controls;
- special deployments with more data, compute, autonomy, or adjusted safeguards;
- internal government or corporate systems that are not publicly available at all.
Anthropic describes Claude Enterprise as the same frontier model deployed with identity management, access control, data governance, auditing, and contractual infrastructure that individual plans do not carry. Its enterprise description makes the governance distinction explicit.
This is an important correction to the idea that the divide must always be a secret “better model” hidden from the public. Sometimes the decisive advantage is not a different model. It is access to private data, approved tools, organizational credentials, long-running workflows, higher resource limits, and legal permission to use the system for consequential work.
Ordinary people may continue to receive increasingly capable assistants while still falling further behind institutions whose systems can operate continuously across proprietary data and real infrastructure. Widespread access to an interface can coexist with concentrated access to operational power.
Safety and Control Use the Same Infrastructure
Identity verification, permission systems, audit logs, approval gates, monitoring, sandboxing, and cloud-only delivery can all make AI deployment safer. They can reduce harm and make accountability possible.
The same mechanisms also determine who may use which capability, under what conditions, and with how much privacy or independence. A control can be justified by a real risk and still create dependency. A safety gate can protect users and also become a gate through which an institution selects customers, regions, professions, or approved purposes.
That does not make every safeguard illegitimate. Removing all boundaries from agentic systems would not create freedom; it would often create preventable damage. The important questions are about governance:
- Who defines the criteria for access?
- Are the criteria visible and consistently applied?
- Can a decision be appealed?
- Can users export their data, memory, and work state?
- Can they move to another provider or a local system?
- Does losing one account mean losing years of accumulated continuity?
- Are lower-risk alternatives available when a high-risk capability is restricted?
The danger is not simply that a company or government might say no to one request. It is that the user's memory, history, settings, work, and identity may be fused to the same service that decides what the user is permitted to do next.
This Outcome Is Not Inevitable
There are strong forces in the opposite direction. Companies compete. Countries do not all want to depend on the same providers. Hardware improves. Research spreads. Open-weight models and local runtimes allow people and smaller organizations to retain capabilities that do not require continuing permission from one cloud account.
OpenAI's gpt-oss models are one concrete example. OpenAI released the weights under the Apache 2.0 license and described the smaller model as suitable for local or on-device use with 16 GB of memory. The company explicitly presented open models as a way for individuals, enterprises, and governments to run and customize AI on their own infrastructure. OpenAI's release describes the models and the case for open weights.
Open weights do not guarantee permanent parity with the best hosted frontier systems. Local hardware, energy, memory, model quality, and specialist tooling still matter. A public model can also have its own licensing, supply-chain, and security problems.
But local and open systems make total dependence harder to enforce. They provide a floor: a capability that can continue even if an account is closed, a provider changes direction, a region is unsupported, or a subscription becomes unaffordable.
The future may therefore contain both trends at once: increasingly governed frontier systems and increasingly capable local alternatives. The central question is not whether one side eliminates the other, but how large the capability gap becomes and what remains portable across it.
What Ownership Can Still Mean
A personal system cannot guarantee ownership of frontier compute. It cannot force a provider to keep a model online, override a law, reproduce a restricted data center, or make a small computer equal to the largest cluster.
Ownership can still apply to the durable layer around the model:
- the user's memory and history;
- project state and unfinished work;
- decisions, procedures, and accepted constraints;
- tool configuration and permission policy;
- personal data and local archives;
- the ability to switch models and providers;
- a basic local mode that remains usable when cloud access is unavailable.
This is where doll fits. It is not an attempt to own the strongest model in the world. It is an attempt to keep the relationship with AI from depending entirely on one company's permission.
The model is treated as a replaceable reasoning engine. The user's state, work, memory, and continuity are the durable core. Cloud systems may extend performance, but the basic system is intended to remain meaningful when the cloud changes or disappears.
That does not abolish the AI capability hierarchy described in this essay. It addresses a narrower and more practical problem: even when the available model becomes weaker, more expensive, more restricted, or different, the user should not have to begin again as though the previous relationship never existed.
The Question Is Not Whether AI Will Exist
The social-media posts that prompted this line of thought may describe real events or may not. They do not prove that companies, governments, and model providers are moving toward one coordinated plan.
They reveal a plausible incentive. Once an AI system can read secrets, operate tools, and affect real systems, organizations have rational reasons to control it. As capability grows, those controls are likely to become more elaborate. As the controls become more elaborate, access can become more unequal even while AI remains visible and widely used.
The important future question is therefore not merely whether people will have AI.
Who will be permitted to use which capabilities, with what data and tools, under whose conditions—and how much of the memory, work, and continuity created through that system will still belong to the user?
That question is one of the reasons doll is being built.
Publication Note
This essay grew out of a conversation between the builder of doll and GPT-5.5 Thinking. The initial observation, the connection to doll, and the main editorial decisions came from the builder. GPT-5.5 Thinking developed the structure and drafted the prose. The builder is responsible for the final decision to publish this version.
This is not a verbatim transcript of the conversation. Factual claims and source links were checked separately for publication.