Credential encryption

How WP-PFAgent stores LLM API keys and other secrets at rest.

What we encrypt

LLM API keys (the full value).
OAuth client secrets.
Per-credential connection tokens.

How

Algorithm: AES-256-GCM, the standard for authenticated symmetric encryption. Integrity-protected — any tampering with the ciphertext is detected and the value refuses to decrypt.
Encryption key: derived from your WordPress installation's secret salts (the same constants WordPress itself uses to protect logged-in sessions). If your wp-config.php salts are strong, your credentials are too.
IV: a fresh random value per encrypted record. Stored alongside the ciphertext.

What we do NOT store encrypted

Some metadata is intentionally readable so it can be queried and displayed without unlocking the secret:

The provider id and preset name (needed to look the credential up).
A masked tail of the key (last 4 characters, for the UI: sk-...xyz1).
Model IDs, pricing, and health status (not secret).

Operational handling

API keys are never written to log files by the plugin.
API keys are never sent in trace data or telemetry.
When a chat message would echo a key (e.g. you paste one), it is scrubbed before being persisted to the conversation log.
Exports (workflow JSON, support bundles) never include decrypted credential values.

Key rotation

If your WordPress salts change (operator decision, or a security incident response), existing credentials cannot be decrypted any more. The plugin detects this and marks the credential as failed in the admin UI — you simply re-enter the API key to re-encrypt it under the new salts.

What this gives you

A stolen database dump alone does not yield usable API keys; the attacker would also need wp-config.php (or whichever environment secret store the salts come from). Defense in depth: keep your filesystem and your database under separate access boundaries.
Day-to-day, the encryption is transparent — saved keys are reusable across requests until you change them.