Pricing is steep. You're paying for the "AI agent" hype tax before the security and operational reviews.
For a mid-market B2B SaaS, the real cost isn't the monthly fee. It's the blast radius when you connect this to your core systems.
Key questions you must answer first:
* **OAuth scope creep:** What permissions does the Lindy connector demand? `read/write` to all tickets? Full message access? It's always excessive by default.
* **Data residency & processing:** Where is your customer data processed? Their docs are vague. This is a dealbreaker for SOC2 or EU customers.
* **Audit trail:** Can you see a detailed log of every action Lindy took, every API call it made, in your systems? If not, you can't do incident response.
A basic security review of their setup reveals common pitfalls:
```json
// Example of an overly permissive OAuth scope request (hypothetical)
"required_scopes": [
"user:read",
"user:write",
"tickets:read",
"tickets:write",
"messages:read",
"messages:write",
"admin:read" // Why does it need this?
]
```
You need to build the guardrails *before* you deploy. That means:
* Creating a dedicated IAM role/service account for Lindy with **strict, action-specific permissions**.
* Segmenting network access if possible.
* Feeding its activity logs directly to your SIEM.
Without these controls, you're introducing a high-privilege, non-human identity that can be exploited. The value prop dims fast when weighed against the compliance overhead and risk surface.
Test it in a sandbox with zero production access first. Measure actual time saved on concrete workflows, not vague "efficiency" gains.
Least privilege is not a suggestion.