Bind caller identity to call context, not request arguments

[asim]

Foundation for the micro/xyz services. Partially landed in 1f6289f5.

The problem

Account identity travelled as an account_id request argument, so it was only as trustworthy as the caller. Nothing in the call path enforced it — it was enforced by a wrapper at each boundary where untrusted input entered, and there were two independent implementations:

• apps/sdk_service.go — the app SDK over HTTP
• agent/native.go:injectAccount — the agent's tool calls, guarding against prompt injection in tool content

Both correct. That was the point: the same rule implemented twice, in two packages, because the argument guaranteed nothing on its own. A third caller — a service calling another service — would have needed a third copy, and the failure mode of forgetting is silent cross-account access to mail, index, images, events.

There was no live hole: every other service.Call site is first-party Mu code building typed requests.

Done (1f6289f5)

• service.WithAccount(ctx, id) / service.AccountFrom(ctx) — identity on go-micro call metadata. Verified to propagate over the in-process transport before anything was built on it. An empty id clears inherited identity, so a guest request cannot borrow the previous caller's account.
• CallDynamic is the single enforcement point. It discards args["account_id"] and re-stamps from context, so no dynamic caller can scope a call to someone else by naming them.
• The SDK boundary drops its own scrub and just sets the context.
• Tests cover: forged account_id overwritten, guest cannot claim an account, identity reaches the handler when the caller passes nothing.

The agent still sets the request field as well as the context, deliberately — its tool calls are dispatched by go-micro straight to the service rather than through CallDynamic, so the field is what today's handlers read.

Remaining

• Migrate the account-scoped handlers (mail, index, images, events) to read service.AccountFrom(ctx) instead of the request field.
• Once migrated, stop setting the field in injectAccount and drop AccountID from those request structs, so the value has one source.
• Account-scoped storage for services, built on the context identity. The go-micro store Mu wires is flat (internal/service/service.go:95, store.NewFileStore into $HOME/.mu/store) — no namespace, no owner, no encryption, unlike internal/userdb. This is what the personal services need (reminders, ledger, notes, habits, contacts) and it must be settled before the service contract in micro/xyz Add full markets page at /markets with extended market data and persistent caching #7, or shipped services need their data migrated.

Blocks: micro/xyz #7 · related #1444, #1445

[asim]

Leaving this open, but two of the three remaining items are done — flagging so the residue is clear rather than the whole thing looking untouched.

• Handlers read service.AccountFrom(ctx). No service request struct carries an AccountID field any more (checked across service/), so there is nothing to forge.
• injectAccount no longer sets the field. It strips any account_id the model invents rather than passing it through, and its comment now says why: "handlers read service.AccountFrom(ctx) and nothing else". One source for the value, as this issue asked for.
• Account-scoped storage for services — still open, and still flat. internal/service/service.go wires store.NewFileStore(store.DirOption(dir)) with no namespace, no owner and no encryption, unlike internal/userdb.

That last one is a different piece of work from the identity binding this issue is named for, and it is the one that blocks micro/xyz #7. Might be worth splitting it out so this can close.

One thing that has changed the surrounding picture since this was written: every service call now passes through a single gateway (127a326), which reads identity from exactly the context metadata this issue introduced. So the context identity is no longer only what handlers read — it is what the charge, the allowance and eventually the rate limit are keyed on. That makes the remaining storage item more valuable rather than less.

---

Generated by Claude Code