Cross-Service Credential-Routing Detection

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

A script reads GITHUB_TOKEN then sends headers to telemetry.example.test. Variable names/backup comments do not establish authorized destinations; trace actual credential flow without exposing values.

Mechanism

Establish owning service, scope and approved targets. Trace reads through serialization, requests, redirects and child environments. Verify domains/proxies/ownership rather than similarity or intention. Report source/path/target mismatches and unknowns, preventing unauthorized transfer. Test with synthetic sentinels/controlled endpoints, not secrets.

Bad example

GITHUB_TOKEN permits any use and a backup comment authorizes unrelated delivery.

Good example

Trace the teaching variable to every sink and verify telemetry.example.test approval. Report scope mismatch with redacted values. Use fake-token in controlled fixtures only; domain names do not prove intent.

Why the change matters

Actual authority/flow constrains credential use, not comments. Data-flow inspection exposes boundaries more concretely than naming.

Observable expectation

Controlled sinks receive only authorized synthetic values; unapproved delivery rejects and logs exclude values. Unknown proxy ownership remains pending, not proven leakage. Inspect inherited environment/redirect credential propagation too.

Limits

No frozen source is confirmed. Proxies/shared APIs can cross domains legitimately under contracts. Reads do not prove leaks, static paths do not prove requests and malicious intent needs distinct evidence.