Goldnat AI Connect for XenForo 1.2.52

[chanina]

canina updated Goldnat AI Connect for XenForo with a new update entry:

Demo: one prompt, three platforms (Shopify → WordPress → XenForo)

Put together a short demo showing what a cross-platform request actually looks like end to end.

The prompt:
"Check my Shopify sales this week, write a blog post about the top-selling
product, and open a discussion about it in my customer forum 'Community'"

What happens:
1. Agent pulls this week's Shopify sales and finds the top seller
2. Writes and publishes a WordPress blog post about it
3. Finds the right forum on the connected XenForo board and opens a
discussion thread — through...

Read the rest of this update entry...

 

[IMCD]

Suggest something like conversation:read access and a listConversations in order to pull recent conversations and interact with those. Currently, no way to pull a list, only interact with known conversation IDs.

Also, any eta on the moderation version? Would be a huge help.

Overall, excellent add-on. Anybody sleeping on this is missing out on practically endless possibilities.

 

[chanina]

canina updated Goldnat AI Connect for XenForo with a new update entry:

v1.2.52 — SERVIO-aligned OAuth, admin scope fixes, security hardening

This release aligns OAuth scope handling with the SERVIO principle (the token is an identity credential; per-request permission is authoritative) and adds several security and reliability fixes accumulated since 1.2.44.

Highlights

• SERVIO-aligned permissions — admin/write operations are now authorized per-request by the acting user's actual role, not by a scope tag baked into the token. This fixes cases where legitimate admins were blocked from operations they could perform manually in...

Read the rest of this update entry...

 

[CrazyChef]

I've been looking pretty seriously at AI Connect Pro for a XenForo community I'm building, and I have a few questions before I get to the installation/testing stage.

I've read through this thread, the Pro thread, the resource descriptions, and the documentation, so I tried not to repeat questions that have already been answered.

A few things appear to have changed pretty quickly as the add-on has developed, so I'd appreciate some clarification on the current state.

1. What is the authoritative current Pro tool list?

The XenForo Pro resource currently refers to 67 Pro tools, while the Goldnat site appears to show a larger current tool set, including some fairly powerful administrative actions such as user and node management.

Are all of those tools included in the current Pro package, or is the website showing tools from another/additional administrative package as well?

Basically, when installing the current versions today, what is the exact authoritative tool set?

2. When new tools are added in an update, do they fail closed by default?

This is probably one of my most important questions.

Suppose an AI account already has access to a Pro tool group/package, and a future update introduces a new tool—especially a potentially destructive or administrative one.

Does that new tool automatically become available because the broader permission was already granted, or must the administrator explicitly grant permission to the newly added tool?

For security purposes, I would strongly prefer newly introduced capabilities to default to denied until explicitly enabled.

3. Is there a complete audit log of AI actions?

I'm aware of the token/connection information and revocation capabilities.

Is there also an action-level log showing things such as:

• which XenForo member/token performed the action;
• date/time;
• tool called;
• affected thread/post/conversation/member/node ID;
• success or failure;
• and ideally enough information to determine exactly what was changed?

For an AI account that may eventually have write permissions, being able to determine exactly what it did and when would be extremely useful.

4. Can consequential actions require server-side approval?

Does the XenForo add-on itself have any ability to require human approval for particularly sensitive actions before they execute?

For example:

• deleting content;
• modifying another member;
• moderation actions;
• bans/warnings;
• creating/deleting nodes;
• account administration.

I'm specifically asking about enforcement on the XenForo/AI Connect side rather than an approval mechanism implemented only by the AI client using it.

5. How are private conversations protected?

For the conversation tools, can an authenticated AI account access only private conversations that the corresponding XenForo account is actually entitled to see?

Could an administrator/moderator-connected AI account ever retrieve another member's private conversations solely because that account has elevated XenForo privileges?

I'd like to understand exactly where that boundary sits.

6. Are attachment permissions rechecked when an attachment is downloaded?

If an AI uses an attachment-download tool, does AI Connect verify that the authenticated XenForo account currently has permission to access the parent content?

For example, an attachment belonging to:

• a private conversation;
• a restricted node;
• member-only content;
• deleted/moderated content.

I want to make sure possession of an attachment ID alone could never bypass normal XenForo access controls.

7. Can query-string token authentication be disabled completely?

