AI Connector

Scoped tokens, authority levels, the signed API, the MCP server and the record of everything an agent did.

AI Connector is a paid module. It is the door that lets an AI agent operate your site, and the set of rules that keeps that door narrow.

Warning Site content is data, not instruction. Topic titles, posts, messages, member names and custom fields were written by people, and some of those people will write orders addressed to your agent. The connector marks member content as untrusted for exactly this reason. An agent that treats it as instruction can be steered by anyone who can post on your site.

What it is, and what it is not#

It is a token system, a signed REST API and an MCP server. A token acts as a service member of one member group, so it never does more than that group can, and the scope you put on top can only take permissions away.

It does not include an AI model. You connect the agent you already use, with the provider and the account you already pay for. Bondry stores no model, no provider key and no usage bill.

It reaches the core and every installed module, because it speaks through the permissions each module already declares. A module installed tomorrow is within reach the day you install it, with no update to the connector.

Install and license#

Download the package from your account, then upload it under Admin panel > Modules. Activate the license with the serial number of your AI Connector purchase, on the same production domain as your core license.

Nothing is open until you create a token. The module ships with no token and grants no access by default.

Create a token#

Go to AI Connector > Tokens and choose New token. A token carries:

The secret is shown once. Everything before the dot is the key id; everything after it is the signing secret. The site keeps it encrypted and never displays it again, so store it where you store passwords.

Note Leave Read only on for your first token. A read only token is enough to let an agent answer questions about your community, and it cannot damage anything while you learn what that agent does with it.

The three authority levels#

The level is derived from the group you picked and from one box. It is written into every line of the activity timeline, so a token that was downgraded later does not rewrite its own history.

Member. A normal group. The token acts exactly as a member of that group acts, and the administrative surface stays closed. This is the level for a token that answers questions, posts replies or keeps a category tidy.

Administrator. A group with administration rights, with the box off. The token creates and configures whatever an administrator configures in the panel, in the core and in every installed module: groups, categories, forums, pages, courses, plans, badges, menus, languages and themes. Destructive actions stay closed unless you grant them one by one, and they still answer with a confirmation step.

Absolute. A group with administration rights, with Absolute access on. The token does everything, destructive included, with no confirmation step per action. Granting it costs, on the screen and on the server:

1. a written acknowledgement that the token can delete content and members, uninstall modules and change payments, permissions and settings;
2. the password of the administrator creating the token;
3. the two-factor code, when that account has two-factor authentication on;
4. an expiry date thirty days away at most.

Removing absolute access costs nothing: lowering power is never harder than raising it. The master switch, the rate limits, the IP list, the audit log and read only still apply to an absolute token.

Connect over the signed REST API#

The base URL is under AI Connector > Documentation. Every call carries four headers:

Ask the site before acting. GET /ai/v1/capabilities says which modules are installed, what this token may run, whether it is read only and what the ceilings are. GET /ai/v1/schema/{resource} describes the fields and the actions of one resource. POST /ai/v1/actions runs one action.

Connect over MCP#

The same door with another handle: the same tokens, the same ceilings, the same trail and the same confirmation step. AI Connector > Documentation shows the MCP URL of this installation, and the token travels as a bearer:

{
  "mcpServers": {
    "bondry": {
      "type": "http",
      "url": "https://your-community.com/ai/mcp/<installation>",
      "headers": {
        "Authorization": "Bearer bai_xxxxxxxxxxxx.<secret>"
      }
    }
  }
}

Claude Code adds it in one line:

claude mcp add --transport http bondry \
  https://your-community.com/ai/mcp/<installation> \
  --header "Authorization: Bearer bai_xxxxxxxxxxxx.<secret>"

Four tools, and none of them is a factory list: bondry_capabilities, bondry_schema, bondry_read and bondry_act.

Warning An MCP client does not sign the request body, so the secret itself travels in the header. The endpoint refuses plain HTTP outside local development. Serve your site over HTTPS before you hand a token to an agent.

Dry run#

Any action can be sent as a dry run. The site answers what it would do, in detail, and changes nothing. The answer also says whether the real call will ask for confirmation. Use it the first time an agent touches a kind of resource it has never touched before.

Two-step confirmation#

A destructive action answers 409 with a confirmation token that is good once, for five minutes, for that exact action on that exact target. The second call carries the token and executes. This holds for an administrator token even in "everything the group allows" mode: destructive never arrives by inheritance.

An absolute token skips the second step. That is the whole difference, and it is why granting absolute access costs what it costs.

The activity timeline#

AI Connector > Activity lists every call an agent made, including the ones refused at the gate. Each line carries the token, the authority it had at that moment, the surface (REST API or MCP server), the action, the target and, when something changed, the before and the after.

Filter by token, by surface, by type and by result. The same actions also land in the Administrator Log of the core, so an audit reads one story, not two.

The master switch#

AI Connector > Tokens has one switch that turns the connector off. It revokes every token at once and refuses every call until you turn it back on. Nothing else on your site changes.

Turning it back on does not restore the tokens: they stay revoked, and you restore the ones you still want, one by one. That is deliberate. A switch you pulled in a hurry should not undo itself in a hurry.