Lindy Security Basics

Lindy Security Basics

Overview

Secure Lindy workflows at the boundaries Lindy currently documents: generated Webhook Received secrets, per-action connected-account selection, target-service authentication in HTTP Request, Ask for Confirmation/draft modes, dedicated Computer Use sessions, Tasks, and Test Panel. Do not rely on an undocumented Lindy API key, webhook signature, role, connection-sharing level, fixed quota, or plan entitlement.

Prerequisites

• Lindy workspace with an editable custom agent
• Inventory of triggers, actions, connected accounts, external endpoints, data classes, owners, and consequential side effects
• Sanitized fixtures and test/sandbox integrations

Instructions

Step 1: Draw the Trust Map

For every path, record source, destination, data fields, credential owner, selected connected account, allowed side effects, approver, failure path, and evidence source. Separate these directions:

Step 2: Secure Webhook Received

1. Create the webhook inside the Webhook Received trigger.
2. Generate the secret, copy it once, and store it in the caller's secret manager.
3. Send it only in the Authorization bearer header to the generated HTTPS URL.
4. Keep the webhook URL/secret out of prompts, bodies, query strings, task titles, screenshots, logs, and tickets.
5. Minimize and validate the caller's payload before transmission.
6. Rotate after suspected exposure by creating/reconfiguring the protected boundary, verifying the replacement, and retiring the old value according to the current UI.

The bearer secret authenticates the caller to Lindy. It does not authenticate a callback from Lindy to your application, and Lindy's Webhooks guide does not document an HMAC signature or timestamp header for that callback.

Step 3: Scope Connected Accounts and Actions

Lindy documents that each action selects one connected account. For every action:

• select the account with the minimum data and authority required;
• prefer a dedicated work/test account when the integration supports one;
• remove actions and connections no longer required by the workflow;
• avoid combining broad read and consequential write abilities in an autonomous Agent Step when deterministic actions/conditions are sufficient; and
• use a dedicated Computer for an agent that needs Computer Use so saved sessions and site credentials are not shared across unrelated work.

Do not invent local permission dictionaries or quotas and describe them as Lindy controls. Enforce application-owned authorization again at any external receiver.

Step 4: Put Humans Before Consequential Side Effects

Enable Ask for Confirmation on supported actions that send messages, update records, create events, or cause other consequential effects. Use draft mode where available. Add condition-based escalation for unknown/out-of-scope cases. Keep confirmation enabled until representative testing and review justify a deliberate change; money, contracts, access changes, deletion, and sensitive external communications should retain explicit approval.

Step 5: Minimize Data Across Every Step

• Use stable references instead of full messages/documents where possible.
• Do not pass all webhook headers or the entire body to later actions.
• Send HTTP Request only fields required by the target schema.
• Bound lengths, collection sizes, nesting, and allowed enum values.
• Never print secrets or sensitive inputs in Run Code; stdout becomes text.
• Keep task links restricted because Tasks can expose step inputs and outputs.
• Redact incident/evaluation exports; retain details only in approved systems.

Prompt instructions are defense in depth, not authorization. Conditions, selected accounts, receiver-side checks, confirmation, and schema validation must enforce the boundary even if model output is incorrect or adversarial.

Step 6: Test Fail-Closed Behavior

Use synthetic data and test accounts. Lindy's Test Panel executes real actions. Verify valid flow plus wrong/missing webhook secret, oversized/unknown payload, unexpected outbound host, target 401/403/429/5xx, malformed response, attempted prompt injection, missing approval, and untrusted callback content. Each negative case must stop, quarantine, or request human review without completing its side effect.