I noticed support was added for authentication through something like ?token=... for clients that cannot provide an Authorization header.

Can an administrator disable that method and require Bearer/OAuth authentication only?

My concern is that tokens placed in URLs can potentially appear in web-server logs, proxy logs, browser history, analytics, etc.

8. How are access and refresh tokens stored?

Are access/refresh tokens stored hashed or otherwise protected in the XenForo database?

Also, are raw token values ever written to XenForo logs, PHP error logs, web-server logs, or AI Connect diagnostic output?

9. During normal direct AI Connect usage, does any forum content pass through Goldnat infrastructure?

If an MCP/AI client connects directly to my XenForo installation, does the forum content travel only between my XenForo server and that client?

What information, if any, is transmitted to Goldnat servers for licensing, telemetry, usage statistics, diagnostics, etc.?

I'm particularly interested in whether post content, private conversations, member information, prompts, or tool results ever pass through Goldnat infrastructure.

10. How does Pro licensing behave during a Goldnat/licensing-server outage?

Is license validation performed on every request, periodically, or cached locally?

If the Goldnat licensing service becomes temporarily unavailable, what happens?

Ideally I'd want an external licensing outage to affect the Pro integration only and never interfere with normal XenForo operation.

11. How does a license work with a separate staging installation?

My normal development workflow is staging first, followed by promotion to the real site after testing.

Does one Pro license allow a private staging installation and the production installation for the same community, or would the license need to be moved between domains?

Would a separate staging license be required?

12. How granular is rate limiting?

Can limits be configured separately by:

• member;
• token/client;
• user group;
• tool;
• tool category;
• read versus write operations?

For example, I'd potentially want fairly generous search/read limits but extremely conservative posting or messaging limits.

13. Is there any idempotency/duplicate-write protection?

This one is specifically about AI clients retrying requests.

If replyToThread, createThread, sendConversation, etc. succeeds on XenForo but the client never receives the response because of a timeout, it may retry the same operation.

Is there an idempotency key or duplicate-write mechanism available to prevent duplicate posts/messages in that situation?

14. What happens if Pro fails or is disabled?

If Pro is disabled, its license fails, an exception occurs, or the add-on is uninstalled, does normal XenForo simply continue unaffected?

Does the base AI Connect functionality continue functioning independently?

I'm looking for clean failure isolation where the AI integration can break without affecting normal community use.

15. Are permission-aware events/webhooks planned?

I understand from the discussion that AI Connect itself isn't intended to be an autonomous background watcher, which makes sense.

For certain uses, though, it could be useful to receive narrowly scoped events such as:

• this connected account was mentioned;
• someone replied to this account;
• a watched thread changed;
• this account received a notification.

Is a permission-aware webhook/event mechanism planned, or is periodic polling of notifications/watched content the expected approach?

One last version-specific question:

There was a TokenRegistry cleanup issue discussed previously involving affectedRows()/rowsAffected(), and I saw that a fix was planned. Can you confirm that fix is included in the versions currently being distributed?

Thanks. I'm impressed with where this project is heading. I'm mainly trying to understand the security and permission boundaries thoroughly before I start giving an AI account any write authority.

 

[chanina]

I've been looking pretty seriously at AI Connect Pro for a XenForo community I'm building, and I have a few questions before I get to the installation/testing stage.

I've read through this thread, the Pro thread, the resource descriptions, and the documentation, so I tried not to repeat questions that have already been answered.

A few things appear to have changed pretty quickly as the add-on has developed, so I'd appreciate some clarification on the current state.

1. What is the authoritative current Pro tool list?

The XenForo Pro resource currently refers to 67 Pro tools, while the Goldnat site appears to show a larger current tool set, including some fairly powerful administrative actions such as user and node management.

Are all of those tools included in the current Pro package, or is the website showing tools from another/additional administrative package as well?

Basically, when installing the current versions today, what is the exact authoritative tool set?

2. When new tools are added in an update, do they fail closed by default?

This is probably one of my most important questions.

Suppose an AI account already has access to a Pro tool group/package, and a future update introduces a new tool—especially a potentially destructive or administrative one.

Does that new tool automatically become available because the broader permission was already granted, or must the administrator explicitly grant permission to the newly added tool?

For security purposes, I would strongly prefer newly introduced capabilities to default to denied until explicitly enabled.

3. Is there a complete audit log of AI actions?

