---

name: brightdata-install-auth description: 'Bootstrap Bright Data access without mixing proxy-zone credentials and REST API keys. Use when onboarding an integration, changing credential ownership, or proving least-privilege access. Trigger with: "set up Bright Data access", "configure a Bright Data zone", "separate proxy and API credentials".' allowed-tools: Read, Grep, Write, Edit, Bash(python:*) version: 2.0.0 argument-hint: "[integration-root]" model: inherit effort: high license: MIT author: Jeremy Longshore jeremy@intentsolutions.io tags:

• saas
• web-data
• bright-data
• install-auth
• operations compatibility: 'Requires an approved Bright Data account or offline fixtures, current Bright Data documentation, and an authorized public-data collection purpose'

---

Bright Data Access Bootstrap

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

Resources

• Authentication and API keys
• Proxy API authentication
• Users management
• Acceptable use policy