How do I let an AI assistant send emails and create tickets without giving it full access to everything?

Most teams hit the same wall with AI assistants: you want the assistant to send emails, create tickets, and update systems, but you do not want to hand it a master key to Gmail, Jira, Zendesk, Salesforce, and everything else. The good news is you don’t have to choose between “no access” and “unlimited access” if you design the authorization layer correctly.

Quick Answer: You let an AI assistant send emails and create tickets safely by running it on a controlled MCP runtime (like Arcade), using user-specific OAuth scopes, permission gates, and an audit trail—so the agent can perform specific actions (e.g., send email, create ticket) without getting full access to every system or every user’s data.

Frequently Asked Questions

How can I let an AI assistant send emails and create tickets without giving it full access?

Short Answer: Use user-scoped OAuth, tightly-scoped tools (like Google.SendEmail or Jira.CreateIssue), and an MCP runtime that enforces permissions in code—not in prompts—so the assistant only performs approved actions on behalf of each user.

Expanded Explanation:
The unsafe pattern is giving an AI assistant a shared service account that can do anything in your systems. That’s how you end up with a “god bot” that your security team will never approve. The safe pattern is to treat the agent like any other app: each human user authorizes it via OAuth, you scope what it can do (e.g., “send email” but not “delete mailbox”), and a runtime sits between the model and your systems to enforce that contract.

With Arcade’s MCP runtime, the model never sees raw credentials. Instead, the agent calls tools like Gmail.ListEmails or Google.SendEmail, and Arcade injects the right user tokens at runtime, enforces scopes, and logs every action. The assistant feels powerful to the end user (“send this to the customer and file a ticket”), but under the hood it only operates inside the permissions and tools you’ve explicitly allowed.

Key Takeaways:

• Use user-specific OAuth, not shared service accounts.
• Restrict the assistant to explicit tools (send, create, list) instead of broad API keys or full admin access.

---

What’s the right process to set this up for Gmail and ticketing systems?

Short Answer: You register OAuth apps for each system (Gmail, Zendesk, Jira, etc.), plug them into an MCP runtime like Arcade, then expose only the tools you want the assistant to use, such as sending email or creating tickets.

Expanded Explanation:
You don’t wire your LLM directly to Google or your ticketing API. You wire your LLM to an MCP server and runtime that speaks your systems’ APIs on its behalf. The flow looks like a standard OAuth-backed app: user logs in, grants scopes, and from then on the runtime holds and refreshes tokens. The agent just calls tools; it never touches secrets.

Arcade bakes this pattern in. You configure Google and your ticketing providers once. The Arcade runtime handles auth.start to kick off OAuth, wait_for_completion to get the result, and then gives your agent a clean tool surface—Gmail.ListEmails, Google.SendEmail, Zendesk.CreateTicket, Jira.CreateIssue, etc.—with user-specific permissions automatically enforced. No more rolling your own token store or debugging refresh tokens at 2 a.m.

Steps:

1. Create OAuth apps in Google Cloud and your ticketing systems (Zendesk/Jira/HubSpot/Salesforce) with minimal, task-specific scopes (e.g., “send email,” “read metadata,” “create tickets”).
2. Connect those apps to Arcade’s MCP runtime, configuring client IDs/secrets and mapping them to tools like Google.SendEmail or Zendesk.CreateTicket.
3. Have each user authorize the agent via OAuth, then let the agent call only the exposed tools, with Arcade handling token storage, refresh, and audit logging behind the scenes.

---

Should I use a service account or user-specific permissions for my AI assistant?

Short Answer: Use user-specific permissions every time; service accounts are a dead end for multi-user agents.

Expanded Explanation:
Service accounts look tempting: one credential, wired into your agent, and everything “just works” in the demo. Then reality hits. Permissions don’t match what real users see. Security reviews stall because there’s no per-user accountability. And your assistant either sees too much (every mailbox, every ticket) or too little (no access to the user’s actual context).

