An AI that can edit a website is useful. An AI with unrestricted server access is an incident waiting for a date.
Forma's security strategy begins with a separation:
Editing the site is not the same job as administering the server.
The Site editor connection can work with content, media, public identity, and SEO. It does not get SSH, database access, account controls, software updates, or arbitrary PHP execution.
That boundary matters more than which model is on the other side.
The owner approves the connection
A chatbot does not receive access merely because it knows the site's URL.
Forma uses an OAuth authorization flow. The AI tool opens the real Forma site in a browser. The owner signs in there and sees a consent screen naming the client and describing the requested access.
The admin password never goes to Grok or ChatGPT. It is entered only on the owner's Forma site.
Forma also refuses chatbot connections while the install still uses the default admin password. Convenience does not get to turn a known password into an authorization system.
The grant is narrow by design
OAuth scopes are labels for capabilities. Forma's chatbot grant is hard-capped to a non-destructive Site editor set:
- Read content and public settings
- Create and update content
- Upload media
- Update public identity and SEO
- Use the agent rollback point
Delete scopes are not offered through OAuth. Neither are account management, imports, backups, server settings, or Forma updates.
This is not a checkbox the chatbot can talk its way around. The server checks the scope on every request.
If a task needs broader access, a developer can create a custom API key with explicit scopes. That is a separate, visible decision.
Credentials are short-lived and bound to one resource
After approval, Forma issues an access token that lasts one hour.
That token is audience-bound to the site's remote MCP endpoint. Even if another Forma API surface sees the same credential, it will reject it when the intended resource does not match.
The AI tool can use a refresh token to renew access without bothering the owner every hour. Refresh tokens rotate: each one is valid for one successful use, then replaced.
If an already-used refresh token appears again, Forma treats it as possible theft and revokes the connection rather than guessing which requester is legitimate.
Forma stores hashes of access tokens, refresh tokens, and authorization codes — not the usable secrets themselves. A database read should not immediately become a list of working bearer credentials.
PKCE protects the handoff
The connector is a public client. It cannot safely keep a permanent client secret, so Forma requires Proof Key for Code Exchange, or PKCE.
In plain English:
- The connector creates a private random value.
- It sends Forma a fingerprint of that value when authorization begins.
- After the owner approves, Forma issues a one-time code.
- The code can be exchanged only by a client that proves it still has the original random value.
An intercepted authorization code is therefore not enough to obtain a token.
Codes expire in minutes and can be used once.
HTTPS and browser boundaries still matter
OAuth endpoints require secure transport. Forma will not issue or refresh these credentials over ordinary HTTP on a production host.
MCP requests also enforce origin rules when a browser supplies an Origin header. That prevents the endpoint from quietly becoming a general cross-origin API for any web page that can reach it.
Login and consent forms use CSRF protection so another page cannot approve a connection on the owner's behalf.
These controls solve different problems. “We use OAuth” is not a substitute for transport security, session security, or careful browser behavior.
Disconnect means disconnect
Settings → Access lists connected AI tools.
Disconnecting one revokes:
- The registered OAuth client
- Its active access tokens
- Its refresh tokens
The owner does not have to hunt through the chatbot's settings and hope it forgets the credential. Forma can end the relationship from the resource side.
Rollback is the safety net, not the security boundary
Before the first Agent API or MCP write, Forma saves one last-known-good point. If an editing session goes badly, Put it back restores the source-of-truth content and supporting generated assets.
That is operational safety. It is not permission control.
The scope checks should prevent an agent from doing dangerous classes of work in the first place. The checkpoint handles allowed edits that were simply wrong: bad copy, an unwanted redesign, or a bulk SEO pass you regret.
Security asks “was this action allowed?” Rollback asks “did we like the result?”
The honest limitation
No authorization design can decide whether a sentence is on-brand, whether a claim is true, or whether publishing it is wise.
Forma can constrain what kind of change an AI is allowed to make. It cannot replace editorial review.
That is why the recommended workflow remains: let the tool read, ask it to propose, approve a bounded change, inspect the public result, and only then mark the checkpoint good.
The goal is not autonomous everything. It is useful access with a small blast radius.