Settings screen polish. Plugin cards now collapse by default with a chevron toggle, show an allowed-count badge, and display each plugin's proper display name instead of its folder slug. Safe to update.<\/p>","1.1.3":"
Recommended update. Adds a Block all \/ Allow all toggle and a settings legend, fixes a duplicate save notice, removes unnecessary option autoloading, warns when the tamper-detect key has fallen back to a public default, and trims source-tracker overhead. Safe to update.<\/p>","1.1.2":"
Submission housekeeping. Removes the duplicate Plugin URI header to satisfy WordPress.org submission rules. No functional change.<\/p>","1.1.1":"
Small UX update. Saved-state banners now auto-dismiss after 2 seconds. The red tamper-detect banner is unchanged. Safe to update.<\/p>","1.1.0":"
Recommended security and reliability update. Adds signed settings with tamper detection, filter-level enforcement against race attacks, and a self-check that re-attaches the gate if removed. Fixes a source attribution bug for core abilities. Safe to update.<\/p>","1.0.0":"
Initial release.<\/p>"},"ratings":[],"assets_icons":{"icon-256x256.png":{"filename":"icon-256x256.png","revision":3531010,"resolution":"256x256","location":"assets","locale":"","width":256,"height":256}},"assets_banners":{"banner-1544x500.png":{"filename":"banner-1544x500.png","revision":3531010,"resolution":"1544x500","location":"assets","locale":"","width":1544,"height":500},"banner-772x250.png":{"filename":"banner-772x250.png","revision":3531010,"resolution":"772x250","location":"assets","locale":"","width":772,"height":250}},"assets_blueprints":{},"all_blocks":[],"tagged_versions":["1.1.4"],"block_files":[],"assets_screenshots":{"screenshot-1.png":{"filename":"screenshot-1.png","revision":3531010,"resolution":"1","location":"assets","locale":"","width":1280,"height":800}},"screenshots":{"1":"Settings screen showing every plugin that has registered AI abilities, grouped by source, with per-plugin and per-ability checkboxes"},"jetpack_post_was_ever_published":false},"plugin_section":[],"plugin_tags":[251511,83,2353,396,600],"plugin_category":[54],"plugin_contributors":[262333],"plugin_business_model":[],"class_list":["post-312252","plugin","type-plugin","status-publish","hentry","plugin_tags-abilities","plugin_tags-admin","plugin_tags-ai","plugin_tags-privacy","plugin_tags-security","plugin_category-security-and-spam-protection","plugin_contributors-codevera","plugin_committers-codevera"],"banners":{"banner":"https:\/\/ps.w.org\/codevera-ai-access-control\/assets\/banner-772x250.png?rev=3531010","banner_2x":"https:\/\/ps.w.org\/codevera-ai-access-control\/assets\/banner-1544x500.png?rev=3531010","banner_rtl":false,"banner_2x_rtl":false},"icons":{"svg":false,"icon":"https:\/\/ps.w.org\/codevera-ai-access-control\/assets\/icon-256x256.png?rev=3531010","icon_2x":"https:\/\/ps.w.org\/codevera-ai-access-control\/assets\/icon-256x256.png?rev=3531010","generated":false},"screenshots":[{"src":"https:\/\/ps.w.org\/codevera-ai-access-control\/assets\/screenshot-1.png?rev=3531010","caption":"Settings screen showing every plugin that has registered AI abilities, grouped by source, with per-plugin and per-ability checkboxes"}],"raw_content":"\n
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.<\/p>\n\n
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.<\/p>\n\n
How it works:<\/strong><\/p>\n\n Free:<\/strong><\/p>\n\n Works well for:<\/strong><\/p>\n\n Under the hood:<\/strong><\/p>\n\n 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.<\/p>\n\n The plugin stores two options in the No personal data, no visitor data, and no AJAX requests to remote services.<\/p>\n\n When the plugin is uninstalled, all three options are removed.<\/p>\n\n 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.<\/p>\n\n Minimum:<\/p>\n\n Recommended:<\/p>\n\n 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.<\/p>\n\n Form submissions use a nonce and require the 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.<\/p>\n\n From WordPress admin:<\/strong><\/p>\n\n Manual installation:<\/strong><\/p>\n\n Optional hardening:<\/strong><\/p>\n\n Add the following line to your This makes it harder for an attacker who only has database access to forge a valid settings blob.<\/p>\n\n After activation:<\/strong><\/p>\n\n No. It reads only local WordPress data and never contacts any third-party service. No telemetry, no analytics, no licence checks.<\/p><\/dd>\n No. It stores only your allow and block selections and a short list of plugin and ability identifiers in the WordPress options table.<\/p><\/dd>\n Two layers. First, on the 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.<\/p><\/dd>\n The settings option is stored as a JSON payload with an HMAC-SHA256 signature, keyed to a A malicious or buggy plugin running on the same site can call A determined plugin with code execution on the same site can in principle override the Yes. Settings are stored per-site, so each sub-site can have its own allow and block list.<\/p><\/dd>\n Yes. Blocked abilities are unregistered from the registry, so the WordPress core REST run endpoint cannot find or execute them.<\/p><\/dd>\n All of the plugin's options are deleted by Yes. The text domain is Enable \n
wp_register_ability()<\/code> and records which plugin made the call.<\/li>\n\n
\n
\n
wp_register_ability_args<\/code>, wp_abilities_api_init<\/code>, wp_unregister_ability<\/code><\/li>\ndebug_backtrace()<\/code> of the file that called wp_register_ability<\/code>, normalised to a plugin slug<\/li>\nCVAIAC_SECRET<\/code> constant or AUTH_SALT<\/code> fallback<\/li>\nwp_options<\/code><\/li>\n<\/ul>\n\nExternal Services & Privacy<\/h3>\n\n
wp_options<\/code> table:<\/p>\n\n\n
cvaiac_settings<\/code> - your allow and block selections, signed with an HMAC-SHA256 signature<\/li>\ncvaiac_ability_sources<\/code> - a map of ability name to source plugin slug, populated automatically as plugins register their abilities<\/li>\ncvaiac_schema_version<\/code> - an integer that records the storage format version, used for migration<\/li>\n<\/ul>\n\nSupport<\/h3>\n\n
Technical Requirements<\/h3>\n\n
\n
\n
Privacy & Security<\/h3>\n\n
manage_options<\/code> 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.<\/p>\n\nLinks<\/h3>\n\n
\n
\n
\n
\/wp-content\/plugins\/<\/code> directory<\/li>\nwp-config.php<\/code> to use a dedicated secret for the settings signature, rather than reusing AUTH_SALT<\/code>:<\/p>\n\ndefine( 'CVAIAC_SECRET', 'some-long-random-string-that-only-you-know' );\n<\/code><\/pre>\n\n\n
\n
Does this plugin make any external network requests?<\/h3><\/dt>\n
Does it store any personal data?<\/h3><\/dt>\n
How does it actually block an ability?<\/h3><\/dt>\n
wp_register_ability_args<\/code> filter at the highest priority, the plugin rewrites the execute_callback<\/code> and permission_callback<\/code> of any blocked ability to return a cvaiac_blocked<\/code> WP_Error. This neutralises the ability before WordPress even constructs it. Second, on the wp_abilities_api_init<\/code> action at the highest priority, the plugin walks the registry and calls wp_unregister_ability()<\/code> on anything blocked, so it disappears from the listings entirely.<\/p><\/dd>\nCan I block WordPress core abilities?<\/h3><\/dt>\n
What is the tamper-detect mode?<\/h3><\/dt>\n
CVAIAC_SECRET<\/code> constant or AUTH_SALT<\/code>. 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.<\/p><\/dd>\nWhy is fail-closed important?<\/h3><\/dt>\n
update_option( 'cvaiac_settings', array() )<\/code> 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.<\/p><\/dd>\nCan a hostile plugin still bypass this?<\/h3><\/dt>\n
pre_option_cvaiac_settings<\/code> filter, remove the enforcement hooks, or read CVAIAC_SECRET<\/code> from wp-config.php<\/code> 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.<\/p><\/dd>\nDoes it work on multisite?<\/h3><\/dt>\n
Does it work with the REST API run endpoint?<\/h3><\/dt>\n
What happens when I uninstall the plugin?<\/h3><\/dt>\n
uninstall.php<\/code>. No data is left behind.<\/p><\/dd>\nCan I translate this plugin?<\/h3><\/dt>\n
codevera-ai-access-control<\/code>. PO files can be generated with WP-CLI or any standard translation tool.<\/p><\/dd>\nHow do I troubleshoot?<\/h3><\/dt>\n
WP_DEBUG<\/code> and WP_DEBUG_LOG<\/code> in wp-config.php<\/code>. The plugin uses only standard WordPress APIs, so any issue will appear in the standard debug log.<\/p><\/dd>\n\n<\/dl>\n\n\n1.1.4<\/h4>\n\n
\n
1.1.3<\/h4>\n\n
\n
1.1.2<\/h4>\n\n
\n
1.1.1<\/h4>\n\n
\n
1.1.0<\/h4>\n\n
\n
cvaiac_settings<\/code> are detected. A failed check puts the plugin into fail-closed mode and shows a red banner until an administrator re-saves the settings<\/li>\nCVAIAC_SECRET<\/code> constant for sites that want a dedicated signing key in wp-config.php<\/code> rather than the AUTH_SALT<\/code> fallback<\/li>\nwp_register_ability_args<\/code> 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<\/li>\nwp_register_ability<\/code> 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<\/li>\n<\/ul>\n\n1.0.0<\/h4>\n\n
\n
wp_register_ability_args<\/code> filter and debug_backtrace()<\/code><\/li>\nwp_abilities_api_init<\/code> to unregister blocked abilities<\/li>\n