I'm aware of the token/connection information and revocation capabilities.

Is there also an action-level log showing things such as:

• which XenForo member/token performed the action;
• date/time;
• tool called;
• affected thread/post/conversation/member/node ID;
• success or failure;
• and ideally enough information to determine exactly what was changed?

For an AI account that may eventually have write permissions, being able to determine exactly what it did and when would be extremely useful.

4. Can consequential actions require server-side approval?

Does the XenForo add-on itself have any ability to require human approval for particularly sensitive actions before they execute?

For example:

• deleting content;
• modifying another member;
• moderation actions;
• bans/warnings;
• creating/deleting nodes;
• account administration.

I'm specifically asking about enforcement on the XenForo/AI Connect side rather than an approval mechanism implemented only by the AI client using it.

5. How are private conversations protected?

For the conversation tools, can an authenticated AI account access only private conversations that the corresponding XenForo account is actually entitled to see?

Could an administrator/moderator-connected AI account ever retrieve another member's private conversations solely because that account has elevated XenForo privileges?

I'd like to understand exactly where that boundary sits.

6. Are attachment permissions rechecked when an attachment is downloaded?

If an AI uses an attachment-download tool, does AI Connect verify that the authenticated XenForo account currently has permission to access the parent content?

For example, an attachment belonging to:

• a private conversation;
• a restricted node;
• member-only content;
• deleted/moderated content.

I want to make sure possession of an attachment ID alone could never bypass normal XenForo access controls.

7. Can query-string token authentication be disabled completely?

I noticed support was added for authentication through something like ?token=... for clients that cannot provide an Authorization header.

Can an administrator disable that method and require Bearer/OAuth authentication only?

My concern is that tokens placed in URLs can potentially appear in web-server logs, proxy logs, browser history, analytics, etc.

8. How are access and refresh tokens stored?

Are access/refresh tokens stored hashed or otherwise protected in the XenForo database?

Also, are raw token values ever written to XenForo logs, PHP error logs, web-server logs, or AI Connect diagnostic output?

9. During normal direct AI Connect usage, does any forum content pass through Goldnat infrastructure?

If an MCP/AI client connects directly to my XenForo installation, does the forum content travel only between my XenForo server and that client?

What information, if any, is transmitted to Goldnat servers for licensing, telemetry, usage statistics, diagnostics, etc.?

I'm particularly interested in whether post content, private conversations, member information, prompts, or tool results ever pass through Goldnat infrastructure.

10. How does Pro licensing behave during a Goldnat/licensing-server outage?

Is license validation performed on every request, periodically, or cached locally?

If the Goldnat licensing service becomes temporarily unavailable, what happens?

Ideally I'd want an external licensing outage to affect the Pro integration only and never interfere with normal XenForo operation.

11. How does a license work with a separate staging installation?

My normal development workflow is staging first, followed by promotion to the real site after testing.

Does one Pro license allow a private staging installation and the production installation for the same community, or would the license need to be moved between domains?

Would a separate staging license be required?

12. How granular is rate limiting?

Can limits be configured separately by:

• member;
• token/client;
• user group;
• tool;
• tool category;
• read versus write operations?

For example, I'd potentially want fairly generous search/read limits but extremely conservative posting or messaging limits.

13. Is there any idempotency/duplicate-write protection?

This one is specifically about AI clients retrying requests.

If replyToThread, createThread, sendConversation, etc. succeeds on XenForo but the client never receives the response because of a timeout, it may retry the same operation.

Is there an idempotency key or duplicate-write mechanism available to prevent duplicate posts/messages in that situation?

14. What happens if Pro fails or is disabled?

If Pro is disabled, its license fails, an exception occurs, or the add-on is uninstalled, does normal XenForo simply continue unaffected?

Does the base AI Connect functionality continue functioning independently?

I'm looking for clean failure isolation where the AI integration can break without affecting normal community use.

15. Are permission-aware events/webhooks planned?

I understand from the discussion that AI Connect itself isn't intended to be an autonomous background watcher, which makes sense.

For certain uses, though, it could be useful to receive narrowly scoped events such as:

• this connected account was mentioned;
• someone replied to this account;
• a watched thread changed;
• this account received a notification.

Is a permission-aware webhook/event mechanism planned, or is periodic polling of notifications/watched content the expected approach?

One last version-specific question:

