pteglia

PillarShield integrates WordPress with the PillarShield SaaS governance API. It runs checks at the publish boundary, blocks non‑compliant content, allows optional overrides, and keeps a governance record per post for reporting. You must obtain a PillarShield API key from https://pillarshield.co for the plugin to function.
Key features:
<ul>
<li>Gate governance checks on publish/private statuses (configurable per post type).</li>
<li>Optional manual checks that never block saves.</li>
<li>Override workflow for privileged users.</li>
<li>Governance reporting under Tools → PillarShield (blocked-at-gate items only).</li>
<li>Safe storage of outcomes without raw content.</li>
</ul>
<h3>Configuration</h3>
Settings → PillarShield:
<ul>
<li>API Endpoint: The PillarShield governance endpoint.</li>
<li>API Key: Your tenant API key (<code>psk_...</code>).
<ul>
<li>Get a key at https://pillarshield.co. The plugin does not perform governance checks without a valid API key.</li>
<li>You can also define <code>PILLARSHIELD_API_KEY</code> in <code>wp-config.php</code> to override the stored option: 
define(‘PILLARSHIELD_API_KEY’, ‘psk_…’);</li>
</ul>
</li>
<li>Enable Governance: Turn checks on/off.</li>
<li>Allow Save Without API: Allow publishing if the API is unavailable.</li>
<li>Enabled Post Types: Which post types are governed.</li>
<li>Fields per Post Type: Comma‑separated fields to scan. Supports <code>meta:KEY</code>.</li>
<li>Gate Configuration:
<ul>
<li>Gated statuses (default: publish + private)</li>
<li>Fallback status (default: draft)</li>
</ul>
</li>
</ul>
Use the Test Connection button to validate API access.
<h3>Editor UX</h3>
On governed post types, a PillarShield meta box appears with:
<ul>
<li>Check PillarShield governance on this save (manual check)</li>
<li>Override PillarShield governance (save anyway)</li>
</ul>
These checkboxes do not persist — they only apply to the current save.
<h3>Permissions (Roles/Capabilities)</h3>
PillarShield adds these capabilities:
<ul>
<li><code>pillarshield_manage_settings</code> — manage settings page</li>
<li><code>pillarshield_view_reports</code> — view reports</li>
<li><code>pillarshield_manual_check</code> — run manual check</li>
<li><code>pillarshield_override_governance</code> — override violations</li>
</ul>
On activation, these are granted to Administrators only.
Override visibility requirement: 
The Override checkbox only appears for users who have the <code>pillarshield_override_governance</code> capability. Editors will not see it unless you explicitly grant that capability via a role editor plugin or custom code.
<h3>Reporting</h3>
Tools → PillarShield:
<ul>
<li>Overview of content currently blocked at the gate.</li>
<li>Details page per post with block reason and metadata.</li>
</ul>
<h3>External services</h3>
This plugin connects to the PillarShield governance API to evaluate post content for compliance before publishing.
Service: PillarShield SaaS governance API, operated by PillarShield. 
Endpoint: https://api.pillarshield.co/pillarshield-governance/governance
What is sent and when: 
When a user saves a post to a gated status (by default: publish or private) on a governed post type, or manually triggers a governance check, the plugin sends a POST request containing:
<ul>
<li>The post’s configured content fields (by default: title, body, and excerpt)</li>
<li>Post metadata: post type, post ID, post UUID, post URL, and target publish status</li>
<li>WordPress user context: user ID and roles (no email or username is transmitted)</li>
<li>The tenant API key</li>
</ul>
No data is sent during autosaves, revisions, or saves to non-gated statuses. The plugin requires a valid API key obtained from https://pillarshield.co to function.
<ul>
<li><a href="https://pillarshield.co/terms" rel="nofollow ugc">Terms of service</a></li>
<li><a href="https://pillarshield.co/privacy-policy" rel="nofollow ugc">Privacy policy</a></li>
</ul>
<h3>Support</h3>
Support and documentation: https://pillarshield.co.

PillarShield

Connect WordPress to the PillarShield SaaS API and enforce governance checks at publish time.

Haktan Suren

HandL AI Connector Access Control lets administrators allow/deny AI Client prompt execution on a per-plugin basis using the <code>wp_ai_client_prevent_prompt</code> filter introduced with the WordPress AI Client.
Default behavior is allow.
Learn mode (Audit & log tab) logs every AI Client call without blocking, so you can discover callers before enabling deny rules on the Plugin rules tab.
Emergency kill switch blocks all AI Client calls except plugins you list as exceptions.
Caller attribution is best-effort and is determined by inspecting the PHP call stack and mapping file paths to installed plugins.
<h3>Privacy / Data</h3>
This plugin does not send data to any external service.
If you enable recent-call logging in Settings → HandL AI Connector Access Control, it stores a local log in the WordPress options table containing:
<ul>
<li>Timestamp</li>
<li>Allow/deny decision</li>
<li>AI Client operation (e.g. <code>generate_text</code>, <code>is_supported_for_text_generation</code>)</li>
<li>Provider and model when set on the prompt builder (or model preferences)</li>
<li>Truncated prompt preview and selected generation config (best-effort)</li>
<li>Input and output token counts when the AI Client completes a generation (best-effort)</li>
<li>Best-effort calling plugin (plugin basename) and source file</li>
<li>Current user id and display name</li>
<li>Request URI</li>
</ul>
Logs are kept as a count-based ring buffer (default 200 entries, configurable 20–1000). There is no time-based TTL—older rows drop only when the buffer is full.
Logging is disabled by default.

HandL AI Connector Access Control

Control which plugins may execute prompts via the WordPress AI Client.

PillarShield vs HandL AI Connector Access Control