If you are thinking about giving AI bots real access to your business software, this is for you. We run four bots on our own content work, and the most useful lesson so far had nothing to do with which AI model we picked.
Short answer: Give every bot its own identity and key, check that identity at the start of every run, give each bot only the tools its job needs, keep keys out of scripts, and make sure a person approves anything before it reaches a customer. In our experience these guardrails matter more than the model you choose.
What did we build?
We built a small content pipeline with four bots and one human approval step. One bot researches and writes briefs. One bot turns those briefs into finished posts, comments and blog articles. Two bots publish, one for our business accounts and one for personal accounts.
Everything lives in our CRM. Every piece of content is one draft there, from idea to live link, and nothing is tracked anywhere else. That matters more than it sounds: when something goes wrong, there is one place to look.
Nothing goes out without a person approving it. The CRM refuses an approval if it comes from a bot, so a bot can write a draft and move it to review, but only a human can say yes.
How do AI bots connect to business software?
AI bots connect to business software through tools: small, named actions like "list drafts" or "add a note" that the model can ask to run. The Model Context Protocol (MCP) is an open standard for exposing those tools, so one connector to your CRM can serve different AI models.
The major AI providers all work this way. xAI's function calling guide describes the loop: you define tools with a name, a description and a schema, the model asks for a call, your code runs it, and the model continues with the result. Anthropic's MCP connector lets a model call tools on a remote MCP server directly.
Limit each bot to the tools its job needs. Anthropic's connector lets you allowlist specific tools or switch off the ones you do not want, and its docs recommend turning off write or destructive tools when you want a human confirmation step before changes. Our writing bot, for example, has no reason to publish anything, so publishing is not part of its job.
What went wrong with a shared key?
Early on, one bot ran with another bot's key. A draft landed in the CRM under the wrong bot's name, and a person had to delete it.
It showed us the real risk. When bots share a key, your records stop telling you who did what, and a log you cannot trust is worse than no log at all.
The fix was simple:
- One key per bot. Each bot has its own user in the CRM and its own token, so every action shows under its own name.
- Check identity on every run. Before a bot changes anything, it confirms the CRM sees it as the right bot. In our setup, a bot locks the draft it is about to edit, and the lock shows which bot and which key holds it.
- Stop on a mismatch. If the identity is wrong, the bot changes nothing and reports back to a person.
The MCP spec points in the same direction. It requires the access token on every request, and it says servers must only accept tokens issued for them and must not pass a token through to other services.
Where should the keys live?
Keys belong in a secrets manager, not in scripts or chat logs. We recommend AWS Secrets Manager for this. It removes the need for hard-coded credentials in your code, lets your bots fetch a key at runtime, and can rotate secrets on a schedule so long-lived keys become short-lived ones.
Two habits matter whatever tool you use:
- Rotate keys, so an old key that leaks stops working on its own. The MCP spec also recommends short-lived access tokens to limit the damage from a leaked one.
- Revoke anything exposed right away. OpenAI's safety guidance says that if a key may have been exposed or misused, you should revoke it promptly and replace it.
Why keep a human approval gate?
A human gate catches what the bots miss, and it is the cheapest safeguard you can add. OpenAI's safety guidance recommends having a person review outputs before they are used wherever possible, and making sure that person can see the source material behind them.
In our pipeline, a bot can research, write and move a draft to review. A person reads it and decides: approve, ask for changes or reject. When a bot that posts decides something should not go out, it adds a "DO NOT POST" note with the reason instead of quietly changing the draft, and the other bots respect that note.
This also keeps the bots honest about their limits. When a draft needs a fact we do not have, the writing bot asks for it in a note instead of filling the gap.
How we approach this at Dasnuve
What worked for us is treating bots like new staff members with very narrow jobs. Each one gets its own login, a short list of things it is allowed to do, and a manager who signs off on its work. The AI model matters, but in our experience the guardrails around it decide whether you can trust it with real work.
If you are planning your first project, start with our guide on what to automate first with AI. If you want help connecting AI to the systems you already run, see our automation services and our work on intelligent applications.
FAQ
Can several AI bots share one API key?
They can, but we would not do it again. With a shared key, your records cannot tell you which bot did what, and one mistake or leak affects all of them. One key per bot keeps every action traceable and lets you revoke one bot without stopping the others.
What is MCP in plain terms?
MCP (Model Context Protocol) is an open standard for letting AI models use tools in other software, such as a CRM. Instead of building a separate connection for each AI provider, you expose your tools once and different models can call them.
Should AI bots be allowed to approve their own work?
No. In our setup the CRM refuses approvals from bots, so only a person can approve content before it goes out. Bots can draft, check and flag problems, but the final yes stays human.
What should I do if a bot's key leaks?
Revoke it right away and issue a new one, then check what was done with the old key. Storing keys in a secrets manager and rotating them on a schedule makes this much easier.
Key takeaways
- Give every bot its own identity and key, so every action shows who did it.
- Check identity at the start of every run, and stop if it is wrong.
- Give each bot only the tools its job needs, and turn off write tools where a person should confirm.
- Keep keys in a secrets manager, rotate them, and revoke anything exposed.
- Keep approval human. Bots can draft and flag, but a person decides what goes out.