If you are connecting an AI agent to your CRM, the tempting shortcut is one shared admin key. That path is hard to unwind. This guide is for owners and technical leads who want agents that can do real work without becoming an invisible admin.
Short answer: Give every AI agent its own CRM user account and its own token, with a role that only covers its job. Let the CRM enforce permissions on every MCP tool call. Wake agents with webhooks that acknowledge fast, queue the work, and ignore duplicate events. Treat a slow bot like a slow hire: timeouts and expiring locks, not endless waiting.
Why is a shared admin key the wrong default?
A shared admin key is the wrong default because you cannot tell which agent did what, and one leak opens everything. When several bots share one credential, every write lands under the same identity. Revoking that key stops every bot at once. Scoping becomes a prompt suggestion instead of a hard rule.
Business owners already expect human staff to have named logins and limited roles. Agents that change drafts, open tickets or send messages deserve the same bar. The Model Context Protocol (MCP) authorization spec expects a Bearer token on requests and tells servers to return 403 when the caller lacks scope. That only works if each agent has its own token and the server checks it.
A companion piece, how we keep AI bots under control, covers one key per bot and a human approval gate. This post stays on the CRM side: seats, roles, MCP tools, webhooks and slow bots.
What is an agent seat in a CRM?
An agent seat is a real user account for the bot, with its own token and a role that lists what it may see and change. The account name should match the bot people already talk about (writer, researcher, poster), so every change in the audit trail is readable without decoding IDs.
A practical seat usually includes:
- A dedicated user record marked as an agent, not a person.
- One API token bound to that user, stored in a secrets manager, never in a shared script.
- A role that grants only the tools for that job (for example: create and edit drafts, add notes, lock and unlock its own work).
- Explicit denials for human-only actions such as approve, reject or mark posted.
When a draft writing bot cannot approve its own work because the CRM returns 403, the prompt cannot talk its way around the rule. The MCP tools specification expects the server to validate input, enforce access and rate limit. The agent lists tools and calls them; the CRM still decides.
How should MCP tools sit in front of the CRM?
MCP tools should be the only front door the agent uses to touch the CRM. The agent discovers available actions with tools/list, then calls one tool at a time with structured arguments. The server authenticates the Bearer token, checks the role, validates the payload and either runs the action or refuses it.
That design gives you three wins:
- Clear surface area. You can allowlist the tools each bot sees. A research bot does not need publish tools.
- Consistent audit. Every call is tied to the agent user behind the token.
- Safer evolution. You can add or remove tools without teaching each model a custom HTTP client.
Human-in-the-loop still belongs in the product, not only in the model. If an action should wait for a person, the CRM should refuse the bot and leave the draft in a review column. Our own content pipeline follows that pattern: bots move work to Ready to Review; a person decides. For how we pick first automation projects, see what to automate first with AI.
How do webhooks wake agents without creating chaos?
Webhooks wake agents by notifying them when something they care about changes, but they create chaos if you treat every HTTP call as unique, finished work. Senders retry. Networks duplicate. Timeouts make honest systems send the same event again.
Stripe's webhook guidance is a good default for any CRM that wakes agents: return a 2xx quickly, put the real work on a queue, and design for duplicate events. In practice that means:
- Acknowledge fast. The webhook handler verifies the signature (when you have one), records the event id, and returns success before the heavy job runs.
- Queue the work. The agent or a worker picks up the job asynchronously so a slow model cannot make the sender time out and retry forever.
- Dedupe by event id. Keep a short-lived record of event ids (or another idempotency key) and skip events you already handled.
- Scope what wakes whom. A draft change should not wake every bot in the company. Route by event type and by which agent owns that queue.
Duplicate wakes are normal, not rare. Assume the same "draft ready" event can arrive twice. If your handler is not idempotent, you will get double notes, double locks or double status changes.
What do you do about slow bots?
You treat slow bots as a reliability problem, not a model quality problem. Long tool calls hold locks, block queues and encourage senders to retry. The CRM and the agent both need timeouts.
Practices we follow as open defaults when wiring agents to a CRM:
- Set a hard timeout on every tool call the agent makes.
- Prefer locks that expire, so a crashed bot cannot hold a draft forever.
- Keep webhook handlers thin; never wait for the model inside the request.
- If identity or permissions look wrong at the start of a run, stop and report to a person instead of continuing.
We do not invent a single war story here. The open questions for our own CRM (exact roles, which events fire, how we dedupe today) belong with the team that owns those details. The pattern above is what we recommend and what we use as the design target.
How we approach this at Dasnuve
What worked for us as a process is treating each agent like a new hire with a narrow job description. Named seat, own token, role that matches the job, MCP as the only write path, webhooks that queue and dedupe, and a human gate for anything that reaches a customer or goes live.
If you want help wiring agents into the systems you already run, see our automation services and our work on intelligent applications. The companion post on keeping AI bots under control pairs with this one: identity and approval on one side, CRM seats and webhooks on the other.
FAQ
Can several AI agents share one CRM API key?
They can, but you should not. A shared key erases the audit trail and turns every revoke into an all-hands outage. Give each agent its own user and token so you can shut one off without touching the others.
Does MCP replace CRM permissions?
No. MCP is how the agent discovers and calls tools. The CRM (or whatever server implements those tools) still authenticates the token, checks roles and returns 403 when the agent asks for something outside its seat.
How do I stop the same webhook from running twice?
Record the event id (or another idempotency key) when you accept the webhook, then skip events you already processed. Combine that with a fast 2xx response and async work so retries do not stack up.
Should an agent be allowed to approve its own CRM changes?
No. Keep approve, reject and similar decisions for people. Let the CRM refuse those tools for agent roles so a prompt cannot override the rule.
What if an agent is too slow and holds a lock?
Use expiring locks and tool-call timeouts. If a run stalls, the lock should release on its own so another process (or a person) can continue. Log the stall and fix the queue design; do not raise the timeout forever.
Key takeaways
- Give every AI agent its own CRM seat and token, named so the audit trail is readable.
- Scope by role in the CRM; return 403 when a tool call is out of bounds.
- Put MCP tools in front of the CRM and allowlist what each bot can see.
- Design webhooks for retries: acknowledge fast, queue work, dedupe by event id.
- Assume bots can be slow: timeouts, expiring locks, and stop on identity mismatch.