fix: Enable incident graph correlation with anti-spam protection

[emooreatx]

Summary

• Fixed dead code: IncidentCaptureHandler._save_incident_to_graph() was never called - incidents went to file only, never to graph
• Added anti-spam protection: Rate limiting (50/min) and deduplication (30s window) prevent graph flood during error cascades
• Aligned with FSD: Now uses MemoryBus.memorize_log() which creates LOG_ENTRY correlations per CORRELATIONS_TSDB design
• CRITICAL bypass: Critical errors always go through immediately, bypassing rate limits

Changes

File	Change
incident_capture_handler.py	Add rate limiting, deduplication, _write_to_graph() using memorize_log()
test_incident_capture_handler.py	Add tests for rate limiting, deduplication, graph writing

Anti-Spam Patterns Used

Reused existing patterns from ciris_engine/logic/telemetry/security.py:

• Rate limiting: Deque with sliding window (like SecurityFilter._check_rate_limit)
• Fire-and-forget: asyncio.create_task() with add_done_callback cleanup

Test plan

• All 25 tests pass
• Rate limiting allows N items per period, then blocks
• Deduplication blocks same error within window
• CRITICAL bypasses rate limit
• _write_to_graph() calls memorize_log() correctly
• Memory bus injection works via both set_memory_bus() and set_graph_audit_service()

