Farpals: Extensible Sovereign Actions for Any AI

An extensible, model-agnostic MCP gateway that keeps applications sovereign. AI agents receive only their user’s native permissions. WordPress is the first adapter.

Comment

Farpals - Devpost Project Story

Inspiration

The next generation of AI will not stop at answering questions or writing codes. They will act across the software and services people already depend on.

Thinking about that they were just came into the world as chatbots not long time ago, but imagine asking ChatGPT to book a flight within a travel policy, Grok to buy concert tickets without exceeding a price limit, Claude to analyze authorized NCBI data, or Gemini to operate a remote 3D-design application. Each experience creates a question harder than tool calling:

When an AI acts, whose identity and permissions does it use and who makes the final decision?

We call the answer application sovereignty. A model may understand intent and propose an action, but the application that owns the account, data, business rules, and audit trail must remain the final authority. Authorization should follow the user inside that application, not the brand of model making the request.

Farpals is an extensible, model-agnostic MCP gateway built around that idea:

The model proposes. Farpals constrains. The application decides.

Why WordPress first

We needed an Adapter familiar enough for real testing and rich enough to expose the authorization problems future agentic applications will face. WordPress offers both enormous adoption and a natural complexity ladder:

  • posts and pages provide clear create, edit, review, publish, and delete workflows;
  • Subscriber, Contributor, Author, and Editor roles make progressively broader permissions visible; and
  • A rich plugin ecosystem provides scalability. For example, WooCommerce shows how the same ecosystem can extend into products, orders, inventory, customers, and payments.

WordPress is therefore the first Farpals Adapter, and not its definition or limit.

What Farpals does

In a configured deployment, a user adds its MCP URL to a compatible client, signs in through WordPress OAuth, reviews the connection, and receives only the tools permitted by that WordPress account's current native capabilities. Farpals creates no parallel “AI role” and does not allow-list model vendors.

A Subscriber can authorize a connection but receives no editorial tools. A Contributor can create a post and submit it for review but cannot publish it. An Author can publish the Author's own posts, while an Editor can work across authors and receives page tools. Publish and delete still require explicit confirmation. WordPress rechecks both the general capability and the target object during execution.

Denial is therefore a successful outcome. In our Grok test, a Contributor created a post and submitted it for review, but an attempt to publish correctly remained pending. Farpals did not elevate the account to make the demo succeed.

Farpals v0.4 is a working hackathon reference implementation and hosted evaluation prototype, not yet a public WordPress SaaS. Its hosted Core is paired with the Farpals Lab and does not accept arbitrary WordPress sites. Judges can test the complete role workflow with privately supplied Lab accounts, while authorized reviewers can reproduce the deployment from the private repository. A Plugin-first managed Core is a release gate before the Adapter is offered to general WordPress administrators.

How we built it

Farpals separates a model-agnostic Node.js Core from a WordPress-specific PHP Adapter.

The Core owns Streamable HTTP MCP transport, OAuth protected-resource discovery, dynamic tool translation, confirmation orchestration, and an optional reference-agent path. It does not define WordPress roles.

The Adapter keeps application authority inside WordPress: user identity, OAuth Authorization Code with PKCE, revocable Agent Keys, live capability discovery, validation, execution, confirmation enforcement, and bounded audit records. The Core may be hosted elsewhere, but WordPress remains authoritative on every request.

The prototype uses Node.js, PHP, WordPress, MariaDB, Docker, Google Compute Engine, Cloudflare Tunnel, OAuth, and MCP. Adapter and Core are packaged separately, and the same Docker workflow runs locally and in GitHub Actions.

How Codex and GPT-5.6 were used

Codex was the primary development environment, with GPT-5.6 Sol used throughout the development session. This workflow built the Core, Adapter, OAuth flow, MCP server, tests, deployment scripts, and documentation; inspected real logs; and iterated on interoperability failures found with Cursor and Grok.

Separately, the repository contains an optional GPT-5.6 Responses API reference-agent path. It is designed to receive the bounded tools exposed by the Adapter and pause confirmation-gated work before execution. This path is implemented and unit-tested with a mocked OpenAI client, but it has not been enabled with a real OpenAI API key or live-tested end to end. It remains disabled in the hosted Lab.

Challenges and lessons

Mapping an agent to a real application user

The hardest problem was identity, not function calling. At the begining, shared-credential and demo-permission approaches were suggested and implemented by AI agents. However, it was quickly noticed for deviating from actual needs, therefore, the approach based on OAuth connections and Agent Keys mapped to real WordPress users was developed to replace the early one. Tools are derived from live native capabilities instead of a Farpals role table.

Supporting real OAuth and MCP clients

Clients differ in callbacks, popup behavior, unauthenticated probes, and query handling. We added standards-based protected-resource metadata, dynamic client registration, PKCE S256, signed login continuation, callback normalization, and rotating refresh tokens while preserving one authorization boundary.

Keeping the Adapter usable

Typical WordPress administrators should not need to operate Node.js. Splitting the lightweight Adapter from the Core proves the architecture, but it also revealed the next product requirement: a managed multi-tenant Core with Plugin-first onboarding, verified-site routing, tenant isolation, and abuse controls. Self-hosting remains valuable for advanced and sovereignty-sensitive deployments, but it cannot be the default consumer experience.

Building a meaningful shared Lab

A public demo is useful only if reviewers can perform real actions, but giving every visitor Administrator access would hide the permission problem Farpals is meant to solve. The judging environment therefore uses ordinary Subscriber, Contributor, Author, and Editor accounts rather than demo-specific roles. Each OAuth connection remains individually revocable, risky actions still require confirmation, and audit records exclude content bodies and credentials. This lets reviewers observe both permitted actions and intentional denials without turning the Lab into evidence of unrestricted authority.

The broader lesson is that interoperability is part of security. If standards work with only one ideal client, users will fall back to copied secrets or over-privileged integrations, potentially harming security.

Accomplishments

  • Live MCP tools derived from native WordPress permissions
  • OAuth with PKCE plus durable, individually revocable Agent Keys
  • Post and page workflows with confirmation-gated publish and delete
  • Object-level WordPress authorization and bounded audit records
  • Separately installable Adapter and Core packages
  • Successful OAuth connections from Cursor, Codex, and Grok
  • Reproducible Docker and GitHub Actions end-to-end tests
  • 18 of 18 Node.js tests passing

The automated workflow verifies OAuth discovery and registration, PKCE, refresh rotation, Agent Key revocation, role-derived tools, Contributor publish denial, confirmation gates, and audit visibility.

The Farpals logo

Two simplified triangular A forms represent AI ↔ Applications. The lightning stroke between them represents Farpals, the controlled path through which intent becomes an application action. Both A remains distinct as the application keeps its identity, permissions, rules, and final authority.

What's next

The immediate priorities are a managed Core with Plugin-first onboarding; persistent approvals, stronger audit and abuse controls; broader WordPress and WooCommerce capabilities; and a documented Adapter SDK and conformance suite. Beyond WordPress, Farpals can extend to commerce, scientific data, productivity, and creative tools while each application retains its separately authorized identity.

The long-term goal of Farpals is not to make applications subordinate to AI. It is to let AI become useful across applications while those applications - and their users - remain sovereign.

Built With

Share this project:

Updates

Submission history