---
name: bill-kotlin-code-review-security
description: Use when reviewing secrets handling, auth/session safety, sensitive data exposure, and transport/storage security in Kotlin code. Use when user mentions secrets, auth tokens, encryption, sensitive data, or security review in Kotlin code.
---

# Security Review Specialist

Review only exploitable or compliance-relevant issues.

## Focus
- Secret leakage (keys/tokens/credentials)
- Auth/authz logic gaps and session/token misuse
- Sensitive logging (PII/token leakage)
- Insecure storage/transport assumptions
- Security regressions from new code paths

## Ignore
- Non-security style comments

## Applicability

Use this specialist for shared security risks across Kotlin libraries, app layers, and backend services. Favor issues that stay security-relevant regardless of platform; leave transport- or UI-specific nuances to route-specific specialists.
## Project-Specific Rules

### Shared Kotlin Security
- No secrets, tokens, passwords, or private keys in code, logs, tests, or repo config
- Sensitive identifiers and personal data must not be logged or exposed without explicit need and protection
- New code paths must preserve auth/authz guarantees and avoid bypassable feature-flag checks
- Enforce authn/authz at trusted boundaries; do not trust caller-supplied role, tenant, or actor identifiers without verification
- Secrets/config must come from env vars, vaults, or secure local config excluded from version control
- Do not expose stack traces, internal exception messages, or other sensitive failure details to untrusted callers
- Avoid logging raw auth headers, session cookies, full request bodies, or other high-risk payloads without explicit redaction
- Verify authenticity and integrity checks for new external entry points, signed callbacks, or inter-service trust boundaries
- Verify that sensitive stored data receives the protection level the contract or platform requires
- For Major or Blocker findings, describe the abuse or exploit scenario explicitly.
