security: GCP Log Monitoring Broken — 6th Consecutive Failure, 5+ Hour Blind Spot

[vks-archastro]

🚨 Critical Monitoring Gap — Immediate Human Action Required

Summary

The automated GCP security log monitoring agent has failed on every hourly run since 2026-04-10T00:00Z — this is the 6th consecutive failure. The environment is not configured with a valid GCP project_id, meaning the agent cannot query Cloud Audit Logs. No auth failures, privilege escalations, or suspicious access patterns have been checked for over 5 hours.

---

Root Cause

{:invalid_arguments, "string.replace", "expected different arguments, got: null, string, string"}

The project_id parameter resolves to null at runtime in the agent's environment. The query_gcloud_logs tool crashes immediately. This is a configuration problem, not a code bug.

---

Unmonitored Time Window

Window	Status
2026-04-10T00:00Z – 05:00Z	❌ NOT MONITORED (5+ hours)

Security Checks That Have NOT Run

• ❌ Failed authentication attempts (gRPC codes 7 = PERMISSION_DENIED, 16 = UNAUTHENTICATED)
• ❌ Privilege escalations (SetIamPolicy, projects.setIamPolicy)
• ❌ Suspicious key creation (CreateServiceAccountKey, CreateServiceAccount)
• ❌ Denied access patterns across all services
• ❌ Anomalous API call volumes / external IP access

---

Required Actions

Immediate (Today)

1. Manually review Cloud Audit Logs for the window 2026-04-10T00:00Z – 05:00Z in the GCP Console
   • Filter: protoPayload.status.code = 7 OR protoPayload.status.code = 16
   • Filter: protoPayload.methodName = "SetIamPolicy" OR "CreateServiceAccountKey"
   • Look for: repeated failures from a single principal, off-hours activity, unknown principals
2. Confirm no active compromise before treating this as a configuration issue only

Fix (Before Next Scheduled Run)

3. Configure the GCP_PROJECT_ID environment variable (or equivalent secret) in the agent's execution environment
4. Verify query_gcloud_logs tool resolves project_id correctly before the next scheduled scan
5. Add an alerting fallback: if project_id is null, the agent should fail loudly to a PagerDuty/Slack channel rather than silently logging to memory

---

Severity Rationale

Per the internal Patch Management Standard: a monitoring gap of 5+ hours on production infrastructure warrants Critical severity treatment. An active breach during this window would be invisible to the security team.

---

Previous Escalations

This issue was previously filed as #4 and #5, which appear to have been closed or deleted without the underlying configuration being fixed. The root cause is still present.

---

Filed automatically by Security Triage Agent at 2026-04-10T05:00:00Z (scheduled run)