It's the connector in the middle box. It decides what the agent can see and ask for, and the backend decides what it will allow. Before the 09:12 connection, the team needs three things in place: 1. A project with Lovable Cloud enabled, so there's a backend to connect to. 2. An agent that supports MCP, with credentials limited to what the task needs. 3. A named person who approves any change that writes or deletes data. The next section sets those limits one at a time, starting with permissions. ## Example of a Lovable MCP agent burning credits Every limit in the next section exists because of a run like this one: a broad task, a loop, and nobody watching for three and a half hours. The timeline below's illustrative, not a logged incident. At 09:12 the agent was connected over MCP with the project's full backend permissions, no spending cap and no approval step. That was a five-minute setup, and it meant that every later mistake would run unchecked. ### How a broad agent task damages Lovable data "Clean up duplicate customer records." That was the whole task. It's broad, and it had no stopping condition. The table shows each stretch of the run and what it left behind; the point's that the damage grew with every pass, not at one moment. | Time | What the agent did | Backend changes made | Credits spent | Records affected | |---|---|---|---|---| | 14:05 | Scanned the customer table | None | 4 | 0 | | 14:20 | Merged "duplicates" by name match | Rewrote rows, added a column | 38 | 340 | | 15:10 | Saw its own merges as new duplicates, reran | Edited a function, re-merged rows | 71 | 1,100 | | 16:00 | Retried after errors, widened the match | Changed table policies | 96 | 2,400 | | 17:30 | Stopped by a human | None | 41 | 0 | Every pass looked like progress to the agent, so it kept going. That's what a loop without a checkpoint does. At 17:30 someone noticed the credit balance had dropped. The agent had run 3 hours 25 minutes, **spent 250 credits and touched 3,840 records**. Because it was working in the live backend, restoring those rows meant hand-checking them against a stale backup. ### Real costs of runaway AI agent loops How much worse it can get is on the public record. [Sipi](https://sipi.bot/incidents/multi-agent-recursive-loop-47k-2026-03) lists an unnamed bill of $150 per incident, so a small loop can still cost a lunch budget. A LangChain loop cost $437, roughly three times that. A cron job reached $1,818, which means a scheduled task can repeat its mistake without anyone starting it. **$6,000 is what an overnight PR loop cost**, the price of leaving an agent unattended for a night, which is why unattended deployments need hard cost limits. The multi-agent loop cost $47,000, which is what happens when agents trigger each other with no ceiling, so agent coordination requires explicit safeguards. To cap that spread, set credit limits; permissions decide what the agent can touch before the loop starts. ## The unrestricted agent setup Nothing in the setup said no, so the agent was allowed. It had write access it never needed, no human had to approve a change, and no limit stopped a run that kept going. Spend limits only cap the damage; the permissions and the approval step decide whether there's damage at all, and a test copy decides whether it lands on real data. ### Why Lovable MCP permissions should be narrower When a connection gets set up, whatever credential works first gets used, and that's usually a broad one. An agent asked to summarize last week's sign-ups doesn't need to edit tables or delete rows, but if the connection allows it, a misread instruction can do it. The agent didn't go rogue. It used access nobody took away, so the fix belongs at connection time, not in the prompt. Without an approval step before changes, a plan and an action are the same event. The agent decides to alter a schema, and the schema is altered. A person who sees the proposed change first can catch the wrong table name or the unexpected delete before it runs. Skipping that step's what **turns a bad inference into a bad write**. ### No spend or step limit Once a loop has no ceiling, it retries, widens its search and calls the backend again, and every pass uses credits. Nobody notices until the plan's allowance's gone, and by then the loop has also had many chances to touch things it shouldn't.  Each of three controls stops something different and leaves something else open: | Control | What it stops | Setup effort | What it misses | |---|---|---|---| | Read-only access | Any write, edit or delete through the connection | Low: one permission choice when connecting | Tasks that genuinely need to write; sensitive data can still be read and repeated | | Staging project | Damage to live data and live users | Medium: a second project to build and keep in step with production | Drift, since a stale copy hides problems that only appear on real data | | Manual approval | Unreviewed changes of any kind | Low to medium: a person has to be in the loop for each change | Approver fatigue, where tired reviewers click through and a rubber stamp protects nothing | Because no single row covers the other two rows' gaps, the next step is to combine them rather than pick a favorite. ## Fix approvals with Activepieces, where it fits An MCP connection or an SDK gives an agent code to run, and the 09:12 setup shows what that leaves out: no tenant, no role, no record of what the agent did. Activepieces isn't Lovable's MCP. It sits beside it as a separate workflow layer and treats the agent as a user, the way you'd treat an employee. SSO, SCIM and RBAC set what the agent may connect to, and the run detail view lists each tool call on its own line with its input and output, so a bad write traces back to one step. The trigger's the agent proposing a change. The approval step's a person saying yes. The order below shows where the change waits, and the point to take from it's that **nothing reaches Lovable Cloud until step five**. 1. The agent proposes a change, such as a schema edit or a bulk row update, and sends it to the flow instead of applying it. 2. The flow catches the proposal as its trigger and holds it. 3. The flow messages the approver in Slack or by email, with the change spelled out. 4. The approver accepts or rejects. 5. The change applies only on approval; a rejection ends the run. 6. The flow logs the decision, who decided and when. Most setups skip step six, the log. When a run goes wrong, it tells you who said yes to what. Now the cost. [Activepieces](https://www.activepieces.com/pricing) gives the Free tier ($0) 1,000 credits a month, enough to test whether the flow works and to cover a solo builder who proposes few changes.  Plus ($20) gives 10,000, which suits a small team where several agents propose changes daily, so they'll comfortably stay within their approval budget. At Team ($200) you get 50,000, which only makes sense once many agents run in parallel, which means it's overkill below that scale. Before picking, run the flow a few times and see how many credits one proposal burns. That figure, not the tier name, tells you how long a month lasts. In two cases the extra layer isn't worth it. One's a throwaway project with no real user data, where a bad run costs you an afternoon. The other's an agent limited to read-only permissions, since there's nothing to approve. And a flow nobody reads's the "set and forget" version of this, so name the approver before you turn it on. ## Rules before agent connection Do the rules as one checklist, on a Monday, before the agent touches anything, and keep the order, because each step limits the damage of the next. Read it top to bottom: permissions come first because everything after assumes the agent can't reach more than it should. 1. Set least-privilege access: give the agent only the tables and actions its one job needs, and nothing that deletes or changes structure. 2. Create a staging copy of the backend with scrubbed data, and point the first connection there, not at production. 3. Set a credit alert against the plan limit, so a looping agent trips a warning before it burns the month's allowance. 4. Name the approver, one person by name, who signs off on any write the agent proposes. 5. Record a dated re-check of Lovable's pricing and docs, with an owner and a calendar entry. None of these are hard. Skipping the staging copy's the usual mistake, because the first run looks fine on clean data, and the trouble starts when the agent meets a messy real field. ### Monitoring your Lovable MCP agent in week one Run the agent against staging only and read what it did, not just whether it finished. Check the log against the permissions you set: any action you didn't expect means the access is too wide, so narrow it before moving on. Watch the credit alert too. If it fires on routine work, the task's costlier than you assumed, and you want to learn that on staging. Have the approver review every proposed write here, and don't promote the agent to production until they have seen a run that went wrong and caught it. ### Monthly review of Lovable pricing and MCP docs Open the dated reminder from step five and compare Lovable's current pricing and docs against what you recorded. Plan limits and MCP behavior can change, and a credit alert tuned to last month's limit protects nothing if the limit moved.  Update the alert, the permissions and the approver's remit, then write down the new date. Without that entry, the checklist turns into the "set and forget" setup this article warns against. ## Frequently asked questions Is Lovable Cloud MCP free to use? Unconfirmed. Whether the Free plan can open an MCP connection at all isn't something this article can verify, so check Lovable's pricing page before you plan around it. Until you have, assume you need a paid plan and budget for it. Can I connect Claude or Cursor to Lovable Cloud? Any MCP-capable client's a reasonable candidate, but a named list of supported clients's unconfirmed. Lovable's documentation's the place to see which clients it supports today. Don't assume a client works because it speaks MCP in general. Does MCP access use up my Lovable credits? Unconfirmed. Treat every agent action as potentially billable until Lovable's documentation says otherwise. A looping agent's the case that hurts, which's why the credit limit goes in before the first connection, not after the first runaway session. Can I stop an agent from deleting data? Yes, by limiting what the agent is allowed to do. Give it read-only or narrowly scoped access, and put a human approval step in front of anything destructive. An agent can't delete what its permissions don't cover, and it can't act without sign-off if you require it. ### Where do I check current Lovable pricing? Check Lovable's own pricing page, and nowhere else. Plan terms change, and third-party summaries go stale. Until Lovable confirms them, four questions stay open, and each has a place to check: - Overage rates when credits run out: Lovable's pricing page, unconfirmed. - How many tools the MCP connection exposes to an agent: Lovable's documentation, unconfirmed. - Whether the Free plan can connect: Lovable's pricing page, unconfirmed. - Whether MCP calls draw down credits: unconfirmed. Until those answers are on a Lovable page, write each one into your setup notes as an open item. An open item with a named owner's a check. A silent assumption's how the "set and forget" setup comes back. ## Related reading - [Snowflake Pricing Explained for 2026 Data Teams](https://www.activepieces.com/blog/snowflake-pricing-explained-for-2026-data-teams) - [GitHub Copilot Fusion Explained for AI Coding Teams](https://www.activepieces.com/blog/what-is-github-copilot-fusion-ai-model-routing) - [AI Agents for Legal Teams: What’s Possible Now](https://www.activepieces.com/blog/ai-agents-for-legal) ## References - [Lovable](https://lovable.dev/pricing) - [Activepieces](https://www.activepieces.com/pricing) - [Sipi](https://sipi.bot/incidents/multi-agent-recursive-loop-47k-2026-03)People assume the protocol enforces limits it never promised to. It doesn't.