Front, the shared-inbox and customer-communication platform, now ships an MCP server: a single OAuth-authenticated endpoint that lets AI agents search conversations, draft and send replies, post internal comments, and change tags and assignment. Read the developer documentation and the boring details turn out to be the interesting ones. The headline is not “agents can read your inbox.” The headline is that every tool call is attributed to a specific teammate, and the agent’s permissions are exactly that teammate’s permissions.
That is the pattern agency operators need to internalize in Q4 2026. When inbox, CRM, and helpdesk vendors expose MCP endpoints, the procurement question stops being “does it integrate with our AI tool?” and becomes “as whom does the agent act, and what is that identity allowed to touch?” That is an operations question, and most agencies do not yet have a name against it.
The identity model is the real feature
Front’s MCP server authenticates per user: an agent authorizes as a teammate, with scopes of read, write, and send, and inherits that person’s role. If the teammate cannot see an inbox, neither can the agent. Write tools that change something a user can see carry destructiveHint: true, which prompts MCP clients to ask for confirmation on each call.
Compare that to how most agency automation was wired until recently: a shared API key in a password manager, a service account nobody owns, and a Zapier chain with admin-level reach across every client workspace. The MCP model is a genuine improvement in accountability, and it creates a new class of operational failure for teams that treat the agent connection as a setup task instead of a seat assignment.
Three things to read before you connect anything
1. Token model. Per-user OAuth is what you want. A tenant-wide service credential means the agent’s blast radius is the whole workspace, and the audit log tells you nothing useful when something goes wrong at 2 a.m. Ask for the endpoint, the transport, and the scope list in writing.
2. Write confirmation. If the vendor marks state-changing tools as destructive and your client prompts per call, keep the prompts. Agencies disable them for speed roughly one week before their first accidental mass reply. Human-in-the-loop on sends is not friction; it is the control that makes the rest of the automation defensible in a client review.
3. Client compatibility. Front’s docs are explicit that some AI clients cannot connect at all, because the server requires a confidential OAuth connection and does not support Dynamic Client Registration. If your team has standardized on an incompatible assistant, the integration is theoretical. Confirm the client works before you promise a client a workflow. Also note which endpoints are beta and which are generally available; do not put a contractual deliverable on a beta surface without a manual fallback.
Four ways agencies get this wrong
- The admin-token shortcut. One credential for the whole agency is convenient for two weeks and unattributable forever. When an agent tags the wrong client’s conversations, “who did this” has no answer.
- Client workspace bleed. An agent wired into the agency’s own workspace should not also be able to reach a client’s. Separate workspaces, separate tokens per client, separate scopes. This is the same isolation problem you already solve for reporting access — see our notes on what changes when clients get their own agent.
- Offboarding that stops at the human. You remove the teammate from the workspace and forget the agent that was authorized as them. Add agent connections to your offboarding checklist next to email and ad accounts.
- Seat math nobody budgets. Agents that authorize as users consume seats and rate limits like users. Plan agent connections per client workflow, not per headcount.
A four-week rollout that ends in a working workflow, not an incident
Week 1 — read only. Connect with read scope. Have the agent summarize a week of one inbox and produce nothing that a client sees. The only goal is to learn which tool calls it picks and how often it gets them wrong.
Week 2 — drafts and internal comments. The agent drafts replies and leaves internal notes; a human sends everything. Measure how much editing each draft needs. If your team rewrites more than half of them, the prompt is wrong, not the model.
Week 3 — reversible internal writes. Tags, assignment, status changes. All of it visible in the tool and undoable in seconds.
Week 4 — one send workflow, one named owner. Pick the narrowest outbound workflow you have — a renewal follow-up, a support acknowledgment — and give it a single accountable human and a review window. Every stage has the same rollback: revoke the token.
This sequencing is the same guardrail logic we laid out in set the guardrails before agents spend, applied to a surface where a mistake is customer-visible within seconds instead of a week later in a billing report.
Operating it after launch
Three standing routines, none of them glamorous. Own the identity: a registry listing every agent connection, which human seat it runs as, what scopes it holds, and who is accountable for it. Review the writes weekly: pull the tool-call history and look at what the agent actually changed, not what it was asked to change. Audit scopes quarterly: agents that only read should not still hold send because it was easier during setup.
One more risk deserves a line in your runbook: inbox content is untrusted input. Any message a client or a stranger can send is text an agent with send scope will read. Treat prompt injection as an operations threat with a real blast radius, which means the human confirmation step on outbound messages is the control that matters most.
What to ask vendors from here
Four questions, in this order: does the product expose an MCP server today, is the token per user or per tenant, what are the scope boundaries and are writes marked destructive, and what does the audit log record per tool call? A vendor that cannot answer all four has not shipped an agent-ready integration. It has shipped a feature demo, and you will be the one supporting it.
If you are deciding which of your client-facing tools should expose an agent seat this quarter and which should stay read-only, have us audit your agent access model before the first token is issued. It is a shorter conversation than the incident review, and it produces a document your clients can sign off on. For the reporting side of the same stack, see where agency AI actually pays off.