Everyone loves OpenClaw until someone asks the obvious next question: can it talk to our SharePoint? And Outlook? And the rest of Office 365? The short answer is yes. The longer answer is: yes, but you have to wire it properly, and security is the whole game.
This video is Ariel’s field report from a real client setup. He explains the architecture from a high level, then shows the thing actually working: a Telegram message to an agent becomes a new sheet inside a private SharePoint Excel file. No human opens SharePoint. The agent does it.
The architecture in plain English
The setup sits on a VPS โ usually Ubuntu โ running OpenClaw. Each user gets their own agent, and behind the scenes there are additional agents for heavier tasks like coding the integration or managing the server. The agents do not run wild; permissions are deliberately limited, and riskier agents can be dropped into Docker sandboxes.
The bridge into Microsoft land is Microsoft Graph, the umbrella API that wraps SharePoint, Outlook, Teams, OneDrive and the rest of Office 365. Graph is public, documented and stable. The trick is authentication.
That part is handled through Microsoft Entra ID (the artist formerly known as Azure Active Directory). Entra owns every user, every permission and every door into the Microsoft tenant. There are two common ways to open that door:
- User-delegated access โ the agent logs in as the user and can only do what that user is allowed to do. This is usually the safer, more auditable choice.
- App-level access โ a separate Entra application gets its own permissions. You verify that the user belongs to your organization, then the agent acts within the app’s scope. Some setups even create a dedicated “bot user” inside Microsoft 365 so the agent’s footprint is smaller than a real employee’s.
Ariel’s recommendation is to keep it boring: define permissions in Entra ahead of time, let the agent inherit them, and never give it more keys than it needs.
What the demo actually shows
The client’s daily interface is Telegram. Ariel chose Telegram deliberately: it is calm about bots, it shows intermediate progress (unlike WhatsApp, where the user just waits for a final answer), and it works well for organizations that do not want to fight Meta’s business-API mood swings.
In the demo he asks the agent to add a new sheet called “Dragon Slayers” to an existing Excel file stored in his private SharePoint folder. The agent searches, reads the file, adds the sheet and confirms. The admin panel shows the chain of tool calls in real time. The user on Telegram sees what the agent is thinking and doing, not just the final “done.”
Behind the scenes the agent is calling a small Python service that speaks Graph API. That service is itself restricted: it knows about a shared read-only folder and per-user private read-write folders. The agent cannot wander outside those boundaries. This is the pattern โ wrap the big API in a smaller, dumber API that only knows your rules.
Why this is harder than it looks
The demo looks smooth because the hard parts were solved before the camera rolled:
- Identity plumbing. Entra apps, consent screens, scopes, secret rotation. None of it is AI; all of it breaks the project if done wrong.
- Permission design. Every folder and every action has to be pre-mapped. “Just give the agent access” is how you end up in a security review nobody enjoys.
- Sandboxing trade-offs. Ariel notes that Docker sandboxes are great for isolation, but they make it harder for agents to use tools like Open Interpreter. The compromise is to expose a narrow internal API into the sandbox so the agent can request work without holding the keys.
- Chat layer choice. WhatsApp is popular, but for enterprise bots Telegram is the pragmatic default. The right channel is the one that does not fight you.
๐ฅ Roast Corner
Let us be honest about what most “enterprise AI integrations” look like: a founder demoing a ChatGPT wrapper that can read three PDFs, pitching it as “SharePoint connected,” while the actual SharePoint connection is a TODO in a Jira board somewhere.
The real integration is not the LLM. The LLM is the easy part. The real integration is the permission model, the folder structure, the audit trail and the failure modes. If your agent can create files in SharePoint but you cannot explain exactly which folders, which users and under which conditions, you do not have an AI product โ you have a very polite data exfiltration tool.
Ariel’s version is better because he front-loads the boring work: Entra scoping, per-user folders, a restricted Graph API wrapper and admin visibility. That is the difference between a demo and a deployment.
Also, the choice of Telegram over WhatsApp is a small detail that reveals a lot. WhatsApp is sexy for consumer bots. For an organization that needs reliability, audit logs and no surprises, WhatsApp is a liability dressed as a feature.
๐ค AI for Humans
If you do not run an IT department, here is the translation:
Your company probably lives inside Microsoft 365: files in SharePoint, email in Outlook, calendars in Teams. Right now, when someone wants a file created, an email sent or a report updated, a human has to open the right app and do it.
An AI agent wired through Microsoft Graph can do those same tasks from a chat message:
- Create or update files in SharePoint.
- Read or send emails through Outlook.
- Work within the user’s actual permissions, so it can never access more than the user could.
The user experience is simple: type a request in Telegram, get a confirmation. The behind-the-scenes experience is not simple, and that is fine โ that is what the setup phase is for. Once it is wired, the agent becomes a quiet coworker that handles the small Microsoft chores so humans can handle the decisions that matter.
Published 2026-08-23 from the YouTube demo by Ariel Rubinstein.
๐ฌ Comments