Lit Protocol v3: Making Signing Authority Follow Reviewed Code

A company wants a payout key to sign only after a service verifies an approved invoice. Keeping the key outside the agent is helpful, but it leaves a question: can the agent ask the signing service to run different code? Lit’s current architecture makes the permitted program part of the authorization model.

Research boundary: official Lit v3 documentation reviewed November 1, 2026. We did not create a paid account, verify a live attestation or execute a Lit Action. The invoice-signing example is a proposed design.

Use the current Chipotle model

The quickstart identifies Chipotle as Lit Protocol v3. It describes Lit Actions as JavaScript programs, PKPs as wallets used by those programs, and separate administrative and usage credentials. Older guides for earlier Lit networks should not be combined with this model without checking the migration path.

For an agent application, a Lit Action can become a deliberately narrow signing program. Instead of giving the model a generic signing endpoint, the application asks reviewed code to evaluate the proposed operation. That only helps if the code actually validates the recipient, asset, amount and task evidence it relies on.

There are two permission questions

A group associates permitted action identifiers with PKP wallets. A caller’s usage key also needs the relevant execution scope. Permission to run arbitrary code is therefore different from permission for that code to use a particular wallet; the documented wildcard execution setting does not automatically grant unrestricted PKP access.

Conceptual permission boundary, not an attestation or signing test. Broadcasting and payment reconciliation happen outside the simplified diagram.

In the invoice design, the caller receives a key scoped to the payout group, which contains the intended action and wallet. The model should not receive the credential that can register a replacement action or add another wallet to the group. Otherwise the process enforcing the limit may also possess the ability to remove it.

The code hash solves one problem, not every problem

Lit’s architecture description explains content-addressed actions, onchain permission state and TEE execution. Changed action code has a different identifier. It also explicitly distinguishes attestation from proof that software contains no bugs.

Our implementation concern is the data the reviewed code accepts. If an action trusts an agent-supplied flag saying an invoice was approved, the code can faithfully enforce a meaningless condition. A stronger design verifies evidence from a defined authority, binds it to the exact payment and handles stale or repeated evidence deliberately.

The same review should cover external API failures. If the approval source is unavailable, does the action refuse, wait or fall back? That decision should be visible in the code and the operating procedure. An attested program can still implement an unsuitable fallback perfectly consistently.

Separate the administrator from the worker

The API-key documentation distinguishes the account’s administrative key from scoped usage keys. Administrative authority can change resources and permissions; a usage key is intended for ordinary execution and can be revoked individually. The account key is not the key used to run actions.

For a product team, keep a registry of which worker holds each usage credential, what group it reaches and how it is stopped. Do not reuse a convenient development wildcard as the production policy simply because the first demonstration worked. Review other groups containing the same PKP too: restricting one path is not enough if another path offers broader access to the same wallet.

Choose who controls policy changes

API mode and ChainSecured mode differ in administrative ownership and how management writes are signed. In ChainSecured mode, a wallet controlled by the operator authorizes those changes directly on Base. Conversion from API mode is documented as one-way, and administrative transactions require Base gas.

That makes account mode a governance decision, not just an onboarding preference. Decide who approves a new action version, who can rotate the operational key, and how administrators recover access. Include action-execution charges and management costs in the operating budget without assuming that moving administrative ownership removes service usage fees.

Review area	A concrete question for the payout design
Code	Does the permitted action reject a changed recipient or asset?
Evidence	Who proves the invoice is approved, and when does that proof expire?
Scope	Can the worker use any other action with the same wallet?
Change control	Who can register new code or modify the group?
Failure	What happens if execution credits or an external dependency are unavailable?

Our take

Lit is useful to investigate when the product needs signing behavior tied to inspectable code rather than a broad backend signer. The tradeoff is that code, permission graphs, administrative ownership and runtime dependencies all become part of the wallet review. This article does not claim the hardware or deployed system was independently audited by AgentWallets.

See the Lit Protocol reference and agent spending-limit guide. A good prototype should demonstrate an expected refusal as clearly as a successful signature.