This new-terms rule detects the first successful secrets.get operation by a pod service account in Google Kubernetes Engine (GKE) when the request originates from a previously unseen combination of service-account identity, client user agent, and source IP. It ingests GCP audit logs (gcp.audit) and targets events where a system:serviceaccount:* identity performs secrets.get (io.k8s.core.v1.secrets.get) with event.outcome: success, restricting to a Kubernetes workload context. The rule maintains a history window (now-7d) and flags a new triple consisting of client.user.email, user_agent.original, and source.ip as a potential anomaly. When such a first-seen combination appears, an alert is generated, mapping to MITRE ATT&CK technique T1552 (Unsecured Credentials), subtechnique T1552.007 (Container API), under the Credential Access tactic. The rule helps detect token misuse or exfiltration where a token is used from an unusual host or via an unfamiliar client (e.g., curl, kubectl, or custom scripts). The alert is intended to prompt credential rotation and RBAC tightening if malicious activity is confirmed. Setup requires the GCP Fleet integration with GKE audit logs enabled. Potential investigations include verifying whether the user agent is expected for the service account, reviewing gcp.audit.resource_name and namespace scope against secret mounts and RBAC, and correlating with recent deployments or operator upgrades that could legitimately alter client strings. The rule emphasizes that early legitimate changes (e.g., upgrades) may temporarily produce first-seen events and should be evaluated in context.