🤖 Generated with Claude Code

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.
To continue using code reviews, you can upgrade your account or add credits to your account and enable them for code reviews in your settings.

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ emooreatx
❌ google-labs-jules[bot]
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[cla-assistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ emooreatx
❌ google-labs-jules[bot]
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

To fix this error, avoid logging data that may have originated from potentially sensitive user input during interactive setup, especially anything that could plausibly include API keys, secrets, passwords, or tokens. In the indicated log line at create_env_file, the information logged is the LLM provider and base URL. While these are less likely to be sensitive, user input for "base URL" could technically include a secret if mis-pasted, or practices might change in the future. Therefore, the best solution is to remove or strictly limit this logging statement, ensuring no user input is written directly to logs. Specifically, remove or sanitize the log line at line 132 in create_env_file. No other code changes or imports are required.

To remediate the risk of clear-text logging of sensitive information, we should ensure that no part of the API key (old or new) is logged, even in truncated form. In update_api_key, we should avoid computing or passing old_key_preview and new_key_preview, and omit them from the logger.info statement. Instead, the log should state that the API key was updated and the circuit breaker reset, along with the state of the circuit breaker, but without including any (even partial) API key data. Only safe, non-sensitive metadata should be logged.
What to change:

• In update_api_key, lines 202–225:
  • Remove creation and logging of old_key_preview and new_key_preview (old_key_preview, new_key_preview)
  • Edit the relevant logger.info call so the log message omits both previews and only logs non-sensitive data (e.g., the fact the key changed, and the circuit breaker state).
  • Ensure that the rest of the function is unchanged.

No new imports or methods are required; only logging statements need to be made safer.

The correct fix is to ensure that API keys are never written to the logs, not even partially masked or previewed. To maintain some ability to distinguish which key was replaced (if absolutely needed), log only non-sensitive distinguishing information such as "***" or "REDACTED" for both old and new key. Remove the previews completely. Only generic log statements should indicate that the key was updated; never log any characters of the credentials themselves.

Implement this by:

• Removing the old_key_preview and new_key_preview variables and their usage in the logger call.
• Replace the log line so that, instead of interpolating the key preview values, it either logs "REDACTED" or omits the old/new key from the log message entirely.
• Only the circuit breaker state is logged, since it's not sensitive information.

Edit can be made directly at lines 202–227 of ciris_engine/logic/services/runtime/llm_service/service.py in the update_api_key method.

No new imports or dependencies are needed.

---

To fix the issue, we should not write sensitive information in clear-text to the .env file. There are two general approaches:

1. Encrypt the sensitive value before writing, and require the application to be able to decrypt it when it needs to use it (providing a decryption key at runtime via environment variable, secret manager, etc).
2. Omit the sensitive information from the config file entirely, requiring the operator to place it securely elsewhere (such as a secure environment variable manager, etc).

To preserve current functionality with minimal disruption, we will encrypt the API key value before writing it to the config file, using the standard cryptography library (Fernet symmetric encryption). This requires adding an import, ensuring there is an encryption key (which can be generated and stored separately or provided as an argument), and updating both the storing and (eventually) retrieval logic to deal with decryption.

Within the shown code, all relevant logic is in the _save_setup_config function (line 814 onwards). We'll:

• Add a Fernet key loading/generation function, or use an existing one if present (generate_encryption_key is imported; perhaps it's relevant).
• Encrypt setup.backup_llm_api_key before writing.
• Prefix/write the encrypted value clearly (e.g. ENCRYPTED:) to make decryption straightforward.
• Ensure the encryption key is not stored side-by-side with the file.

This requires:

• Adding the necessary from cryptography.fernet import Fernet import.
• Ensuring we have a Fernet key from the environment or available config.
• Encrypting/encoding the API key before writing.

---

The best fix is to ensure that the log on lines 641–648 does not leak any sensitive information. Specifically, avoid logging values that include or would reveal:

• OAuth provider identifiers (as these may uniquely identify users or partners)
• OAuth external IDs or any user identifier (wa_id, external_id)
• Anything related directly to specific tokens or emails

Instead, only log non-sensitive, non-identifying metadata: e.g., whether certain required fields are present (not their values), what optional parameters are included (as booleans), or simply the fact that a request is being made with certain limits/offsets.
Thus, alter the log message to redact the values or log only the presence/status of required fields rather than their values. Make the new log message explicit that it avoids sensitive content, as was already being done for emails but not for the other fields.

Regions to change:
Within ciris_engine/logic/adapters/api/routes/billing.py, replace only the debug log on lines 641–648.
No import changes are required.
No need for new methods/definitions.

---

To fix this, we should prevent logging of the entire user_identity object, which contains potentially sensitive fields. Instead, only log non-sensitive, high-level diagnostic information (such as agent ID, and maybe only some flags or anonymized/boolean status information from user_identity if really needed). We should not include fields like external_id, customer_email, or wa_id (the original user ID), as these can all be used to identify a user. The logger call should be changed to only log allowed, non-sensitive information.

We will replace:

logger.info("[BILLING_API] agent_id=%s, user_identity=%s", agent_id, user_identity)

with something like:

logger.info(
    "[BILLING_API] agent_id=%s, has_oauth_provider=%s, has_external_id=%s, user_role=%s, marketing_opt_in=%s",
    agent_id,
    user_identity["oauth_provider"] is not None,
    user_identity["external_id"] is not None,
    user_identity["user_role"],
    user_identity["marketing_opt_in"],
)

That way, sensitive fields are not logged, but useful diagnostic information is retained. No new imports or dependencies are required; only this single log statement needs updating.

Sensitive user data, such as email addresses and possibly user IDs, must not be logged in cleartext. The best fix is to remove these values from the log message or to redact/mask them. If it is helpful to retain record linkage for debugging, use anonymized versions (e.g., the hash of the email/user_id) or redact most of the value (e.g., only the domain of the email or a partial user ID). In this case, the simplest and safest fix is to remove both {user_email} and possibly {oauth_user.user_id} from the log message. Alternatively, mask part of the email (e.g., show: "e***@domain.com"**) or the user ID (e.g., show only the last 4 characters), depending on requirements.

Implement the fix in file ciris_engine/logic/adapters/api/routes/auth.py, on the lines containing the logging statement (~lines 964–968).

• Remove {user_email} from the log message and argument list.
• Optionally, redact/mask or remove {oauth_user.user_id}; for the most privacy, remove it.
• Retain only non-sensitive data in the log message (e.g., has_credit, marketing_opt_in, role, provider).

No new imports or methods are required if just omitting fields.
If masking is required, add a small utility function for masking emails/user IDs.

---

The best fix is to ensure redirect targets are always either:

1. a trusted configured frontend URL, or
2. a safe local relative path whose dynamic parts are sanitized to a strict allowlist.

For this file, the most direct non-breaking fix is:

• In _build_redirect_response, sanitize provider before using it in gui_callback_url (fallback branch).
• Build gui_callback_url only from safe characters (e.g., [A-Za-z0-9_-]) and fall back to a constant if invalid.
• URL-encode dynamic query values (email, etc.) via standard library urlencode so tainted values cannot alter URL structure.
• Keep behavior intact: still redirect to configured frontend when present; still support relative fallback path.

Edits needed in ciris_engine/logic/adapters/api/routes/auth.py:

• Add standard library imports: re and urlencode from urllib.parse.
• In _build_redirect_response, sanitize provider with re.fullmatch(...) before interpolation in fallback path.
• Use the sanitized provider in gui_callback_url.