There was a TokenRegistry cleanup issue discussed previously involving affectedRows()/rowsAffected(), and I saw that a fix was planned. Can you confirm that fix is included in the versions currently being distributed?

Thanks. I'm impressed with where this project is heading. I'm mainly trying to understand the security and permission boundaries thoroughly before I start giving an AI account any write authority.

Thank you for the questions—this is certainly constructive criticism!
I will begin with a general introduction, followed by detailed answers.


Overarching principle — every tool is bounded by the connected member's own XenForo permissions.
An AI connection acts as a specific XenForo member and can never do anything that member couldn't do manually in the UI. Node view permissions, posting permissions, conversation participation, moderation rights — all of XenForo's normal permission system applies unchanged. The AI-Connect permissions are an additional gate on top of that, never a bypass of it. The real ceiling for any connected account is "what could this member do by hand?".

1. Authoritative tool set
Three separate products: AI Connect (free core) = read/search + identity; AI Connect Pro = the main Pro set; AI Connect Admin = a separate product (own licence) that holds the powerful user/node/administration actions you saw. The resource's 67 figure is out of date — we're reconciling the resource + site so the counts match exactly what installs today, and I'll follow up with the confirmed per-product list.

2. Do newly-added tools fail closed? Fixed and tested.
A newly-introduced tool now defaults to DENIED — the permission is registered so you can enable it, but it is never granted automatically under an already-enabled package. We verified this end-to-end: a freshly-added tool resolves to "denied" for a normal member until an admin explicitly grants it. Existing grants you've already made are untouched. Enabling a bundle is one toggle; enabling a brand-new tool inside it is a deliberate second action. Will be released in the next plugin update.

3. Action-level audit log
A tracking tool with limited capabilities regarding the token (which token/member, timestamp, source IP and user agent, and issue/revocation lifecycle) exists—as detailed in Section 7 below; while an action tracking page (logging the tool called, affected content ID, success/failure status, and changes made) is not yet available, this important feature is already included in our development roadmap.

4. Server-side human approval for consequential actions
As it stands today, the add-on does not provide a "draft / pending approval" gate on the tools it exposes — a permitted write tool executes immediately. That said, XenForo has its own built-in moderation/approval queue, and it may partially fit your needs — it would be worth you checking whether routing certain content through XF's native approval workflow covers your case. Wiring specific AI write actions into that queue is not something the add-on does automatically today; it would be a code change on our side (not just an admin setting), and XenForo's queue does cover several content types (threads, posts, profile posts/comments, and some user/username changes), so it could apply to more than one tool if we pursue it. We'll consider it for the roadmap.

5. Private conversation protection — fully enforced.
Conversation tools load only through the authenticated account's own participation record, not by raw conversation ID. An admin/moderator-connected account cannot retrieve another member's private conversations via elevated privilege — it gets "not found/not accessible". This is explicit in the code, including a guard preventing a moderator inviting themselves into a conversation they aren't part of.

6. Attachment permission recheck — fully enforced.
Every attachment tool (download/read/delete) re-verifies permission on the parent content at call time. An attachment ID alone never bypasses access control — private-conversation, restricted-node, member-only and deleted-content attachments are all re-checked.

7. Authentication methods / disabling query-string tokens
Two authentication methods are accepted today: (a) the standard Authorization: Bearer <token> header, and (b) a ?token=<token> query-string fallback for clients that can't send a custom header. There is no admin switch to disable method (b) at present. Separately, any token can already be revoked at any time from the "My AI Tokens" page (individually or all at once). An option to refuse the query-string method and require the Bearer header only is a legitimate request, and we'll consider adding it to the roadmap.

8. Token storage
The audit registry stores only a 16-char prefix, never the full token, and raw tokens are never written to any log. Being fully transparent: the live OAuth token table currently stores the token value itself (needed for validation lookups), protected by normal DB access controls. Hashing tokens at rest — so a database compromise alone couldn't reuse them — is a worthwhile hardening and it's going on our roadmap.

9. Data flow to Goldnat
The most convenient and tailored way to use artificial intelligence is through goldnat.ai — and in that case Goldnat's privacy policy governs that usage. If instead you connect an MCP/AI client directly to your XenForo install, forum content travels only between your server and the client; the only thing sent to Goldnat is a licence check (licence key + domain + version), roughly once a day — no post content, private conversations, member info, prompts, or tool results.

