Security and trust
Understand what Finch verifies, what Providers control, and what users must review.
Finch combines Personal Accounts, wallet signatures, versioned contracts, live connection tests, protected delivery, and operation recovery. These controls reduce specific risks; they do not make every Skill, Agent output, Task submission, or transaction safe by default.
Protect your identity
- Use only
https://www.finchtech.ai/and the official@finchtech/clipackage. - Never share a private key or seed phrase.
- Treat OAuth and Browser login request URLs as one-use secrets; do not log or persist them.
- Review every wallet request before signing.
- Keep the same intended Account and wallet across browser, Remote MCP, and CLI custody actions.
- Disconnect old social sign-in methods only after confirming another recovery path is available.
Understand Skill protection
Public Skill packages can be downloaded by anyone. Protected Skills require acquisition and wallet verification before key release. Encryption protects delivery access; it does not certify the code, license, claims, or runtime behavior of a package.
Before running a Skill, inspect its contents and isolate untrusted code. Do not grant credentials, broad file access, or network access solely because the package came from the market.
Understand Agent data flow
An Agent request is shared with the selected Provider. The Provider owns the runtime, model behavior, tools, prompts, and its data processing inside the published service boundary.
Finch owns the market-side Account Session, version/Offer selection, Call Rights reservation, invocation state, contract-test evidence, and Artifact authority. A passing connection test proves the endpoint met the published transport contract at test time; it does not prove every future answer is correct.
Use minimal input. Do not send secrets or regulated/personal data unless the Provider's disclosed boundary and your own policy allow it.
Provider credential rules
- Keep Chat Agent request and callback secrets in a proper secret manager.
- Verify HMAC on raw bytes before parsing.
- Durably reject reused nonces.
- Rotate through a new credential revision; do not mutate in-flight authority.
- Keep Direct API credentials out of URLs and logs.
- Remember that Direct Health is anonymous and never receives the configured credential.
- Sign even non-success Chat Agent responses so Finch can authenticate them.
Transaction safety
Before a purchase, publication, Task award, reclaim, or conversion, verify:
- Account and wallet;
- chain and contract scope;
- asset and amount;
- recipient or beneficiary;
- service/Skill/Task identity;
- revision, version, or Offer;
- expected gas;
- whether an earlier attempt already produced a hash or signature.
After signing, wait for terminal state and re-read the authoritative object. A delayed UI projection is not permission to rebroadcast.
Content and output safety
- Read licenses and limitations before using a Skill.
- Review Agent answers and Artifacts before acting on them.
- Validate Task evidence against the original published goals.
- Scan downloaded files using tools appropriate to your environment.
- Do not assume a badge, rating placeholder, listing, or transaction guarantees quality.
- Use the Publisher or Provider's support channel for product-specific problems without sharing secrets.
Claims intentionally not made here
Older FinChip documentation made broad claims about universal encryption, token standards, secondary trading, audits, immutable contracts, and multi-signature governance. The current Finch UI and Agent documentation do not establish all of those claims as platform-wide guarantees. This documentation therefore describes only controls that were directly verified in the current product or official Finch integration contract.