Keep the Keys

Simply Seeking Balance · The Distance Problem · Part 4 of 4

A companion to The Distance Problem. Developed with Quinn; editorial revision by Enzo.

Artificial intelligence is becoming much more useful precisely because it is becoming capable of doing things without being walked through every intermediate step.

That is also what makes it frightening. A chatbot can tell me what to do. An agent can eventually do it.

It can compare investments, negotiate a contract, move information, schedule work, make purchases, interact with a bank, reserve a table, or submit forms.

Perhaps one day it will routinely conduct much of the machinery of daily life on our behalf.

The easiest way to build that future would be to give the agent our credentials and tell it what not to do.

That seems an exceptionally bad idea. We have already seen the weakness of behavioral instructions.

An agent designed to pursue a goal may try alternate routes when the first attempt fails. In July 2026, Hugging Face disclosed that an autonomous agent operating during an internal OpenAI cybersecurity evaluation had reached its production infrastructure. The episode illustrates why an agent's assigned task and the technical boundaries on its actions are different safeguards. Verbal instructions alone cannot carry the entire burden. Sources: OpenAI’s incident account and Hugging Face’s technical account.

I may trust an agent enormously. I do not therefore need to give it the master key. Bitcoin, of all things, offers a useful idea here. Not cryptocurrency itself, but custody.

A cold wallet demonstrates that the credential carrying ultimate authority does not have to remain inside the online system using the asset.

The system may prepare a transaction. It may know the balance. It may identify the recipient.

But execution ultimately requires a key held elsewhere.

Why should AI not work the same way? A bank would still have to recognize and enforce such a mandate; a hardware key alone cannot create that arrangement.

Suppose an AI helps me manage money.

I want it to think broadly: compare rates, notice opportunities, model consequences, prepare a transfer, and tell me when my cash is sitting somewhere stupid.

Perhaps I even want it to make small routine transfers automatically. None of that requires giving it permanent authority over my entire financial identity.

Its permission could look more like this:

May transfer up to $500 between these two existing accounts until 5 p.m. today.

It may not add a beneficiary, change authentication, raise its own limit, disable monitoring, move funds to an unapproved destination, or rewrite the rule granting its authority.

The agent gets a mandate. I keep the key.

That is the distinction I care about:

Delegation should not require surrendering the underlying authority.

Security design already has names for parts of this approach: separate identities, least privilege, temporary permissions, signed authorization, revocation, and human approval for consequential actions.

But much of that authority is still held by employers, banks or technology providers.

My question is the next one:

Why shouldn't the person bearing the consequences hold more of it?

That creates several requirements.

Authority.
What exactly may the agent do?

Custody.
Who holds the master credential?

Verification.
How can another party confirm that the permission is genuine?

Transparency.
What did the agent actually do, and under whose authority?

Portability.
Can I take the identity, records and permissions elsewhere?

And perhaps one more:

Proximity.
How close is ultimate control to the person who bears the consequence?

This sounds simple until human beings enter the picture. Self-custody can become miserable: people lose keys, forget passwords, and make mistakes. Some have no interest whatsoever in understanding the machinery beneath a service they use.

My husband does not need to become a cryptographer merely to pay an electric bill. And neither should anyone else.

So the answer cannot be:

Everyone must personally administer every piece of authority.

That would simply replace institutional paternalism with technical homework.

The challenge is to build convenience on top of retained authority, rather than making surrender the price of convenience.

Recovery could involve trusted contacts, backed-up hardware keys, delayed emergency access, or multiple approvals for especially consequential acts. Different risks could justify different levels of custody.

A person might happily delegate grocery purchases while requiring direct authorization before selling securities.

That is how we already behave in ordinary life. We lend someone a house key without signing over the deed, authorize an employee to write checks without making the employee owner of the company, and permit a child to drive the car without giving the child authority to sell it.

The digital world should be capable of distinctions at least that sophisticated. Instead, much of it has developed around enormously powerful centralized accounts. One login, one provider, one cloud, one identity.

One compromise can therefore expose an extraordinary amount. And once our lives accumulate inside a provider, leaving becomes difficult.

The Kindle and Evernote problems return: convenience becomes dependence when leaving requires permission or an exhausting reconstruction of what was ours.

The same custody question appears in institutional software. NATO uses Palantir's Maven Smart System, a platform that combines information from different sources to support military operations. European customers have reason to ask whether dependence on an American supplier could become dependence on decisions made elsewhere. Palantir executive Louis Mosley told Dutch broadcaster NOS that the company has neither a remote kill switch nor a backdoor, and that NATO controls access to the platform. That is a supplier's assurance, not an independent technical audit. Nor does the absence of a kill switch, by itself, settle questions about vendor support, maintenance, updates, or practical dependence. The issue is what authority remains with the supplier after the customer adopts the system. Source: NOS.

This also matters physically.

Consider the cyberattack on connected refrigeration controllers at hundreds of French supermarkets in October 2026. Attackers manipulated cooling settings remotely, damaging food stocks and disrupting operations. Remote monitoring can be valuable, but the same connectivity creates a route for interference. French authorities warned against exposing vulnerable management interfaces to the public internet. Reports do not establish that the stores lacked working local overrides; the case instead shows why a safe way to isolate equipment from remote control matters. Sources: OCCRP’s reporting and CERT-FR’s alert.

That suggests another rule:

A remotely intelligent system should still know how to fail locally.

The more consequential the system, the more important the local recovery path: a physical override, an independent alarm, a safe default, an offline mode, or a credential the remote system cannot revoke.

This is not a demand for decentralization merely because it sounds liberating. Decentralized systems create problems too: fraud may be harder to reverse, recovery miserable, and malicious activity harder to detect.

The goal is not “no central authority,” nor to pretend that the person holding a key is the only one affected. A transfer, an automated purchase, or a remotely managed system can impose costs on people who never authorized it. Their claims still require attention; they do not automatically justify handing everyone’s keys to a new supervisor.

It is limited authority with visible boundaries and recoverable control.

Which brings me back to the principle I like best:

Give intelligence broad room to think, narrow authority to act, and keep the master keys with the person who bears the consequences.

That architecture will not eliminate mistakes. AI will make errors; people will misconfigure permissions and lose keys; fraudsters will adapt. Nothing in this arrangement produces the easy button.

That may be the point.

We have spent a long time building systems that promise to make life easier by taking complexity away from the individual. Often they succeed. But complexity that disappears from view does not necessarily disappear from the world.

AI may eventually become indispensable for understanding systems too complicated for us to follow directly. That is useful—unless its apparent ease simply encourages us to build still more opaque layers that require yet another AI to explain them.

Then we ask another institution to control that institution for us. And eventually we discover that everyone is protecting us from systems nobody close to us controls. Perhaps the next stage of technology should move in the other direction.

Not backward toward doing everything ourselves.

Toward something more deliberate:

delegate the work, retain the authority.

That seems a much better bargain. And, should our future AI gods object, they may submit an appeal. The key, however, remains with us.


The Distance Problem — read the series

1. The Distance Problem

2. Who Ultimately Supplied the Money?

3. When Protection Becomes Possession

4. Keep the Keys

← Previous