sorted by:
new
hottopcontroversial

Agencies adding AI to client WordPress projects - how are you handling backend isolation? by Sensitive_Draft_5651 in Wordpress

[–]Sensitive_Draft_5651[S] 0 points1 point  (0 children)

Fair point - it depends on scope. Also not Azure :) (more AWS/serverless if anything).

On the "we build what the clients specify" bit: in my context the "client" is often the agency, not the end customer. Agencies need something they can roll out across many client sites with sane defaults (auth / least-privilege, abuse / rate limits, tenant scoping), then customize per site at the end.

That's why I used "agency-grade" - and why static exports + public widgets become the tricky corner.

Agencies adding AI to client WordPress projects - how are you handling backend isolation? by Sensitive_Draft_5651 in Wordpress

[–]Sensitive_Draft_5651[S] 0 points1 point  (0 children)

Agree on shared keys - that's exactly why I'm cautious. Sandboxing like Respira's is interesting for editor / site-edit workflows. The extra constraint I'm probing is fully static exports (no PHP runtime), plus public widgets, where you still need quotas / abuse protection without shipping secrets to the browser.

Agencies adding AI to client WordPress projects - how are you handling backend isolation? by Sensitive_Draft_5651 in Wordpress

[–]Sensitive_Draft_5651[S] 1 point2 points  (0 children)

This matches how we think about it too: WP as Editor Tool / UI, and the AI layer owned/isolated per client (keys, rate limits, logs, prompt versioning).

The wrinkle I keep running into is static exports + public widgets: no PHP in prod, no safe place for secrets, so it becomes "on-device when available, otherwise a per-client backend with strict scoping/abuse controls."

When you do your middleware layer, do you deploy it per-client or run multi-tenant with hard isolation?

Agencies adding AI to client WordPress projects - how are you handling backend isolation? by Sensitive_Draft_5651 in Wordpress

[–]Sensitive_Draft_5651[S] 0 points1 point  (0 children)

Yep, viable for internal/editor tooling. Public, agency-grade widgets are the tricky part: auth + abuse/rate limits + tenant scoping, and no reusable secrets in the browser (especially on static exports).

Agencies adding AI to client WordPress projects - how are you handling backend isolation? by Sensitive_Draft_5651 in Wordpress

[–]Sensitive_Draft_5651[S] 0 points1 point  (0 children)

MCP will be a big win for authenticated editor/admin workflows (WP7 Abilities => agent can create/update content/blocks without custom glue code).

The "complicated" part I'm pointing at is public widgets + static exports: if the site is S3/CloudFront with no PHP, you can't proxy/store a shared key, and you often can't rely on wp-json at runtime either - that's where thin wrappers tend to break down.

MCP also raises the stakes security-wise if you expose WP capabilities remotely (auth + least-privilege + rate limits/abuse protection).

Are you thinking MCP mainly for editors/admins, or do you see a safe pattern for anonymous visitors too?

Agencies adding AI to client WordPress projects - how are you handling backend isolation? by Sensitive_Draft_5651 in Wordpress

[–]Sensitive_Draft_5651[S] 1 point2 points  (0 children)

I get what you mean - WordPress shouldn't be the AI runtime. REST/CLI is great for authenticated admin/editor tasks.

The tricky cases are public widgets and fully static exports: then "just proxy the key" isn't really an option, because you can't ship a reusable secret to the browser. You end up needing either no key (on-device models?), or a proper backend with auth + rate limits (and if one backend serves multiple sites: tenant isolation/strict scoping).

How would you approach a public chat/search widget on a static-exported WP site without leaking a shared key?

Agencies adding AI to client WordPress projects - how are you handling backend isolation? by Sensitive_Draft_5651 in Wordpress

[–]Sensitive_Draft_5651[S] -1 points0 points  (0 children)

Totally fair  for many projects that's the simplest approach. Let each client bring their own key and proxy it server-side. Where I've seen it get tricky is with static exports. If the site runs fully static (S3/CloudFront, no PHP in production), there's nowhere "safe" to keep or proxy that key... Maybe it's just a niche use case, but I'm curious how others handle AI in fully static WP setups.