Skip to content
ReleasesGitHub

Test and debug your integration

After you integrate your application through any of the integration paths, follow the steps on this page to verify that credentials flow end to end. A working integration means Aembit authorizes the request, your application receives a valid credential, and the target Server Workload: Server Workloads represent target services, APIs, databases, or applications that receive and respond to access requests from Client Workloads.Learn more accepts it.

Whichever path you chose, your Aembit Tenant: Aembit Tenants serve as isolated, dedicated environments within Aembit that provide complete separation of administrative domains and security configurations.Learn more records the full authorization flow for every access request that reaches it, so verification starts in the Tenant and ends at your application. Each path also produces its own local evidence, which the per-path sections on this page cover.

Check authorization events in your Aembit Tenant

Section titled “Check authorization events in your Aembit Tenant”

Every integration path produces the same authorization events in your Aembit Tenant, so check them first when access fails. To view them, click Reporting in the left sidebar of your Tenant, which displays the Access Authorization Events page. The events trace each request through four event types: Access Request, Access Authorization, Access Discovery, and Access Credential.

Each authorization event records the identified 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, Server Workload, and whether Aembit granted or denied access, together with the reason for a denial.

A denial reason such as an attestation failure tells you the 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, the 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, or another Access Policy component is the problem rather than your code. See Access Authorization Events for each event type, its fields, and worked failure examples.

Verify credential delivery

Section titled “Verify credential delivery”

The verification steps differ by path, because each path puts the credential-handling logic in a different place. Select your integration path:

Agent Proxy intercepts your application’s requests transparently, so verify that the interception happened and that the injected credential worked.

  1. Check the Agent Proxy logs for credential events, which confirm Agent Proxy intercepts your application’s requests.

    Linux (systemd)
    sudo journalctl --namespace aembit_agent_proxy | grep -i "credential"
    Kubernetes
    # Standalone deployment
    kubectl logs <agent-proxy-pod> -n <namespace> -f
    

    # Sidecar injection (Agent Proxy runs as a container in your application pod)
    kubectl logs <pod> -n <namespace> -c aembit-agent-proxy -f

    Log lines that reference GetCredentials, credential injection, or authentication confirm the interception. Check the Agent Proxy logs specifically, because the Agent Controller logs cover registration and Access Policy sync rather than credential interception.

  2. Confirm your application receives a valid credential by logging the result of its normal authentication call. For example, an application that requests an OAuth token logs the intercepted request’s result:

    token_response = requests.post(
        'https://oauth-provider.com/token',
        data={
            'grant_type': 'client_credentials',
            'client_id': 'your-app-id',
            'client_secret': 'placeholder-client-secret',  # Aembit replaces this
            'scope': 'api.read'
        }
    )
    

    if token_response.ok:
        logger.info("Received access token, expires in %s seconds", token_response.json().get('expires_in'))
    else:
        logger.error("Token request failed: %s", token_response.text)

    A valid access token, an API response in the 200-299 range, or an established database connection confirms delivery, depending on your target service.

  3. Confirm the target service accepts the credential by calling a protected resource. A response in the 200-299 range with no 401 Unauthorized or 403 Forbidden errors completes the verification.

Troubleshoot common failures

Section titled “Troubleshoot common failures”

The most common failures also differ by path. Select your integration path:

  • Your client library reports invalid credentials - Verify Agent Proxy is running with systemctl status aembit_agent_proxy, check its logs for interception activity, and confirm the Access Policy is active and correctly configured.
  • The placeholder value appears in the target service’s logs - The interception isn’t happening, so verify the HTTP_PROXY environment variables for proxy-based interception and configure TLS Decrypt for HTTPS targets.
  • The application works locally but fails when deployed - Confirm the deployed environment doesn’t set the real secret in an environment variable, runs Agent Proxy and Agent Controller, and can reach Aembit Cloud: Aembit Cloud serves as both the central control plane and management plane, making authorization decisions, evaluating policies, coordinating credential issuance, and providing administrative interfaces for configuration.Learn more.
Section titled “Related resources”