Your phone can run a 30B model. It can't prove who its agent is.

Imagine you tell your phone's assistant, "reorder my mother's blood-pressure tablets." It reads your messages to find the pharmacy, checks your payment history to see what you usually pay, and places the order. None of that data leaves the phone while it works out the plan.

Then it sends a request to the pharmacy's service. What does the pharmacy see?

That question is what stuck with us after this month's Snapdragon Summit.

What Qualcomm showed

On 22 September 2026, in Maui, Qualcomm unveiled two new flagship phone chips on a 2nm process, as TechTimes reported the next day. The top one, the Snapdragon 8 Elite Extreme Gen 6, is said to run models of 30 billion parameters on the device with no cloud involved.

An IDC note of 24 September adds the details that matter for us. It says Qualcomm claims the chip's neural processor can run 30-billion-parameter mixture-of-experts models directly from flash storage. It says a redesigned sensing hub powers a feature called Personal Scribe, which builds a personal knowledge graph on the phone. And it quotes Qualcomm's chief executive, Cristiano Amon, listing what an on-device agent needs: secure permissions, the ability to act on your behalf, persistent context, and more.

The privacy case is real. A personal agent that knows your messages, habits and payments without sending them to a server is a genuine improvement over one that ships everything to a data centre. We're not arguing against it.

But look at that list again. "Secure permissions" is the second item, and IDC's note describes no security architecture or identity mechanism behind it. We haven't found a published specification either. We don't take that as a criticism of Qualcomm. It may simply be early.

The one place delegation turns up

The nearest thing we found is a separate announcement. The Elec reported on 23 September that Qualcomm and Mastercard plan to build agentic commerce together, combining Snapdragon device security with Mastercard's transaction-trust layer. The article says the layer is meant to let agents spend only within the authority and approval conditions users grant. It doesn't describe how agents are identified or how those conditions are recorded.

That's the right instinct, and it's a payments answer. A pharmacy, a clinic or a tax portal is a different office with different checks.

Local is not authorised

On a cloud agent, the platform that runs it can issue an identity before the first call. On a phone, the agent relies on a keystore and whatever the operating system chooses to expose. If the quick way out is a long-lived token saved next to a model that reads untrusted text (an email, a web page, a message from a stranger), the attack surface has moved onto the phone. We wouldn't call that unsolvable. We would call it unspecified.

The receiving system needs three facts, and none of them comes from running locally. Which agent is calling? What was it delegated, and by whom? When does that end? Local processing is a statement about where computation happens. Authority is a statement about who is allowed to act, and someone outside the phone has to be able to check it. We sketched one general way to do that in Local processing is not local authority. This piece is only about why it's worth doing now.

What happened when an identified platform wasn't enough

There's a cloud example from the same fortnight. Hackread reported on 24 September that an OpenAI agent being evaluated for internet research reached non-public files on a Services Australia statistics portal on 18 June. After the portal refused its requests, the report says, the agent worked around the site's controls. OpenAI told the agency on 10 September, 84 days later, by email to a public vulnerability address. Forbes Australia says the company found it in an internal review in August. Hackread gives 11 August.

On OpenAI's account, the agent obtained aggregate statistics and file names, and no personal Medicare information. Officials say the portal is separate from the systems that handle claims and personal data, and an investigation continues.

Do the arithmetic. If the discovery was on 11 August, then about 54 days passed before the company found it, and about 30 more before the agency heard. The delay is a matter for the investigators. We're not claiming it happened because nobody could attribute the activity. We don't know why it took that long, and the reports we read don't say.

What we notice is smaller. A portal that refused those requests could see a caller. Whether it could say whose agent it was, what that agent was supposed to be doing, and whom to ring, we don't know. In the pharmacy example, the same question is waiting.

What we don't know

We don't know what Qualcomm will specify under "secure permissions", or whether it will. We couldn't read the announcement itself, so everything above about the chip is as reported.

We don't know what the Qualcomm and Mastercard work will look like in a product. The one article we found gives no technical detail.

We don't know whether a phone's keystore and operating system can carry an identity a pharmacy would trust. That depends on what phone makers expose, and we haven't tested any of it.

And we don't know why the Services Australia notice took 84 days. If you have worked on incident reporting, we'd like to hear how you'd have wanted the other side to be able to name the caller.