--- title: "Crypto Tools Integration" description: "Run cryptography utilities entirely inside FlowRunner with no API key, vendor account, or outbound call. Agents hash and checksum data, sign and verify HMACs, encrypt field values, and generate tokens as a workflow step." url: https://flowrunner.ai/integrations/crypto-tools date_modified: 2026-08-07T17:20:23-07:00 --- # Crypto Tools [Developer Tools](https://flowrunner.ai/integrations/category/developer-infrastructure) Run cryptography utilities entirely inside FlowRunner with no API key, vendor account, or outbound call. Agents hash and checksum data, sign and verify HMACs, encrypt field values, and generate tokens as a workflow step. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 12 actions · No credentials · available [Platform Documentation](https://nodejs.org/api/crypto.html) · Capability data verified 2026-08-04 1. A webhook arrives claiming to be an order update from the storefront 2. Agent reads the raw body and the signature header exactly as received 3. Agent recomputes the signature with Verify HMAC using the shared secret 4. Agent branches on the returned boolean rather than assuming the payload is genuine 5. Agent processes the verified payload and writes the order update to the system of record 6. When verification fails repeatedly on the same endpoint, the operations owner decides whether the secret rotated or the traffic is hostile ## What This Integration Enables Crypto Tools runs cryptography utilities entirely inside FlowRunner. No API key, no vendor account, no outbound call, which for this connector in particular is the point rather than a convenience: the secrets a flow uses to verify inbound traffic and seal stored values never travel to a third party to be processed, and there is no external service whose outage or breach becomes yours. The connector covers hashing and checksums with MD5 through SHA-512, HMAC signing and verification, AES-256 encryption and decryption, Base64, hexadecimal and percent encoding, and cryptographically secure random values for keys, tokens and identifiers. The defaults are the careful ones. Encryption derives its key from a passphrase with scrypt and a fresh random salt, uses a new random initialisation vector on every run so the same input never produces the same output twice, and verifies the GCM authentication tag before returning any plaintext. Digest and signature comparisons are timing-safe. The actions that exist only for legacy interoperability say so in their own descriptions rather than leaving a flow author to find out later. ### Without FlowRunner **Webhooks trusted on arrival**: An inbound payload is processed because it reached the right URL **Secrets compared with equality**: A signature check leaks timing information one character at a time **Sensitive fields stored in the clear**: Values land in a sheet or a third-party record exactly as they arrived ### With FlowRunner **Every payload verified first**: The signature is recomputed and compared before anything downstream runs **Constant-time comparison**: Digests, signatures and tokens are compared without leaking their contents **Fields encrypted before they travel**: Sensitive values are sealed in an authenticated envelope before storage ## Use Case Scenarios ### The inbound webhook that proves who sent it A flow receives order and payment events from [Stripe](https://flowrunner.ai/integrations/stripe), [Shopify](https://flowrunner.ai/integrations/shopify), [Slack](https://flowrunner.ai/integrations/slack) and [GitHub](https://flowrunner.ai/integrations/github). Each provider signs its payloads, and each expects the receiver to recompute that signature over the raw body with a shared secret. The agent calls Verify HMAC, which recomputes the HMAC and compares it to the supplied signature in constant time, accepting the expected signature in hexadecimal, Base64 or Base64 URL-safe depending on what the provider sends. It returns whether the signature is valid rather than throwing, so the flow branches cleanly into a verified path and a rejected path. Nothing downstream runs on an unverified payload. ### A field that stays sealed in somebody else's system An onboarding flow collects a value that has to be retained but should not sit readable in a shared spreadsheet or a vendor record. The agent calls Encrypt Text with AES-256-GCM, which returns a single self-describing envelope string carrying the algorithm, salt, initialisation vector and authentication tag alongside the ciphertext. That envelope is what gets written to [Google Sheets](https://flowrunner.ai/integrations/google-sheets) or the CRM record. When the value is needed again, Decrypt Text consumes the envelope directly, with no algorithm or vector to supply, and the authentication tag is verified before a single byte of plaintext comes back. A tampered ciphertext throws instead of returning something corrupted and plausible. ### Identifiers and tokens generated properly A provisioning flow issues API keys for new tenants, invite codes for their users and idempotency keys for the calls it makes on their behalf. The agent uses Generate Random Bytes for the keys and webhook secrets, drawing from the operating system entropy source rather than anything predictable, Generate Random String from the unambiguous character set for codes a person has to read aloud or type from a screen, and Generate UUID for the idempotency and correlation identifiers written onto every record in [Jira](https://flowrunner.ai/integrations/jira-issues). The same flow calls Hash File on each vendor download to compare it against the published checksum before anything is installed. ## Human-in-Loop Highlight The gate here is the strongest one this connector has, and it is a refusal to fail open. Verify HMAC returns a boolean rather than throwing precisely so a flow can branch, and the correct branch for a failed signature is to discard the payload. A single failure is ordinary noise: a retry, a truncated body, a proxy that rewrote something. A run of failures on the same endpoint means one of exactly two things, and they call for opposite responses. Either the provider rotated the signing secret and legitimate business events are now being dropped, or someone is posting forged payloads at a production URL. An agent cannot tell those apart from the signature alone, and both are expensive to get wrong: the first quietly loses orders, the second processes an attacker's data if anyone reacts by relaxing the check. So after a configured run of consecutive failures from one source, the agent halts that branch, holds the unverified payloads unprocessed rather than discarding them, and asks the operations owner in [Microsoft Teams](https://flowrunner.ai/integrations/microsoft-teams): "17 consecutive signature failures from the storefront webhook in the last 9 minutes, 0 successes in that window, last success 06:14. Held payloads are quarantined and not processed. Did the signing secret rotate, or should I keep rejecting and raise this to security?" No option offered on that card processes an unverified payload. The human is deciding what the failure means, not whether to trust it, and that distinction is what [human-in-the-loop](https://flowrunner.ai/concepts/human-in-the-loop) is for in a security path. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 12 actions ### Hashing and Checksums 3 - **Hash Text** Computes a cryptographic digest of a text or binary value using MD5, SHA-1, SHA-256, SHA-384 or SHA-512, returned as hexadecimal, Base64 or Base64 URL-safe, with an input encoding option for binary data supplied as Base64 or hexadecimal. MD5 and SHA-1 are offered for checksums and legacy interoperability only and must not be used for signatures, passwords or any security decision. - **Hash File** Downloads a FlowRunner file or any publicly reachable URL and computes its checksum with any of the same algorithms. Used to verify downloads against a vendor-published checksum, de-duplicate uploads, and compare files across systems. The file is buffered in memory, so it needs to fit within the execution memory limit. - **Compare Digests** Compares two digests, signatures or tokens in constant time, so the result cannot be used to recover the expected value one character at a time. This is the action to use instead of a plain equality check whenever a hash, signature or secret is being validated. Values of different lengths never match. ### Signing and Verification 2 - **Generate HMAC** Computes a keyed hash message authentication code over a value using a shared secret, returned as hexadecimal, Base64 or Base64 URL-safe, with a secret encoding option for binary keys. Used to sign outbound webhook payloads and to reproduce the signature a provider expects on a request. SHA-256 or stronger is the right choice; the MD5 and SHA-1 variants exist only for legacy interoperability. - **Verify HMAC** Recomputes an HMAC over a value and compares it to a supplied signature using constant-time comparison, which is the correct way to validate an inbound webhook from Stripe, Shopify, Slack, GitHub and similar providers. Accepts the expected signature in hexadecimal, Base64 or Base64 URL-safe, and returns whether it is valid rather than throwing, so a flow can branch on the result instead of failing the run. ### Encryption 2 - **Encrypt Text** Encrypts text with AES-256 using a key derived from a passphrase via scrypt with a fresh random salt, plus a fresh random initialisation vector on every run, so the same input never produces the same output twice. Returns a single self-describing envelope string carrying the algorithm, salt, vector and authentication tag alongside the ciphertext. AES-256-GCM is authenticated and detects tampering; AES-256-CBC is offered only for interoperability with systems that require it and provides no integrity protection. - **Decrypt Text** Decrypts an envelope produced by Encrypt Text and returns the original plaintext. The envelope carries everything needed except the passphrase, so no algorithm or vector has to be supplied. For AES-256-GCM the authentication tag is verified before any plaintext is returned, so an altered ciphertext or a wrong passphrase throws rather than returning corrupted data. ### Encoding 2 - **Encode Text** Converts UTF-8 text into Base64, Base64 URL-safe, hexadecimal or percent-encoded URL form. The URL-safe Base64 variant is suitable for URLs, filenames and JWT segments, and the two percent-encoding modes distinguish a query-string value from a complete URL that must stay usable. This is encoding, not encryption, and provides no confidentiality. - **Decode Text** Converts Base64, Base64 URL-safe, hexadecimal or percent-encoded input back into UTF-8 text. Input is validated strictly, so malformed data raises a clear error rather than silently dropping bad characters, and whitespace and line breaks in Base64 and hexadecimal input are ignored. Intended for text payloads rather than binary content. ### Random Values 3 - **Generate Random Bytes** Generates cryptographically secure random bytes from the operating system entropy source, returned as hexadecimal, Base64 or Base64 URL-safe. Used for API keys, session identifiers, salts, nonces and webhook secrets. A length of 32 bytes gives 256 bits of entropy and is a sound default; up to 4096 bytes may be requested. - **Generate Random String** Generates a random string of a chosen length from a selected character set, drawing every character without modulo bias. Used for passwords, one-time codes, invite tokens and temporary identifiers. The unambiguous set omits the characters people confuse when reading or typing a code aloud. - **Generate UUID** Generates one or more version 4 UUIDs from a cryptographically secure random source, suitable for idempotency keys, correlation identifiers and record keys. Available in the standard hyphenated form, a compact form, an uppercase form or the URN form. Up to 100 can be produced in a single run. ## Frequently Asked Questions ### What can FlowRunner do with Crypto Tools? FlowRunner agents can run Hash Text, Hash File, and Compare Digests in Crypto Tools, plus 9 more actions. ### Does connecting Crypto Tools to FlowRunner require OAuth? No. Crypto Tools needs no credentials at all, so there is no key to obtain, store, or rotate. ### Can Crypto Tools trigger a FlowRunner workflow automatically? Crypto Tools doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger. **Work at Crypto Tools?** This integration exposes Crypto Tools to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/crypto-tools. Site index: https://flowrunner.ai/llms.txt