MCP Sentinel | Open Source | Wilkes & Liberty

MCP Sentinel is for Drupal owners and security teams that need AI agents to work against a real CMS without inheriting ordinary administrator freedom. Wilkes & Liberty maintains the GPL-licensed Drupal module. It enforces policy inside Drupal for authenticated agent traffic over MCP, JSON:API, and governed GraphQL paths, so a connector or client cannot waive the site's final rules.

Why it exists

An external connector can restrict itself, but a self-imposed restriction is not a security boundary. If its credential can publish, read sensitive fields, or extract large datasets, a bug or compromised client can still exercise that authority. MCP Sentinel gives the CMS an independent answer to “may this agent perform this operation, on this entity, in this environment, right now?”

The module distinguishes agent traffic using validated OAuth consumers and scopes—not a presentation header. Browser sessions and normal editorial administration stay outside the agent channel.

Who should use it, and when

Drupal platform owners enabling AI-assisted content operations on production or regulated sites.
Security and compliance operators who need least privilege, attributable actions, data-loss controls, and evidence after a change.
Editorial teams that want agents to prepare drafts without allowing them to publish or overwrite a page someone is editing.
Integration developers exposing custom Tool plugins or GraphQL operations that need the same policy profile as ordinary entity writes.

Use MCP Sentinel when an automated client can reach non-public Drupal data or mutate the site. A read-only public-content integration may not need this full control plane.

Where it sits

MCP Sentinel runs in Drupal. OAuth consumer scopes identify the capability tier; the authenticated account's roles select a policy profile. The profile is evaluated at Drupal's API, entity, field, configuration, and tool boundaries. The companion Drupal MCP Connector translates MCP calls into Drupal operations, while Sentinel remains the server-side authority.

Audit records are delegated to Audit Chain, which provides independent hash-chain verification and optional signing/encryption.

What a policy profile controls

Operation gates: separate read, create/update, delete, publish, configuration, GraphQL mutation, and raw-SQL decisions.
Entity and field boundaries: allowlists, denylists, sensitive-field redaction, and PII/DLP pattern masking.
OAuth scopes: standardized mcp_read, mcp_write, and mcp_config tiers enforced per tool.
Publish control: publishing is denied by default and can remain an owner-only transition even when draft writes are allowed.
Rate and exfiltration limits: request throttles, daily quotas, result caps, and bulk-export controls.
Network controls: per-profile IP/CIDR allowlists with explicit trusted-proxy requirements.
Content locks: an agent is prevented from overwriting a node currently being edited.
Redirect and outbound safety: off-domain redirects and webhook targets are bounded to approved hosts.

Operational evidence and response

Allowed and denied operations are attributable to the acting account and consumer. Audit metadata can include entity identifiers, operation, policy profile, client label, network context, and redaction-aware change detail. Audit Chain supplies the tamper-evident sequence, Drush verification, optional HMAC signing, encryption, rotation handling, and SIEM streaming.

Anomaly rules can alert on denial bursts, unusual volume, or other configured conditions without putting alert delivery on the request path. Reliable webhooks use a delivery queue, retries, SSRF protections, delivery history, and replay rather than a single fire-and-forget callback.

Shipped integration modules

MCP Sentinel Server exposes Sentinel's governed Tool plugins through Drupal's MCP Server ecosystem.
MCP Sentinel Approval adds a human approval workflow for actions that should be proposed before execution.
MCP Sentinel GraphQL extends governance to configured GraphQL operations and mutations.

The base security, audit, lock, and webhook controls work without requiring every optional submodule.

Install and establish the trust model

Release 2.3.0 requires PHP 8.3+, Drupal 10.6+ or 11.3+, Simple OAuth, Consumers, Key, Encrypt, Tool, and Audit Chain.

composer require drupal/mcp_sentinel
drush en mcp_sentinel mcp_sentinel_server -y
drush mcp-sentinel:setup

For each environment, create a dedicated OAuth consumer and account, grant only the required MCP scopes, assign a non-administrator role, select the policy profile, export non-secret configuration, and keep client secrets in a Key provider rather than configuration YAML. The connector contract documents the exact token, scope, proxy, and end-to-end verification steps.

Honest boundaries

MCP Sentinel governs requests that pass through Drupal and its registered integration seams. It cannot govern an operator with direct database access, unrestricted shell access, or a custom module that deliberately bypasses Drupal access APIs. Raw SQL is therefore off by default and is available only through the Sentinel-governed Drush command when both sides opt in.

Redaction reduces exposure in governed responses; it cannot erase data already available through another API or credential. IP allowlists are safe only when Drupal's trusted-proxy configuration is correct. Anomaly detection and webhooks provide signals, not an incident-response program. Policy design, account lifecycle, key custody, review of approvals, and response ownership remain organizational responsibilities.

Project, source, issues, and operator documentation

Maintained by Jeremy Michael Cerda and Wilkes & Liberty under GPL-2.0-or-later. The checked source release for this page is 2.3.0.