Aimogen ProDocumentation
Product page Support

Where credentials are stored

How Aimogen Pro stores API keys and other credentials, who can read them, and how to supply them from code instead of the database.

The storage model#

Every credential — provider API keys, storage keys, SERP keys, translation keys, the REST API keys, MCP bearer tokens — is stored as plain text in the WordPress options table, inside aiomatic_Main_Settings (or aiomatic_mcp_settings for MCP).

This is the same model used by the overwhelming majority of WordPress plugins that talk to third-party APIs. It is not unusual, and it is worth understanding rather than being alarmed by.

Who can read them#

WhoHow
Anyone with manage_optionsThe settings screens, or get_option()
Anyone with database accessA SELECT on wp_options
Anyone who can run PHP on the siteget_option( 'aiomatic_Main_Settings' )
Anyone with a database backupBackups contain the options table
An agent with query_wp_databaseA query against wp_options

That last one is worth pausing on. An agent with read-only database access can read your API keys and put them into a provider request. Consider it when choosing agent tools.

Keeping keys out of the database#

Every provider credential passes through a filter, so it can come from anywhere.

php
// wp-config.php
define( 'MY_OPENAI_KEY', 'sk-...' );
php
// A must-use plugin
add_filter( 'aimogen_openai_api_key', function () {
    return defined( 'MY_OPENAI_KEY' ) ? MY_OPENAI_KEY : '';
} );

Leave the settings field empty and the filter supplies the value at request time.

From an environment variable:

php
add_filter( 'aimogen_anthropic_api_key', function () {
    return getenv( 'ANTHROPIC_API_KEY' ) ?: '';
} );

The full list of credential filters is in Filter reference.

Multiple keys#

Every provider field accepts one key per line. That enables smart rotation, and it means a compromised key can be removed without downtime.

Key health records are keyed by an HMAC-SHA256 fingerprint salted with the WordPress auth salt. Health records contain the provider, failure category, status, failure count and cooldown expiry — never the key. Fingerprints are site-specific and cannot be reversed.

That is why the diagnostics are safe to share.

Rotating a key#

  1. Create a new key at the provider.
  2. Add it to the field, on its own line, alongside the old one.
  3. Confirm generation still works.
  4. Remove the old line.
  5. Revoke the old key at the provider.

Rotate when: someone with manage_options leaves, a database dump went somewhere untrusted, a key appeared in a screenshot or a support ticket, or you see usage you cannot account for.

Restricted keys#

Where the provider supports it, use restricted keys:

  • OpenAI project keys scoped to specific models and spend
  • AWS IAM users with PutObject on one bucket only
  • Google Cloud keys restricted by API and by referrer or IP

A key that can only do what this plugin needs limits the damage if it leaks.

Provider-side spend caps#

Set a monthly cap in every provider dashboard.

This is the only control that a plugin misconfiguration, a compromised WordPress account or an abused public endpoint cannot bypass. Set it before anything else.

Other secrets#

SecretWhere
REST API keys and bearer tokensaiomatic_Main_Settings
MCP bearer tokenaiomatic_mcp_settings
Webhook secretsRule and block configuration
The licence purchase code<plugin_slug>_registration
Cloud storage keysaiomatic_Main_Settings

All are plain text and all deserve the same treatment: long random values, rotated when exposed.

Never do these#

  • Paste a key into a support ticket, a forum or a screenshot. Rotate it immediately if you do.
  • Commit wp-config.php with keys to a repository.
  • Reuse one key across sites. One compromise then affects all of them.
  • Give manage_options casually. It is read access to every credential.

Still stuck? Open a support ticket and include the diagnostics from Aimogen Pro › System & Logs › System Info.