The security invariant
Composition is open. Signing is gated. A prompt, App, or skill can request an action. None of them can grant themselves permission to sign. The wallet’s policy remains authoritative across chat, scheduled work, and embedded surfaces.Actors and trust boundaries
Your Aomi account owns threads, settings, Apps, and wallet-policy records. A
linked wallet remains a distinct signing identity. Linking another wallet does
not merge its funds, keys, or permissions with an existing wallet.
Three independent controls
Authorization depends on three separate questions. Passing one never implies that the others pass.Signing policy
The signing policy answers what kind of approval is required for one linked wallet. It can require you to approve, permit an authorized signing path, or block signing entirely. A policy belongs to one wallet; linking another wallet does not copy it. This page defines the policy’s role in the security model. Read Configure approvals for the available settings and how to change them.Signing capability
Policy is not the same as capability. A policy may permit an automatic signing path, but the required wallet session or provider authorization must also exist for the exact wallet. If it does not, Aomi stops instead of substituting another signer.Transaction constraints
Signing permission does not make every transaction acceptable. Read Transaction safety for simulation, App and skill constraints, protocol checks, batch integrity, and fail-closed behavior.How authorization is evaluated
For each signing request, Aomi evaluates the current account, wallet, policy, and available signing capability. It uses current state rather than authority claimed by a prompt, old message, or schedule. Only after those relationships agree does Aomi hand the exact proposal to the transaction-safety pipeline. That pipeline owns constraint evaluation, simulation, signature verification, and broadcast.Non-custodial boundaries
Aomi does not ask you to upload a private key.- A self-custody key remains in your wallet or approved client.
- An embedded-wallet key remains with its wallet provider.
- Delegated signing uses a revocable provider grant scoped to a wallet.
- The runtime stores policy and grant state, not the private key material.
The default is no signature
If the account, wallet, policy, and signing capability do not resolve clearly, Aomi does not request a signature. It never widens authority or tries a different wallet to make the action succeed. Read Transaction safety for the concrete checks and failure outcomes applied to a proposed transaction.What this model protects
The permission model prevents a prompt, model, App, or skill from becoming its own source of signing authority. It also keeps authorization scoped to the specific account, wallet, chain family, policy version, and transaction path being evaluated. It does not make a protocol economically safe or make decisions for the wallet owner. Transaction safety lists the concrete risks outside Aomi’s transaction checks.Signing
See what happens when a transaction needs a signature.
Configure approvals
Choose and change the policy for each wallet.
Transaction safety
Follow the checks that run before value moves.