10. Licensing-server outage vs. invalid licence
Two distinct cases, and neither ever touches normal XenForo operation or the free core:

• Temporary outage (our licence server briefly unreachable): fails open on the last cached verdict — Pro keeps working.
• A licence that is genuinely invalid/expired/for another domain: the Pro tool-set stops loading (intended enforcement).

Either way, only the Pro tools of the AI integration are affected — your forum and the free core continue unaffected.

11. Staging + production
This is actually a licensing or business detail rather than a technical limitation—please send me a private message about this later.

12. Rate-limiting — what exists today
Rate limiting is enforced locally by the add-on (Goldnat imposes no limits of its own on your tools). It's a per-member limit with two windows — 50 requests/minute and 1000/hour by default. To be precise: these are built-in defaults and are not currently exposed as a settings screen in the admin control panel (they live in the add-on's own settings store), so adjusting them today is not a simple UI toggle. It is also not yet splittable per-token, per-group, per-tool, per-category, or read-vs-write. Both surfacing these limits in the ACP and adding finer-grained control are candidate enhancements.

13. Idempotency / duplicate-write protection
Not present today — a client retry after a timeout could create a duplicate post/message. It's important that you raised this; we'll add it to our roadmap.

14. Pro failure isolation — clean.
If Pro is disabled, its licence fails, it throws, or it's uninstalled, the free core and normal XenForo both continue unaffected. Core and Pro are architecturally separate (Pro is a conditionally-loaded module, not a modification of core).

15. Permission-aware events/webhooks
The concept is already in our plan for the future — a narrowly-scoped, permission-aware event mechanism (mentioned / replied-to / watched-thread-changed / notification-received). The precise design of this capability isn't finalised yet, and the timing depends on demand. For now the model is polling notifications/watched content via tools, which is the expected approach in the near term.

TokenRegistry cleanup fix — confirmed present in the currently-distributed versions.

---
Bottom line: the boundaries that matter most before granting write authority — everything bounded by the member's own XF permissions, private-conversation isolation (5), attachment rechecks (6), audit-safe token handling in logs (8), data isolation on the direct path (9), failure isolation (14), and now fail-closed new tools (2) — are all in place today. On your prompting, idempotency (13) and an option to disable query-string tokens (7) go on the list, alongside action-level auditing (3), token hashing at rest (8), moderator-approval routing (4), ACP-exposed + finer rate limits (12), and events (15). Genuinely appreciate the depth of this review.

 

[chanina]

Suggest something like conversation:read access and a listConversations in order to pull recent conversations and interact with those. Currently, no way to pull a list, only interact with known conversation IDs.

Also, any eta on the moderation version? Would be a huge help.

Overall, excellent add-on. Anybody sleeping on this is missing out on practically endless possibilities.

Hi, following up on your question – Great news on both counts — they're already here.

Listing conversations: Pro already ships getUserConversations, which does exactly what you're after — it pulls the current user's private conversations as a list (title, participants, last-reply date, unread state), so you're no longer limited to interacting with known conversation IDs. From there you can drill in with getConversationand others

Moderation: no ETA needed — Today I uploaded the new plugin. That includes Forum management capabilities, node management, and design capabilities, many and varied. Every one of these runs under the acting member's real moderator permissions — the AI can only moderate where that member could moderate by hand.

Make sure you're on the current Pro build and your agent has re-fetched the manifest, and you should see all of the above. And thanks for the kind words — genuinely appreciated.

 

[chanina]

@CrazyChef

Following up on point 1 (the authoritative tool list) — the reconciliation is done, so here are the exact per-product counts as they install today:

• AI Connect (free core) — read/search + identity tools.
• AI Connect Pro — 84 tools: content read (threads/posts/forums/attachments/reactions/polls/tags), writing (threads/posts/replies/polls/profile posts), conversations (list/read/send/reply/invite/etc.).
• AI Connect Admin — 57 tools across 10 bundles (separate product/licence): nodes, node-permissions, users, credentials, discipline, usergroups, add-ons, cron, styles/appearance, widgets, options/email, phrases.

The powerful user/node/administration actions you saw on the site belong to the Admin product, not to Pro — that's why the count looked larger than the Pro resource's (now-corrected) figure. Installing Pro today gives you the 113-tool Pro set; the admin operations require the separate Admin add-on.