Connect Trello to Copilot via a scoped AI agent with an approval gate
A scoped Trello connector lets an AI agent read boards, lists and cards through Copilot while every write waits for human approval.
Last updated
8 minute read · Written by the team that builds UtilitySpaces. More about UtilitySpaces.
Connect Trello to Copilot in UtilitySpaces by adding the Trello connector to your workspace once and exposing it to Copilot — the conversational AI that answers questions and acts on a prompt. To connect Trello to Copilot, you use a scoped connector that restricts the agent to five specific tools: three read-only tools for fetching boards, lists, and cards, and two write tools for creating cards and adding comments. Unlike a raw API key, this setup ensures that no card is ever created or modified without a person first reviewing the proposal in the approval queue. This architecture prevents accidental board clutter and ensures a least-privilege boundary, where the agent handles the discovery and drafting while a human retains final control over every durable change made to your Trello workspace.
You can try this setup with a demo.
What “connect Trello to Copilot” means (and what it does not)
To connect Trello to Copilot, create one API key connection in the Trello integration and add it to a workspace that has Copilot enabled. The connector does not hand the raw credential to the agent; it exposes five named tools that the agent calls by exact name rather than composing Trello API URLs, which caps what it can reach. Three are read-only — Get my boards, Get board lists, and Get list cards — and run open. The two writes — Create card and Add comment — are the only tools that can change Trello, and each goes to the approval queue first. Reads open, writes wait. Every call is written to the hash-chained audit log, and a monthly cost ceiling bounds Copilot compute. The agent can read boards, but no card is created or commented on without approval first.
This is not a chatbot that only reads Trello data back to you, nor a raw API key handed to an agent with nothing in front of the writes. It is not the same surface as the general-purpose Trello AI agent — that covers broad access; this connector is scoped to the five tools above, and every write stops for review.
What Trello actions can the scoped connector access?
The connector does not expose the raw API. It exposes five named tools, and because tool matching is exact, the agent calls them by name rather than composing a URL — which sets a hard ceiling on what it can reach. The catalogue is generated from the live tool list, so it cannot name a tool that does not exist. The table below is the real surface, not a wishlist.
| Tool | What it does | Read or write | Stops for approval? |
|---|---|---|---|
| Get my boards | List boards for the member | Read | No |
| Get board lists | List the lists on a board | Read | No |
| Get list cards | List the cards in a list | Read | No |
| Create card | Create a card in a list | Write | Yes |
| Add comment | Add a comment to a card | Write | Yes |
Three reads are always permitted — no gate, no extra grant. They let an agent summarise a list, surface overdue cards, or flag items sitting in a “Doing” or “Blocked” column. The two writes stay closed until a person signs off. The connector exposes nothing for moving cards between lists, editing descriptions, adding labels, or changing due dates — if that work depends on those actions, surface it through a separate Trello export first.
Why is handing an agent a raw Trello key too much trust by default?
A raw Trello key or token carries account-wide access, and an agent connected with nothing but the key can compose any endpoint it allows — not just the five tools a scoped connector would name. The blast radius is the entire workspace, on every run. A wrong read is recoverable; a wrong write — a card created in the wrong board or a comment added by mistake — is durable the moment it leaves. That is not a least-privilege boundary.
The case for an approval gate when an agent touches business apps is plain: only what a person can take back should happen without asking, and a card created or commented on in Trello is not always take-backable. The gate enforces least privilege by design.
How do I connect Trello to Copilot in three steps?
- Add the Trello connector to your workspace from the connected apps page, using the API key and API token you create in Trello. The credential is encrypted in place, bound to the workspace, and never read back — the agent never holds a raw secret to copy out.
- Enable Copilot for the workspace, which exposes the connector’s tools through the conversational interface. An agent can now read boards and lists by name, but cannot act.
- Confirm the approval gate is set to “ask before every write” — the default — or switch to “auto-approve after admin review” for a lighter touch. The setting changes who is in the loop, not whether there is one.
Where does the agent stop and ask for approval?
The agent does not ask in chat. When it decides a write is warranted — “this blocked card needs a ticket in the backlog,” or “this overdue item should get a follow-up comment” — the proposal does not go straight to Trello. It lands as a request in the shared inbox, where the action, the target Trello board and list, and the proposed values appear for a one-click approve or reject. Designing the moment an agent stops and asks is where that discipline is designed, and the queue itself is managed on the approval gate page.
A reviewer sees the payload, not a description: the board name, the list it will go to, the card title and description, the status it will receive. Approving runs the write as a real Trello call; rejecting sends it back so the agent can refine. The request appears where the work lives — in the shared inbox — or as an inline button, so it does not sit in a separate console to be forgotten. The managed AI agents enforce it at the write: a wrong read is recoverable, a wrong write is durable, and the gate is how that is enforced.
How does the audit trail and cost ceiling protect you?
Every run — including the ones where the agent found nothing to say — is written to the hash-chained audit log. A hash chain means nothing deleted or altered can pass unnoticed: each entry records the tool, its arguments, its result, and the approver’s identity. The log proves an agent called a tool and that a person approved the write; it does not prove the reasoning was correct, only that the boundary was enforced.
The cost ceiling works the same way at the budget layer. A hard monthly limit on Copilot compute means a standing schedule that runs every morning cannot surprise you with an unexpected bill. Review both on your own schedule; a ten-minute weekly glance catches a drifting role faster than any alert, because no alert understands your process like a person reading the output.
Why not just use a raw Trello API key?
The choice is between a key with nothing in front of the writes and the same key with a per-action approval gate. UtilitySpaces offers: the credential is stored encrypted and bound to your workspace, reads stay open, writes stop at the gate, with no option four. The table below contrasts the two approaches.
| Aspect | Trello API key + Copilot | UtilitySpaces Trello connector + Copilot |
|---|---|---|
| Write access | Full access to all boards | Per-tool scope: 3 reads + 2 writes |
| Credential | Single key, no rotation | API key + token, encrypted in place, never read back |
| Approval | None — writes land directly | Approval gate on every write |
| Audit | No record of what the agent did | Hash-chain audit trail |
| Cost control | No ceiling on Copilot compute | Monthly cost ceiling |
The same pattern is already in production for Mailchimp: see how Connect Mailchimp to Copilot applies the same read-open, write-gated contract to a different app. In both cases, the agent reads through named tools, the writes stop at the gate, and the boundary is visible to a reviewer before any app change lands.
What work do teams actually hand an agent in Trello — reports or writes?
Teams hand an agent the board-reading work first. Three jobs come up again and again, all read-scoped so value appears without a write leaving the gate.
- Report what is sitting in a “Doing” or “Blocked” list each morning by reading its cards and writing a summary to the inbox.
- Surface a card into chat when a related decision lands elsewhere, so the card stays the record.
- Draft a card in the intake list when a request arrives in a chat thread the board tracks — the draft stops for approval before it is created.
The hard rule is visibility: the agent reads only the boards the API key can see, and a new card or added comment is visible to everyone at once — keep both writes on approval for any board shared outside the team. On a schedule, keep the role text tight and require a report even when nothing was found; the cost page shows a weekly cadence that found nothing is cheap to keep running, and it keeps the agent honest.
Limits, trade-offs, and when not to use a Trello AI agent
Not every Trello job is ready for an agent, even with the gate. The hard boundary is the two write tools: the connector can create cards and add comments, but cannot move a card between lists, edit its description, add a label, or change its due date — so do not ask the agent to tidy a board.
The deeper limit is the credential. A Trello API key is account-wide, so the gate is the only thing between a wrong plan and a write to a live board. That holds while someone reads the approval on every run, not once approvals are batched and rubber-stamped. The agent is not a replacement for Trello’s own interface; it is a way to fold Trello reporting and triage into a larger workspace routine, with two writes that always wait.
The honest limitation is not the agent’s reasoning — it is the boundary you set. Read tools stay read; the two write tools stay gated; and the API key is safe to hand over only while a real person is behind that gate on every run. Start with read tools only, confirm one board summary looks right in the inbox, then enable a single write and watch the first proposals — not the writes — land in the approval queue.
We build UtilitySpaces, a managed service for teams. It routes an AI agent to a runtime and a provider of your choice, but does not train or serve models. Trello connects through our connector, and every write is stopped by a human approval before it reaches Trello. To run an agent on a real Trello board, see pricing or connect Trello.
Keep reading
- Asana qualified: the five gates an AI agent must pass before it touches your Asana tasks — how to verify a connected agent before letting it write.
- GPT-6 Astra: the automated AI engineer that still needs your approval gate and cost control — why capability without a gate is not production readiness.