# Security model The hosted components inject an EIP-1193 provider bound to the user's wallet into a WebView. Two properties matter for review. ## The UI is locked to the Yodl origin ``, `` and `` lock the WebView to the configured Yodl origin, and off-origin navigation is blocked via `onShouldStartLoadWithRequest`. This prevents origin spoofing and mid-request navigation that could otherwise intercept a signed response. The injected provider also enforces a 30-second pending-request timeout. No configuration is required — this is the default and cannot be disabled. ## The bridge owns no keys and no accounts The bridge forwards EIP-5792 methods — `wallet_sendCalls`, `wallet_getCallsStatus`, `wallet_showCallsStatus`, `wallet_getCapabilities` — and all signing methods straight through to the wallet provider you supplied. It holds **no smart-account stack** and makes **no RPC calls of its own**. The embedded UI reads chain state through its own provider. Every signature and transaction is authorised by the user's wallet, exactly as if your app had made the request. For wallets without native EIP-5792 support, atomic batching is available via the [EIP-7702 provider](/sdk/eip-7702-provider) — an opt-in wrapper around the same provider, which likewise never holds keys. ## What this means for your review * Signing authority stays with the user's wallet at all times. * The SDK's network surface is the Yodl origin plus whatever your wallet provider talks to. * Your `integrationAddress` is sent on Yodl-owned requests as an identifier. It is **not** an authentication secret — see the caveat on [the integration address](/integrations/integration-address#a-declared-address-is-not-an-authenticated-one).