{"slug": "bring-your-own-ai-the-three-ways-to-connect-an-assistant-to-a-birkly-site", "title": "Bring your own AI: the three ways to connect an assistant to a Birkly site", "summary": "Birkly, an open AI-native content management platform, connects AI assistants to sites through three methods: a personal connector that inherits the logged-in user's role, a service agent with a fixed admin-assigned role, and a built-in assistant that uses a user-supplied API key from providers like OpenAI, Anthropic, Google, OpenRouter, or a local Ollama setup. All three routes share the same tool registry and permission checks, with a site-wide switch and hard denylist that admins control above them.", "body_md": "**Quick bit of context first, since this is a small project and there's a decent chance you're reading this without knowing what Birkly even is. Birkly is an open, AI-native content management platform that enables everyone to build, manage and operate digital experiences without vendor lock-in, unnecessary software complexity or dependency-heavy technology stacks. You can read more about it on [https://birkly.io](https://birkly.io)**\n\nHere's something I like about how Birkly handles AI: it treats an AI connection the same way it treats a person. You give it a role, and that role decides what it can and can't do. There's no looser, separate rulebook for \"what an AI is allowed to touch.\" It goes through the exact same role and permission system a human user does.\n\nThat one choice shapes everything else. There are three different ways to connect an AI to a site: a personal connector, a service agent, and a built in assistant. Each one answers the same underlying question a bit differently, namely which role the AI is actually operating under. But no matter which of the three you use, admins still keep the final say. A site wide switch and a hard denylist sit above all three, all the time, and neither can be talked around.\n\nWhich role an AI connection ends up with, and where that role comes from, depends on which method you pick.\n\n**1. Personal connector: the AI acts as whoever's logged in**\n\nThis is the default option. Under Settings → AI there's a single MCP URL for the whole site. You paste that into whatever AI client you're using, Claude, ChatGPT, Cursor, anything that speaks MCP, sign in with your Birkly account, and approve a consent screen that spells out exactly which role you're handing over.\n\nFrom then on the AI simply has that account's permissions. If you're an Editor, it acts as an Editor. If you're an Admin, it acts as an Admin, full access to content, media, settings, plugins, the whole site. There's no separate \"AI role\" to think about, because there's no separate identity at all. It's just you, working through a different interface. One set of permissions to keep track of instead of two.\n\n**2. Service agent: a fixed role, not tied to a person**\n\nSometimes \"acts as whoever's logged in\" isn't what you want. Maybe it's an automation, an integration, or a teammate who really doesn't need full account access just so their AI client can help with content. That's what a service agent is for. An admin creates it, gives it a fixed role that never changes (always Editor, say, no matter who's actually behind it), decides which people can even see it, and hands out its own dedicated MCP URL.\n\nUnder the hood it's the same tool registry and the same permission checks as the personal connector. The only real difference is where the role comes from. A personal connector's role follows the account. A service agent's role is pinned in place by an admin and stays put.\n\n**3. Built in assistant: bring your own model**\n\nThe third option skips MCP entirely and lives right inside the admin panel as a chat window. You connect it with an API key from whatever provider you already use, OpenAI, Anthropic, Google, OpenRouter, a local Ollama setup, even a custom endpoint. You set its role the same way you would for a connector, and there's an optional \"Require approval\" setting that holds every write it proposes in an Approvals tab until a human actually clicks confirm.\n\nThis one's for people who just want a chat box in their CMS, backed by whichever model they already have access to, without setting up a separate AI app. Birkly genuinely doesn't care which company made the model. It only cares that it can call the same tool registry the other two methods use.\n\nWhat ties all three together is that they're not really three different feature sets. They're three different doors into the same room. Whether an AI is working through a person's own login, acting as a fixed role service bot, or chatting away in the admin panel on someone's own API key, it's reaching the exact same catalog of actions: content, media, the site's files, plugin admin tools, settings, all of it. The thing that changes between them is whose identity it's borrowing, and how a write actually gets confirmed. OAuth consent up front for the two MCP methods, an optional approval queue for the built in one.\n\n\"Bring your own AI\" usually just means \"point any model at our API.\" Here it stretches a bit further than that. You bring your own client, your own model provider, and your own identity story, personal, service, or built in, and the underlying permission model never has to bend to accommodate any of it.\n\nBorrowing a role, whether it's a person's own or a service agent's fixed one, is the identity layer. But it's not the only thing standing between an AI connection and something going wrong. Two site wide settings sit above all three methods, and they apply no matter which role is in play.\n\nThe first is the AI & MCP tools switch. It has three states. Normal, where tools simply follow role permissions and this is the default. Read only chat, where the built in assistant still works but no MCP tools get exposed or executed at all. And Disabled, where all tool execution is blocked outright and MCP's tools list comes back empty. This overrides whatever a connection's own approval setting says. If the site is set to Read only or Disabled, nothing gets more access than that, no matter how privileged its role is.\n\nThe second is the Plugin Security Denylist. Specific collections can be marked as protected, and specific plugin admin spaces can be denied entirely, which blocks that plugin's sidebar injection and any space scoped hooks it would otherwise get. Anything on this list is simply off limits to every plugin, regardless of what capabilities it's been granted elsewhere. The settings page describes it plainly as a hard barrier that can't be overridden.\n\nSo the role based model answers one question: whose permissions does this AI have. These two settings answer a different one entirely: what's the absolute ceiling, no matter whose permissions those are. Same doors as before, just with a breaker switch sitting above all of them that doesn't care which one an AI happened to walk through.", "url": "https://wpnews.pro/news/bring-your-own-ai-the-three-ways-to-connect-an-assistant-to-a-birkly-site", "canonical_source": "https://dev.to/rakete/bring-your-own-ai-the-three-ways-to-connect-an-assistant-to-a-birkly-site-41h2", "published_at": "2026-09-15 09:28:00+00:00", "updated_at": "2026-09-15 09:39:20.484446+00:00", "lang": "en", "topics": ["ai-agents", "ai-products", "ai-tools", "developer-tools"], "entities": ["Birkly", "OpenAI", "Anthropic", "Google", "OpenRouter", "Ollama", "Claude", "ChatGPT"], "alternates": {"html": "https://wpnews.pro/news/bring-your-own-ai-the-three-ways-to-connect-an-assistant-to-a-birkly-site", "markdown": "https://wpnews.pro/news/bring-your-own-ai-the-three-ways-to-connect-an-assistant-to-a-birkly-site.md", "text": "https://wpnews.pro/news/bring-your-own-ai-the-three-ways-to-connect-an-assistant-to-a-birkly-site.txt", "jsonld": "https://wpnews.pro/news/bring-your-own-ai-the-three-ways-to-connect-an-assistant-to-a-birkly-site.jsonld"}}