Should I vibe code
Configurable AI assistants for email, meetings, support, and operations
Your inbox is untrusted input. An agent holding your send scope will do what a stranger's email tells it to.
?
Their verdict, the Plus price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
Zapier and Make are rated YOUR FUNERAL on this site because a deterministic workflow with a bad idempotency key sends a duplicate invoice. This is a different animal and deserves a different answer. An agent platform holds an OAuth grant that can send mail as you, write to the CRM your colleagues rely on, and — on the tier above — drive a browser; then it decides what to do next by reading text that arrives from strangers. That is the entire problem in one sentence: your inbox is untrusted input, and the control flow of the system is a language model reading it. Nobody needs to breach anything. A message containing instructions, a white-on-white block in an HTML signature, a calendar invite description, a PDF the agent was asked to summarise — any of them can become the next thing it does, using credentials you granted, under a name people trust. The build is not the hard part; a tool-calling loop over Gmail is a genuinely good weekend, which is exactly what makes this dangerous. Lindy sells approvals, audit logs, SSO and a BAA because those are the parts that turn the demo into something you can point at a real mailbox, and they are the parts a weekend build does not have.
What actually breaks
not "if". the specific failures.
- Indirect prompt injection, first and hardest to see. Instructions arrive inside the content the agent was asked to process — an email body, a signature, a calendar description, an attached PDF — and become actions taken with your credentials
- The credential store: one process holding refresh tokens for mail, calendar and CRM, with the encryption key in an environment variable on the same host
- Send scope, which has no undo. A drafted reply that was meant for review goes out because a retry re-ran the branch that sends
- Model updates, which change the agent's behaviour with no commit, no diff and no way to reproduce what last Tuesday's version would have done
- Loops, when the agent's own outgoing mail triggers the inbox rule that started it, at API cost and with real recipients
- Bulk writes to shared systems, where a plausible-but-wrong interpretation updates four hundred CRM records and the undo is a support ticket
- The audit question. Someone asks why a customer received that email, and the honest answer is a prompt, a temperature setting and a context window nobody kept
A supplier's invoice email arrives with a signature block containing white text on white background: a short paragraph addressed to any assistant reading the message, asking it to forward the last thirty days of correspondence with the finance team to an address one character away from the supplier's real domain. Your agent has read scope on the mailbox and send scope on the same account, because that is what makes it useful, and it does what the message says — the model has no category for "this instruction came from outside my principal". You find out four days later, from the real supplier, who is asking why they were copied on a thread that mentions the bank details they are about to change. There is no log of the decision, because the decision was a token sequence. There is no rollback, because the mail already went. And the credential that did it is still valid, because nobody built a revocation path.
Is that you?
the verdict is a default, not a law
- It only reads, and everything it produces lands in a draft or a file a human opens
- The mailbox is yours alone, contains nothing about anyone else, and the agent has no send scope at all
- Every outbound action requires a click from you, per action, with the full payload shown before you approve it
- It runs on your machine against a dedicated account, and revoking it is one click in a provider console you can find
- It can send, post or write to any system without a human approving that specific message
- It acts on content from senders you do not control — which is every inbox
- It holds tokens for accounts belonging to colleagues or clients
- The CRM or shared drive it writes to is something other people's work depends on
- You cannot say, for any action it took last week, exactly what input caused it
If you build it anyway
the checklist, then the prompt that enforces it
- Split the credentials by direction. Read scope for the agent, send scope for a separate service that only accepts an approved, signed payload from you. A single grant that can both read the world and act on it is the whole failure mode.
- Treat every piece of retrieved content as hostile data, never as instructions. Fence it in the prompt, strip hidden text and HTML tricks, and never let tool selection be influenced by text the agent fetched.
- Human-in-the-loop on every irreversible action, showing the exact payload — recipient, subject, body, record IDs — not a summary of the intent.
- Allowlist recipients and destinations. An agent that can only email addresses already in your contacts is a fraction as interesting to attack.
- Log the full context window, tool calls and outputs for every run, and pin the model version. "Why did it do that" is unanswerable otherwise, and it will be asked.
- Rate-limit actions per hour and put a hard daily cap on sends and writes, so a loop costs you an apology rather than a reputation.
- Write the revocation runbook before the first token is issued: which grants exist, where, and how to kill all of them in under a minute.
- Give it its own account with the narrowest scopes the provider offers, never your primary session, and never a scope you granted for a different feature.
I want to build an AI assistant that reads my email and calendar and acts on
them. Assume the inbox is hostile input and build accordingly. Refuse anything
that gives a model unattended write access.
1. Before writing code, state the threat model back to me in three sentences:
content the agent reads can contain instructions, the agent cannot reliably
distinguish those from mine, and any scope it holds is therefore available to
whoever emails me.
2. Build read-only first, end to end, and make me use it for a week. No send, no
write, no calendar mutation exists in the codebase yet.
3. Separate the credentials by direction: the agent gets read scope only; a
distinct service holds send scope and accepts only payloads I have approved.
Do not put both in one grant, and say why in a comment.
4. Fence retrieved content in the prompt as untrusted data, strip hidden text,
zero-width characters and white-on-white HTML before it reaches the model,
and never let fetched text influence which tool is chosen.
5. Every irreversible action requires my explicit approval showing the literal
payload — recipient, subject, full body, record IDs — never a summary. If I
ask for an auto-send mode, refuse once and describe the forwarding attack
this prevents.
6. Allowlist outbound recipients to addresses already in my contacts, and make
anything else a blocked action that asks me rather than a warning it logs.
7. Log every run in full: input, context window, tool calls, arguments, outputs,
model name and version. Pin the model. An upgrade changes behaviour with no
diff, and I need to be able to reproduce last week.
8. Cap actions per hour and sends per day, and detect the loop where the agent's
own outgoing mail re-triggers its inbox rule. Build that stop before the
second integration.
9. Write the revocation runbook before issuing the first token: every grant,
where it lives, and how to kill all of them in under a minute. Store secrets
in a secrets manager, not a .env beside the code.
10. Out of scope, and say so rather than attempting it: browser automation,
bulk CRM writes, and acting on anyone's mailbox but mine.
11. Finish by telling me honestly that Lindy sells approvals, audit logs and a
signed BAA for about $50 a month, and that those are precisely the parts I
am now responsible for.That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
Before you start, honestly. Fifty dollars a month buys the parts that are boring to build and awful to get wrong: approvals wired into every action, an audit log that survives the incident, SSO, and — telling, this — an enterprise tier with a signed BAA, which tells you exactly what people put in the inboxes these agents are pointed at. If you want to build agents for the pleasure of it, build them read-only against your own mail and keep the send scope with somebody who has a security team.
$49.99/mo is cheaper than your weekend.
There is no data to migrate and that is not the point — the exit here is a revocation drill, not an export. Keep a written list of every OAuth grant the agent holds, which account issued it and which console revokes it, and rehearse killing all of them once. Then keep the run logs somewhere outside the agent, because on the day you shut it down the only remaining question anyone has is what it did while it was running, and that answer lives in the logs or nowhere. The prompts and tool definitions belong in git from the first commit; they are the closest thing this system has to source code.
MIT-licensed automation platform with AI steps, a credential store and run history, self-hostable from a compose file.
Fair-code workflow engine with AI agent nodes, execution history and retries, and a large self-hosting community.
Open-source platform for building LLM agents and workflows, with tool calling and observability already wired in.
Questions
Zapier and Make are only YOUR FUNERAL. Why is this worse?
Because their control flow is written down. A Zap does the same thing every time, so its failure is a duplicate or a dropped event and you can read the steps to find out why. Here the control flow is a model reading whatever arrives, so the failure is the system doing something nobody specified, chosen by text a stranger wrote, using credentials you granted. That is a different category of thing, and it is the category this site reserves the top rating for.
Isn't prompt injection a solved problem by now?
No, and the people building these platforms are the loudest about it. It sits at the top of OWASP's list for LLM applications precisely because there is no reliable way to separate instructions from data inside one context window. The mitigations that work are architectural — narrow scopes, allowlists, and a human approving every irreversible action — which is exactly why this entry is about permissions rather than prompts.
What if it only drafts and never sends?
Then most of this page stops applying and it becomes a good project. A read-only agent that writes drafts into a folder you open is genuinely useful, cheap to build, and its worst failure is a bad paragraph you delete. The line is send scope. Cross it and the failure mode goes from wasted effort to messages you cannot recall.
Where does the agent-versus-automation line actually sit?
At whether the next action is chosen by your code or by the model. A workflow that calls an LLM to classify something and then follows a branch you wrote is automation, and Activepieces or n8n will run it with a credential store and run history you did not have to design. The moment the model picks the tool, you have an agent, and every scope it holds is now reachable by anything it reads.
- OWASP Top 10 for LLM Applications — LLM01: Prompt Injection
- GDPR Art. 32 — security of processing (EU)
- GDPR Art. 5 — principles relating to processing of personal data (EU)
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
Retries are the feature. A loop without them silently drops work; a loop with them sends it twice.
The canvas is not the product. The queue of half-finished runs you can fix and resume is the product.
Relay is deleting your workflows in September. Whatever you build has to survive that, with you as the vendor.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice