Title: Codevera AI Access Control Author: codevera Published: 13 maja, 2026 Last modified: 13 maja, 2026 --- Search plugins ![](https://ps.w.org/codevera-ai-access-control/assets/banner-772x250.png?rev=3531010) ![](https://ps.w.org/codevera-ai-access-control/assets/icon-256x256.png?rev=3531010) # Codevera AI Access Control By [codevera](https://profiles.wordpress.org/codevera/) [Download](https://downloads.wordpress.org/plugin/codevera-ai-access-control.1.1.4.zip) * [Details](https://sl.wordpress.org/plugins/codevera-ai-access-control/#description) * [Reviews](https://sl.wordpress.org/plugins/codevera-ai-access-control/#reviews) * [Installation](https://sl.wordpress.org/plugins/codevera-ai-access-control/#installation) * [Development](https://sl.wordpress.org/plugins/codevera-ai-access-control/#developers) [Support](https://wordpress.org/support/plugin/codevera-ai-access-control/) ## Description WordPress 7.0 introduced the Abilities API. Any active plugin can register an ability and the WordPress AI feature can then invoke it, consuming whatever credits or tokens your AI provider charges per call. By default every registered ability is exposed, and there is no built-in way to see what is exposed or to limit it. Codevera AI Access Control adds a single settings screen that lists every plugin which has registered AI abilities, grouped by source plugin, and lets you allow or block each plugin as a whole or each individual ability. **How it works:** 1. The plugin watches every call to `wp_register_ability()` and records which plugin made the call. 2. The Settings -> Codevera AI Access screen groups those abilities by source plugin so you can see at a glance what is exposed. 3. Untick a plugin or a single ability and save. From the next request onwards, the AI feature can no longer see or invoke it. **Free:** * Per-plugin and per-ability granular controls * Automatic detection of newly installed plugins that register AI abilities, with an in-admin notification so you can review them * Tamper-detect signature on the saved settings, with a fail-closed mode that blocks every non-core ability if the settings option is modified outside the plugin * Filter-level enforcement that neutralises a blocked ability before WordPress constructs it, plus a registry sweep that removes blocked abilities from the listings * Self-check that re-attaches the enforcement hooks on init, admin_init and rest_api_init if another plugin removes them * Search and filter inside each plugin card so large registries stay readable * No external requests, no telemetry, no licence checks * Works on multisite (per-site settings) * Translation ready **Works well for:** * Sites where editorial staff use the WordPress AI feature and you want strict control over what context the AI can pull in * Agency sites where new plugins are installed regularly and you want to review their AI exposure before letting them in * Privacy-sensitive sites that need an explicit allow list of which plugins may expose data to an AI provider * Compliance-driven environments that need an auditable record of which plugins have been allowed to register AI abilities **Under the hood:** * Uses only the official Abilities API surface: `wp_register_ability_args`, `wp_abilities_api_init`,` wp_unregister_ability` * Source attribution from `debug_backtrace()` of the file that called `wp_register_ability`, normalised to a plugin slug * HMAC-SHA256 signature on the settings option, keyed to a `CVAIAC_SECRET` constant or `AUTH_SALT` fallback * No frontend assets shipped, all code runs in admin and on the AI Abilities REST routes * No database tables, just two options in `wp_options` ### External Services & Privacy This plugin does not contact any external service. It reads only local WordPress data. No telemetry, no analytics, no licence checks, no remote update checks beyond what WordPress core itself performs. The plugin stores two options in the `wp_options` table: * `cvaiac_settings` – your allow and block selections, signed with an HMAC-SHA256 signature * `cvaiac_ability_sources` – a map of ability name to source plugin slug, populated automatically as plugins register their abilities * `cvaiac_schema_version` – an integer that records the storage format version, used for migration No personal data, no visitor data, and no AJAX requests to remote services. When the plugin is uninstalled, all three options are removed. ### Support Email info@codevera.ai for support, bug reports, or feature requests. Include your WordPress version, PHP version, a list of other plugins that register AI abilities, and a description of the issue with steps to reproduce. ### Technical Requirements Minimum: * WordPress 7.0 (required for the Abilities API) * PHP 7.4 Recommended: * WordPress 7.0 or higher * PHP 8.0 or higher ### Privacy & Security The plugin does not collect or transmit any personal data. The settings option is stored locally and signed with an HMAC keyed to a site-specific secret. The source- tracker option contains only plugin slugs and ability names that are already public to any code running on the site. Form submissions use a nonce and require the `manage_options` capability. The enforcement hooks run on every request that loads the Abilities API, so blocking takes effect from the next request after a setting is saved. This plugin defends against opportunistic interference such as another plugin writing directly to the settings option, removing the enforcement hooks, or re-registering an ability that has already been blocked. It does not claim to be a security boundary against a fully hostile plugin that has code execution in the same PHP process. The safest practice is still to only install plugins you trust. ### Links * Website: https://codevera.ai * Support: info@codevera.ai ## Screenshots * [[ * Settings screen showing every plugin that has registered AI abilities, grouped by source, with per-plugin and per-ability checkboxes ## Installation **From WordPress admin:** 1. Go to Plugins -> Add new 2. Search for “Codevera AI Access Control” 3. Click Install now and then Activate 4. Go to Settings -> Codevera AI Access 5. Review the list of plugins that have registered AI abilities 6. Untick anything you do not want the AI feature to use 7. Click Save changes **Manual installation:** 1. Download the plugin zip file 2. Upload to the `/wp-content/plugins/` directory 3. Extract the files 4. Activate through the Plugins menu in WordPress 5. Configure as described above **Optional hardening:** Add the following line to your `wp-config.php` to use a dedicated secret for the settings signature, rather than reusing `AUTH_SALT`: ``` define( 'CVAIAC_SECRET', 'some-long-random-string-that-only-you-know' ); ``` This makes it harder for an attacker who only has database access to forge a valid settings blob. **After activation:** * Visit Settings -> Codevera AI Access to see which plugins have registered abilities * Untick any plugin or ability you do not want to expose to the AI feature * Save changes * When a new plugin is installed and registers an ability, you will see a Newly detected items banner the next time you open the settings screen ## FAQ ### Does this plugin make any external network requests? No. It reads only local WordPress data and never contacts any third-party service. No telemetry, no analytics, no licence checks. ### Does it store any personal data? No. It stores only your allow and block selections and a short list of plugin and ability identifiers in the WordPress options table. ### How does it actually block an ability? Two layers. First, on the `wp_register_ability_args` filter at the highest priority, the plugin rewrites the `execute_callback` and `permission_callback` of any blocked ability to return a `cvaiac_blocked` WP_Error. This neutralises the ability before WordPress even constructs it. Second, on the `wp_abilities_api_init` action at the highest priority, the plugin walks the registry and calls `wp_unregister_ability()` on anything blocked, so it disappears from the listings entirely. ### Can I block WordPress core abilities? You can block individual core abilities, but the WordPress core group as a whole cannot be blocked. Blocking individual core abilities can prevent the AI feature from working correctly, so do it with care. ### What is the tamper-detect mode? The settings option is stored as a JSON payload with an HMAC-SHA256 signature, keyed to a `CVAIAC_SECRET` constant or `AUTH_SALT`. Each time the plugin reads the option, the signature is recomputed and checked. If it does not match, the plugin enters fail-closed mode and blocks every non-core ability until an administrator re-saves the settings through the UI. A red banner appears on the settings screen explaining what happened. ### Why is fail-closed important? A malicious or buggy plugin running on the same site can call `update_option( 'cvaiac_settings', array() )` to wipe your block list. With tamper detect, that write produces an invalid signature, the plugin notices, and the AI feature loses access to every plugin’s abilities until you investigate and re-save. ### Can a hostile plugin still bypass this? A determined plugin with code execution on the same site can in principle override the `pre_option_cvaiac_settings` filter, remove the enforcement hooks, or read ` CVAIAC_SECRET` from `wp-config.php` to forge a valid signature. This plugin defends against opportunistic interference, not against a fully hostile plugin in the same PHP process. Treat it as a policy and tamper-detect tool, not a security boundary. The safest practice is still to only install plugins you trust. ### Does it work on multisite? Yes. Settings are stored per-site, so each sub-site can have its own allow and block list. ### Does it work with the REST API run endpoint? Yes. Blocked abilities are unregistered from the registry, so the WordPress core REST run endpoint cannot find or execute them. ### What happens when I uninstall the plugin? All of the plugin’s options are deleted by `uninstall.php`. No data is left behind. ### Can I translate this plugin? Yes. The text domain is `codevera-ai-access-control`. PO files can be generated with WP-CLI or any standard translation tool. ### How do I troubleshoot? Enable `WP_DEBUG` and `WP_DEBUG_LOG` in `wp-config.php`. The plugin uses only standard WordPress APIs, so any issue will appear in the standard debug log. ## Reviews There are no reviews for this plugin. ## Contributors & Developers “Codevera AI Access Control” is open source software. The following people have contributed to this plugin. Contributors * [ codevera ](https://profiles.wordpress.org/codevera/) [Translate “Codevera AI Access Control” into your language.](https://translate.wordpress.org/projects/wp-plugins/codevera-ai-access-control) ### Interested in development? [Browse the code](https://plugins.trac.wordpress.org/browser/codevera-ai-access-control/), check out the [SVN repository](https://plugins.svn.wordpress.org/codevera-ai-access-control/), or subscribe to the [development log](https://plugins.trac.wordpress.org/log/codevera-ai-access-control/) by [RSS](https://plugins.trac.wordpress.org/log/codevera-ai-access-control/?limit=100&mode=stop_on_copy&format=rss). ## Changelog #### 1.1.4 * Collapsed each plugin card by default and added a chevron toggle, so the settings screen stays compact when many plugins register abilities. * Added an allowed-count badge to every plugin card that shows how many of its abilities are currently allowed for AI, with a red badge when none are allowed and a green badge when all are allowed. * Replaced the raw plugin folder slug in each card heading with the plugin’s display name, and moved the folder slug to a smaller secondary line for reference. #### 1.1.3 * Added a Block all and Allow all toggle to the settings screen so administrators can clear or tick every plugin and ability in one click. * Added an on-screen legend that explains a ticked box means the plugin or ability is allowed for AI, and an unticked box means it is blocked. * Stopped a duplicate Settings saved notice from appearing after save by namespacing the success flag so it no longer collides with WordPress core. * Stopped the cvaiac_settings and cvaiac_schema_version options from autoloading on every request. Both options are now read on demand only. * Added an admin notice that warns when neither CVAIAC_SECRET nor AUTH_SALT is defined in wp-config.php, so site owners know the tamper-detect signature is using a public fallback key. * Reduced source-tracker overhead by skipping the debug_backtrace call when an ability’s source plugin is already known from a previous request. #### 1.1.2 * Removed the redundant Plugin URI header so it no longer matches the Author URI, which is a WordPress.org submission requirement. #### 1.1.1 * Auto-dismiss the Settings saved and Newly detected items acknowledged banners after 2 seconds, so the screen tidies itself up after a save. The red tamper- detect banner is unaffected and stays until you re-save. #### 1.1.0 * Added an HMAC-SHA256 signature on the settings option so direct database writes to `cvaiac_settings` are detected. A failed check puts the plugin into fail-closed mode and shows a red banner until an administrator re-saves the settings * Added a `CVAIAC_SECRET` constant for sites that want a dedicated signing key in `wp-config.php` rather than the `AUTH_SALT` fallback * Added filter-level enforcement on `wp_register_ability_args` so blocked abilities are neutralised before WordPress constructs them, closing a same-priority race where another plugin could re-register a blocked ability at PHP_INT_MAX * Added a self-check on init, admin_init and rest_api_init that re-attaches the enforcement hooks if another plugin removes them * Fixed source attribution for abilities registered by WordPress core. The source tracker now reads the immediate caller of `wp_register_ability` rather than the first plugin-dir frame on the stack, so core abilities are correctly attributed to “core” even when a plugin’s code triggers the lazy registry init #### 1.0.0 * Initial release * Settings screen grouping registered abilities by source plugin * Per-plugin and per-ability allow and block controls * Source tracking using `wp_register_ability_args` filter and `debug_backtrace()` * Registry sweep on `wp_abilities_api_init` to unregister blocked abilities * Newly detected items notification with an Acknowledge action * Uninstall script that removes all plugin options ## Meta * Version **1.1.4** * Last updated **5 ur ago** * Active installations **Fewer than 10** * WordPress version ** 7.0 or higher ** * Tested up to **7.0** * PHP version ** 7.4 or higher ** * Language * [English (US)](https://wordpress.org/plugins/codevera-ai-access-control/) * Tags * [abilities](https://sl.wordpress.org/plugins/tags/abilities/)[admin](https://sl.wordpress.org/plugins/tags/admin/) [AI](https://sl.wordpress.org/plugins/tags/ai/)[privacy](https://sl.wordpress.org/plugins/tags/privacy/) [security](https://sl.wordpress.org/plugins/tags/security/) * [Advanced View](https://sl.wordpress.org/plugins/codevera-ai-access-control/advanced/) ## Ratings No reviews have been submitted yet. [Your review](https://wordpress.org/support/plugin/codevera-ai-access-control/reviews/#new-post) [See all reviews](https://wordpress.org/support/plugin/codevera-ai-access-control/reviews/) ## Contributors * [ codevera ](https://profiles.wordpress.org/codevera/) ## Support Got something to say? Need help? [View support forum](https://wordpress.org/support/plugin/codevera-ai-access-control/)