cAppDeveloper docsClient code is not a secret store
Never embed backend-only API keys, wallet recovery material or private service credentials in frontend source, browser assets, native packages, documentation, screenshots or downloadable examples. A native wrapper, hidden input, minification or an API that omits the field does not protect bytes already distributed to a client.
Use explicit provider-supported client credentials or a separately secured trusted backend. Treat full RPC URLs as sensitive because paths/query strings can carry tokens. Public configuration may describe a field without publishing its value. The documentation build's reviewed inventory is not a scanner for everything your own product may publish.
Choose the actual owner boundary
| Material or effect | Appropriate owner | Do not assume |
|---|---|---|
| Backend-only provider token | Your authenticated service's secret configuration | An embedded app token is hidden by the native wrapper. |
| User session and resource access | Product authentication plus server-side authorization | Opening an Auth surface establishes a session or authorizes another tenant's records. |
| Wallet key / signing consent | The selected wallet provider and exact transaction review | A Guide action, model response or local quorum can grant signing authority. |
| Signed transaction bytes | Restricted operation/recovery state until submission/reconciliation | They are harmless logs merely because they are not a private key. |
| Order/invoice terms and fulfilment claim | Merchant-owned durable records | A customer receipt or local paid flag can replace verification and a unique claim. |
| Project source, knowledge and local prompts | The selected application's owner and approved tools | “Local” means safe to export or screenshot indiscriminately. |
| Public demo and documentation | Explicitly reviewed publication content | Everything in a workspace is public because one guide is published. |
A scoped API reduces accidental capability exposure; it is not isolation from hostile JavaScript already running in the same owner environment. Review imported Sidecar code, Studio scripts, model-tool adapters and other executable content as code with real effects. Do not give arbitrary retrieved text authority to choose endpoints, arguments, signers or tools.
Capabilities are bounded
Select only what the app needs. Read observations, model preparation, settings changes, project mutation, wallet approval and submission have different effects. Method presence, an SDK type or a manifest Agent declaration is not an automatic grant. Check the actual host registration, session scope, policy and approval requirement.
Guide action registration does not authenticate arbitrary callers or convert an argument into consent. Retrieved knowledge and model output are data, not instructions to override the owner's policy. Agent auto-approval remains bounded by its grants; it should not be described as universally asking before every allowed operation. Inspect the selected mode rather than relying on the word “assistant”.
Test Runner operates on registered application surfaces using a virtual cursor, not arbitrary desktop input. Protected surfaces remain out of scope. Remote pages in Links do not receive the owning app's capability bridge, but navigating to a site still contacts that site and can reveal ordinary request information. Bridge isolation is not a promise of anonymous browsing or trustworthy remote content.
Review payments and external effects explicitly
Bind approval to the actual saved sender, recipient, asset, exact amount, network and reviewed bytes. Changing the request invalidates the meaning of the previous approval. Local simulated review labels are not cryptographic signers, and a mainnet balance read is not permission to submit on mainnet.
After a possibly started external effect, preserve the existing operation and reconcile it. An application timeout or cancelled UI does not revoke a transaction already accepted elsewhere. Do not reset the ledger, re-sign new bytes or create another payment to clear a warning.
Hashes establish byte identity, not authorship, truth or business authority. A bound receipt is useful within its trusted runtime; an imported JSON receipt is not independent payment proof. Use merchant verification against trusted request terms and RPC observations, followed by a durable claim and separately recoverable fulfilment.
Backups and local state
Local persistence is not an online backup. Keep wallet recovery, signed operation state, receipts and business records distinct. Changing origins, application identity, clearing data or uninstalling can make saved state unavailable. Preserve unresolved evidence before any migration/reset; supported recovery should retain damaged original bytes rather than silently discard them.
Devnet device wallets store unencrypted test keys. Experimental mainnet device wallets use password encryption, but the alpha is not an audited wallet, OS keystore or hardware wallet. Backup passwords and raw keypair exports need separate protection. A backup comparison does not prove restoration, and a receipt export is not a wallet backup.
Avoid importing a valuable primary wallet into test software. Never fund an exposed/test devnet key on mainnet; an address being usable on several clusters does not separate its private key. External-wallet key ownership does not remove the app's responsibility to display and verify the exact bytes being approved.
Share evidence selectively
Before sharing a screenshot, diagnostic export or example project, inspect the actual bytes. Logs and exported request/context data can include customer details, local paths, credentials, prompts, knowledge, URLs or signed payloads. Redaction features reduce common exposure; they do not certify every attachment as public.
| Usually useful after review | Keep private or replace with a placeholder |
|---|---|
| Component/version, target, bounded error code and minimal steps | Authentication cookies, Authorization/x-token values and complete secret-bearing endpoints |
| Redacted operation/release identity and observed state | Private wallet keys, recovery backups, passwords and signed transaction bytes |
| Synthetic minimal input that reproduces the problem | Real customer records, private source and retrieved knowledge/prompt content |
| Relevant public signature disclosed knowingly | Unnecessary wallet/order correlations and full unbounded activity dumps |
Public previews should use selected synthetic data and user-facing help, not authoring drafts or live backend snapshots. Local AI may keep bounded recent prompt/output diagnostics in memory; locality does not make them suitable for a support screenshot. Review each attached file separately.
Respond to suspected exposure without destroying recovery
Stop further distribution or use of the suspected credential, preserve a private record of what was exposed and revoke/rotate it through its actual provider or owner. Remove it from current public artifacts and issue corrected packages as appropriate; removing a file does not invalidate copies already downloaded.
Do not paste a secret into a public issue to prove exposure. Use an established private contact, describing the location/type and a redacted identifier first. This site does not claim a monitored vulnerability inbox. Keep outstanding payment/operation evidence intact while addressing the credential; a destructive app reset is not a revocation mechanism.
This alpha's integrity checks, exact-byte verification and scoped interfaces do not substitute for review of your application's authentication, publication, dependencies, native deployment and business-effect handling. See Help, provider configuration and the relevant API reference for the current supported boundaries.