User-specific permissions flip that model. Each human authorizes the agent with their own identity through OAuth or your IDP. The MCP runtime (Arcade) stores and refreshes tokens, then injects them per call. The agent’s tools execute “as the user,” not as a backend bot. That means:

• It can send email “from” the user’s real Gmail account with correct From/Reply-To.
• It can create tickets only in the projects/queues the user is allowed to touch.
• Every action ties back to a human for audit and incident response.

Comparison Snapshot:

• Option A: Service account bot: One shared identity, broad or mismatched permissions, no per-user traceability, security review nightmare.
• Option B: User-specific OAuth: Each call runs as a real user, scopes are limited by design, and every action is auditable and reversible.
• Best for: Any production AI assistant that needs to send emails or create tickets in systems where compliance, least privilege, or user accountability matters.

---

How do I actually implement this with Arcade’s MCP runtime?

Short Answer: Define agent-optimized tools, wire them to your OAuth-backed systems via Arcade, and let the agent call those tools while Arcade enforces authentication, scopes, and logging.

Expanded Explanation:
Implementation is mainly about drawing clean boundaries. Instead of “give the agent Gmail,” you give it specific tools: “list my recent emails,” “draft and send a reply,” “create a ticket with this summary,” “post status to Slack.” Each tool has a tight schema (what inputs it accepts, what outputs it returns) and runs under Arcade’s runtime, not inside the LLM.

Arcade provides SDK-first patterns so you don’t re-invent authorization flows. You trigger auth with something like client.auth.start(...), wait for the result with wait_for_completion, and once complete, the agent can safely call tools such as Gmail.ListEmails, Google.SendEmail, Slack.PostMessage, Jira.CreateIssue. Tokens live in Arcade, never in prompts. Every tool call is logged with who did what, when, and against which system.

What You Need:

• An MCP runtime (Arcade) configured with your Google Workspace and ticketing providers, plus any other systems your agent should touch (Slack, Linear, GitHub, Salesforce, HubSpot).
• A set of agent-optimized tools that map to real actions (send email, create ticket, update CRM) with clear schemas, permission gates, and just the scopes those actions require.

---

How do I make sure this approach is safe at scale and aligned with business goals?

Short Answer: Combine user-specific authorization, scoped tools, and governance (RBAC, audit logs, SSO/SAML) so your AI assistant can drive real outcomes—faster responses, fewer manual tickets—without breaking your security model.

Expanded Explanation:
The whole point of letting an AI assistant send emails and create tickets is to move from “chat about work” to “actually do the work.” But at scale, that only flies if compliance and security teams can see, govern, and control what’s happening. That’s where an authorization-centric runtime like Arcade matters.

Arcade gives you:

• Scoped OAuth and IDP integration so access lines up with your existing identity and permission model.
• Zero token exposure to LLMs, so you never paste secrets into prompts or embed them in model state.
• Audit logs and RBAC so every tool call is traceable, and only the right agents/tools are allowed in each environment.
• Deployment options (cloud, VPC, on-prem, air-gapped) to match your data residency and risk posture.

The result is an assistant that your users love—“send this to the customer and file a bug”—and your security team can live with, because every action is controlled, scoped, and auditable.

Why It Matters:

• Real business impact: Faster customer responses, fewer dropped tickets, and less manual copy/paste across Gmail, Slack, and your ticketing tools.
• Enterprise alignment: Meets security and compliance expectations with user-specific permissions, clear audit trails, and no uncontrolled token exposure.

---

Quick Recap

You don’t need to give an AI assistant full access to your email and ticketing systems to make it useful. Instead, you:

• Use user-specific OAuth and existing IDP flows so each action runs “as the user.”
• Expose only tightly-scoped tools (send email, create ticket, list messages) via an MCP runtime.
• Let Arcade handle authentication, token refresh, permission gates, and auditing, while the agent focuses on reasoning and deciding which tool to call next.

That’s how you get agents that can actually send emails and create tickets—without turning them into all-powerful, un-auditable service-account bots.

Next Step

Get Started