What counts as credentials in user input?

Password-like key-value pairs (password=, api_key=), bearer tokens, vendor API keys, cloud access keys, private key blocks, and similar authentication material—not standalone emails unless paired with secrets.

Should login form passwords go through LLM scanning?

No. Credential detection targets accidental paste in general-purpose chat or text fields. Standard login endpoints should use TLS and hashed storage, isolated from LLM logging middleware.

What API category covers password= assignments?

The credential_pair category flags key-value patterns such as password=, api_key=, token=, and secret= followed by values meeting length thresholds.

How do I reduce false positives on credential detection?

Tune policies for instructional documentation, combine patterns with entropy checks, allowlist known safe origins for internal tools where appropriate, and route ambiguous cases to human review instead of the model.

How to Detect Credentials in User Input

Detecting credentials in user input means scanning free-form text—chat messages, form fields, support tickets, and file uploads—for usernames paired with passwords, API keys, bearer tokens, and other authentication material before that input is stored, logged, forwarded to an LLM, or displayed back to other users. Credential detection differs from generic PII scanning because exposed secrets often require immediate rotation and hard blocking rather than redaction alone, and because users frequently paste .env snippets or curl commands without realizing the security impact.

What "credentials in user input" includes

Production detectors typically flag:

Pattern	Synthetic example	Category
Key-value secrets	`password=SuperSecretExample123!`	`credential_pair`
API key assignments	`api_key=sk-test_notrealvalue1234567890`	`credential_pair`
Bearer tokens	`Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.test`	`bearer_token`
Vendor API keys	`sk-test_abcdefghijklmnopqrstuvwxyz123456`	`stripe_key`
Cloud access keys	`AKIA0000000000000000`	`aws_access_key`
Private keys	PEM blocks starting with `-----BEGIN PRIVATE KEY-----`	`private_key`

Usernames and emails alone (user@example.com) are usually PII (suspicious verdict), not credentials—unless paired with passwords in the same message.

Deep dives: Secrets Detection for LLM Applications, How to Detect Private Keys and Tokens in Text.

Why scan before storage and LLM forwarding

User input becomes durable quickly:

Database rows — Support tickets, feedback forms
Search indexes — Full-text search over conversations
Log streams — ELK, Datadog, CloudWatch with body logging enabled
LLM context — Provider-side retention depending on settings
Admin dashboards — Support staff view raw messages

Scanning at ingress lets you reject or sanitize before those systems copy the data. See LLM Data Leakage for downstream paths.

API workflow with IdenticAPI

Use PII & Secrets Detection:

POST /api/v1/security/pii-secrets

{
  "text": "Login: admin@example.com password=ExamplePassw0rd!123",
  "redact": false
}

Example response:

{
  "verdict": "unsafe",
  "risk": "high",
  "findings": [
    {
      "category": "email",
      "reason": "Detected email (pii)",
      "confidence": 0.95
    },
    {
      "category": "credential_pair",
      "reason": "Detected credential pair (secret)",
      "confidence": 0.8
    }
  ],
  "reasons": [
    "Detected email (pii)",
    "Detected credential pair (secret)"
  ]
}

Recommended actions when credential_pair or other secret categories appear:

Block submission to LLM and persistent storage (or store redacted version only)
Return user-facing guidance without echoing the secret
Log request_id and categories only
Do not use the LLM to "validate" whether the password is correct

For PII-only findings, consider "redact": true:

{
  "text": "Reset password for user@example.com",
  "redact": true
}

Documentation: PII & Secrets Detection docs. Try the PII Checker.

UX patterns that reduce credential paste

Technical detection works better when the UI discourages risky behavior:

Never ask for passwords in chat — Use SSO or magic links
Mask password fields — Standard form hygiene
Upload restrictions — Block .env, .pem, id_rsa uploads in generic document chat
Paste warnings — If a code block is detected, show "Remove secrets before sending"
Separate "share code" flow — Static analysis on pasted code before LLM review

Handling false positives

Credential regexes may match instructional text:

Set password=YourSecurePasswordHere in the config docs.

Tune policies:

Require minimum entropy on captured values
Combine credential_pair with adjacent keywords in high-confidence rules
Allowlist internal documentation origins for employee tools (still risky for LLM forwarding)

When ambiguous, route to human review instead of automatic LLM processing.

Server-side vs client-side detection

Approach	Pros	Cons
Client-side	Instant feedback	Bypassable via API calls
Server-side	Authoritative	Slight latency
Both	Best UX + security	Duplicate logic unless shared API

Always enforce server-side before LLM calls. Client checks are convenience only.

Integration with authentication flows

Do not send login forms through LLM preprocessors designed for chat. Credential detection targets ** accidental** paste in general-purpose text areas—not password login endpoints protected by TLS and hashed storage.

If your product mixes auth and chat, isolate routes so login traffic never hits LLM logging middleware.

Synthetic test cases

Input	Expected finding	Verdict
`token=abc123short`	May skip (length thresholds)	varies
`api_key=sk-test_abcdefghijklmnopqrstuvwxyz123456`	`credential_pair`, `stripe_key`	`unsafe`
`My email is user@example.com`	`email`	`suspicious`
`Hello world`	none	`safe`

Automate these in CI against staging keys.

Limitations

Cannot detect credentials split across multiple messages with manual obfuscation
Key-value patterns miss secrets embedded only in binary files
Detection does not trigger automatic rotation—you need runbooks
Legitimate penetration test reports may trigger blocks—define exception workflows

Pair detection with PII and Secrets Leakage Checklist reviews.