Lindy Security BasicsSAFE

Model-agnostic agent-skills platform with a harness-free canonical layer, verified adapters, and the ccpi package manager. Explore at tonsofskills.com.

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: lindy-security-basics
description: 'Implement security best practices for Lindy agents and integrations.

  Use when securing webhook secrets, scoping connected accounts,

  controlling side effects, or auditing agent access.

  Trigger with phrases like "lindy security", "secure lindy",

  "lindy webhook security", "lindy permissions", "lindy audit".

  '
allowed-tools: Read, Write, Edit
version: 1.20.0
license: MIT
author: Jeremy Longshore <[email protected]>
tags:
- saas
- lindy
- api
- security
compatibility: Designed for Claude Code
---
# 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:

| Direction | Supported boundary |
|---|---|
| Application to Lindy | Webhook Received URL + Lindy-generated bearer secret |
| Lindy to external service | HTTP Request + that service's authentication |
| External account action | Exactly the connected account selected on the action |
| Lindy callback to application | Receiver-owned trust boundary; no documented Lindy signature claim |

### 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.

### Step 7: Review Tasks and Current Account Controls

Use Tasks to inspect the exact step order, selected paths, inputs/outputs, errors, and
timestamps after testing and deployment. Review connected accounts and agent actions
on a defined owner-approved cadence. For organization identity, audit, compliance,
or contractual controls, verify current availability and configuration in Lindy's
official security/pricing material and your workspace; do not freeze plan claims in
this skill.

## Security Checklist

- [ ] Trust map covers every inbound, outbound, connected-account, and callback path
- [ ] Webhook Received uses the generated bearer secret and exact generated URL
- [ ] Secrets are distinct, nonempt

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.