Skip to content
ReleasesGitHub

Local development

For local development, you have three options to get credentials from Aembit, and they differ in how close each one is to your production setup.

Option 1: Aembit CLI credential injection

Section titled “Option 1: Aembit CLI credential injection”

Use the Aembit CLI to retrieve credentials and inject them into environment variables. This is useful for local development without running the full Agent infrastructure.

Terminal window
# Get credentials and export to environment variable
export MY_API_KEY=$(aembit credentials get \
  --server-workload-host api.example.com \
  --server-workload-port 443 \
  --client-id YOUR_CLIENT_ID)


# Run your application with the credential
python my_app.py

The CLI authenticates through a Trust Provider: Trust Providers validate Client Workload identities through workload attestation, verifying identity claims from the workload's runtime environment rather than relying on pre-shared secrets.Learn more and needs the Edge SDK Client ID: A structured identifier that Aembit generates when you configure a Trust Provider, encoding your region, tenant, and Trust Provider. It identifies a Trust Provider rather than an individual Client Workload.Learn more from that Trust Provider, so check the supported Trust Providers before you start. See Getting credentials with Aembit CLI for detailed setup instructions.

Option 2: Run Aembit Agent Proxy locally

Section titled “Option 2: Run Aembit Agent Proxy locally”

Install and run both Aembit Agent Controller and Agent Proxy on your development machine for end-to-end credential injection that matches production behavior. This is the highest-fidelity option when your deployed workload integrates through Agent Proxy.

Set up a local Agent Proxy

Section titled “Set up a local Agent Proxy”

  1. Install Agent Controller and Agent Proxy on your development machine, following About Agent Controller.

  2. Configure Agent Proxy to connect to your Aembit Tenant: Aembit Tenants serve as isolated, dedicated environments within Aembit that provide complete separation of administrative domains and security configurations.Learn more.

  3. In your Aembit Tenant, create the Access Policy components that authorize your local application:

    • A Server Workload: Server Workloads represent target services, APIs, databases, or applications that receive and respond to access requests from Client Workloads.Learn more that represents the target service
    • A Client Workload: Client Workloads represent software applications, scripts, or automated processes that initiate access requests to Server Workloads, operating autonomously without direct user interaction.Learn more that identifies your local application
    • A Trust Provider that can verify your development machine’s identity evidence
    • A Credential Provider: Credential Providers obtain the specific access credentials—such as API keys, OAuth tokens, or temporary cloud credentials—that Client Workloads need to authenticate to Server Workloads.Learn more that supplies the credential for the target

  4. Create and activate an Access Policy: Access Policies define, enforce, and audit access between Client and Server Workloads by cryptographically verifying workload identity and contextual factors rather than relying on static secrets.Learn more that ties the components together, following Create an Access Policy, because Aembit injects a credential only when an active Access Policy permits the access.

  5. Run your application locally, and Agent Proxy intercepts its traffic as it does in production.

Option 3: Call the Edge SDK from your application

Section titled “Option 3: Call the Edge SDK from your application”

If your application uses an Edge SDK, the same code runs on your development machine, because the SDK retrieves credentials in-process without any local Aembit components. The SDK authenticates with identity evidence from the environment it runs in. Your development machine therefore needs to present evidence that a Trust Provider you configured can verify, the same requirement the CLI has. See the Edge API authentication contexts for the evidence each environment provides, and the SDK repository for language-specific setup and runnable examples.

Section titled “Related resources”