This rule detects the creation of a Kubernetes service account token via the TokenRequest API by a non-system identity. The TokenRequest API lets users and workloads programmatically issue short-lived tokens for service accounts they have create permissions on, without reading the filesystem or using mounted tokens. Abuse scenarios include minting tokens for more privileged service accounts, pivoting to cloud provider resources through IRSA/workload identity, or generating longer-lived tokens that persist beyond pod termination. Tokens created via TokenRequest leave no filesystem footprint and are only observable in Kubernetes audit logs as a create verb on the serviceaccounts/token subresource. Legitimate system components (e.g., kubelet, kube-controller-manager) and cloud-provider managed identities are excluded from triggering alerts. The rule filters audit events to catch creates on serviceaccounts/token by non-system principals, while excluding known benign system identities. When triggered, it supports triage of the actor, origin, and target: actor identity and source (user.name, kubernetes.audit.user.username, kubernetes.audit.sourceIPs, user_agent), cloud identity fields (kubernetes.audit.user.extra.*), and the targeted service account (kubernetes.audit.objectRef.namespace/name) and request URI. It also prompts validation of the RBAC permission that allows create on serviceaccounts/token and checks for follow-on activity from the same actor (secret reads, pod exec, RBAC changes, or cloud API calls). Remediation includes revoking the TokenRequest permission, rotating credentials, and, in IRSA/workload identity cases, rotating cloud role sessions and reviewing cloud audit logs for related activity.