Overview
Establish the product, identity, zone, target, and secret boundaries before any live collection. Native proxy clients use a zone username/password, while REST API clients use a named-user API key; treat them as different credentials with different blast radii.
Prerequisites
- An approved public-data purpose and target allowlist
- A Bright Data account owner who can grant only the required product and zone
- A secret manager and a non-production validation environment
Instructions
Step 1: Inventory the access path
Read the integration and Grep for existing Bright Data hosts, environment names, and secret references. Classify each call as native proxy, Browser API, or REST API before choosing credentials.
Step 2: Define the secret contract
Write an example-only configuration that declares names but contains no values.
BRIGHTDATA_API_KEY=
BRIGHTDATA_PROXY_USERNAME=
BRIGHTDATA_PROXY_PASSWORD=
BRIGHTDATA_ZONE=
Step 3: Bind ownership
Record the named owner, permitted zone, approved target classes, expiry or review condition, and revocation path. Do not reuse an account-wide API key when a zone credential is sufficient.
Step 4: Validate without disclosure
Use Bash(python:*) only to check that required names are present and mutually consistent; never print values. Run one separately approved smoke test through the product-specific workflow.
Tool Discipline
Use Read and Grep to inventory existing access. Use Write and Edit only for approved example, configuration, and runbook paths. Use Bash(python:*) for local presence/schema checks that never print secret values; this skill does not authorize a live request.
Output
- Credential-mode decision: native proxy or REST API
- Named secret bindings, owner, scope, and revocation receipt
- An approved smoke-test handoff with no credential material
Examples
For a Web Scraper API worker, bind one named-user API key in the deployment secret manager and keep proxy username/password variables absent. For a Playwright proxy client, bind only the approved zone credentials. Stop if the product or target authorization is ambiguous.
Error Handling
| Failure | Meaning | Response |
|---|---|---|
| Both credential modes are populated | Integration boundaries are mixed | Split the clients and remove unused secrets |
| Zone is inactive or missing | Wrong account, spelling, or entitlement | Have the account owner verify the zone; do not broaden access |
| Secret appears in logs | Unsafe diagnostics or command construction | Revoke it, scrub retained output, and correct the logging path |