Local processing is not local authority

Imagine a loan application on your phone. An assistant that runs on the phone itself, with no cloud model involved, offers to fill in the form for you. It reads your salary slips from your files, works out the figures and sends the application to a bank's service.

Your documents never left the phone while the assistant read them. That's a real privacy gain, and it's why people like on-device models.

Now look at what arrives at the bank. A request, with a token in it. The token was saved in the app's storage three weeks ago, when you first signed in. The bank's service sees the token and says yes.

It has no idea whether you pressed a button this morning, whether the assistant or some other program on the phone sent it, or what you meant the assistant to do.

Where the data is processed, and who decides

Running a model locally answers one question, which is where the data lives while it's being read. It doesn't answer a different set of questions that a receiving service has.

Which agent is calling? Who gave it authority, and for what? When does that authority end? With a long-lived token sitting in app storage, the honest answer to all three is "whoever has the token, whoever was signed in, and eventually".

So our shorthand is that local processing isn't local authority. The first is a statement about where computation happens. The second is a statement about who is allowed to act, and it has to be checkable by someone who isn't on the phone.

A design for the edge

Here is the shape we'd like to see, kept at the headline level. It's a general pattern, and we don't claim to have invented any piece of it.

Each installed copy of an agent makes its own key when it's first set up, and it keeps that key in the phone's hardware-backed keystore, where the key can be used but not copied out. That key is the agent's own, separate from yours. If you reinstall, you get a new one.

When the agent needs to do something on your behalf, the phone's operating system asks you. This is the ordinary prompt that checks that you're really there. It names the agent's key, the task, the tools and resources the agent may touch, and an expiry measured in minutes. When you approve, the system issues a short-lived delegation that carries all of that.

Each request the agent sends is then signed with its key. A copied delegation is no use without that key, so a thief who lifts the token out of the app gets very little.

The receiving service checks a signed statement from the operating system, saying that a real person approved this. It doesn't look at a field the agent wrote. That matters because an agent can type "user approved" into any field it likes, and the point is that it shouldn't be the one to say so.

Lastly, the service keeps its logs of what the agent did separately from what you did, and records the agent's key and the delegation's reference against each entry.

What it costs

Nothing here is free, and we'd rather say so.

Every call carries a signature, and the service has to verify it, so there's extra time on each request. On a fast connection you won't notice. On a slow one, with a lot of small calls, you might, and a service that handles millions of requests will see the cost add up in its own bill.

Then there's the business of issuing delegations and handling their expiry. A short life is good for safety and tiresome for the person using it. If the agent asks you to approve every five minutes, you'll stop reading the prompts, and the whole thing turns into a ritual.

Data protection and the forwarded record

There's one more piece, and it comes from India's data protection law. Suppose the on-device agent forwards a record containing personal data to a cloud service. If the delegation reference doesn't travel with that record, the audit trail breaks at exactly the point where the data leaves the phone. Someone later asking "who sent this, and on whose authority" finds a record with no parent.

So we'd say the reference should be carried with the record every time. That's our reading of the Digital Personal Data Protection Act 2023, and it isn't legal advice. Please check it with counsel before building on it.

What we don't know

We don't know what a phone should do when a delegation runs out while it's offline halfway through a task. Failing closed is safe and irritating. A short grace period is kinder and quietly weakens the idea. We haven't picked one, and we suspect it depends on the cost of the action.

We don't know whether attestation, the proof that the right agent software is running, should reveal which model it's using. A service might reasonably want to know for a risk decision. But the claim is easy to fake without a trusted root, and revealing it could expose something a person would rather keep to themselves.

And we haven't seen this design tried at scale. The tradeoffs above come from thinking it through, not from measurements, and we'd like to be corrected by people who've built it.