Integrate through Agent Proxy

Agent Proxy intercepts your application’s outbound requests. Before each request reaches the target Server WorkloadServer Workload: Server Workloads represent target services, APIs, databases, or applications that receive and respond to access requests from Client Workloads.Learn more, Agent Proxy injects the credential the request needs. The integration work therefore lives in your infrastructure and your Aembit configuration, and your application code changes only where a client library demands a credential value. This page walks you through the developer-side work: supply a placeholder credential where a library requires one, then send a request and verify the credential arrived. For the other ways to integrate, see the Developer Guide overview.

Prerequisites

Complete both prerequisites before changing application code, because Agent Proxy only injects a credential that an Access PolicyAccess 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 authorizes:

• Deploy Agent Proxy in the environment where your application runs.
• Create an Access Policy that authorizes your Client WorkloadClient 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 to reach the target Server Workload, with a Trust ProviderTrust 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 a Credential ProviderCredential 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 attached. You can create the Access Policy in the Tenant UI of your Aembit TenantAembit Tenant: Aembit Tenants serve as isolated, dedicated environments within Aembit that provide complete separation of administrative domains and security configurations.Learn more, through the Cloud API, or with the Terraform provider, and Manage your Aembit configuration compares the three paths.

Add a placeholder credential

Many client libraries refuse to initialize without a credential value, even though Aembit supplies the real credential at request time. Give such a library a placeholder credential, which is any non-empty string that passes the library’s validation, such as 'placeholder-client-secret'. Agent Proxy replaces the placeholder with the real credential in transit, so the placeholder never reaches the target service.

from some_oauth_library import OAuthClient

# Initialize with a placeholder - Aembit replaces it in transit
client = OAuthClient(
    client_id='your-client-id',
    client_secret='placeholder-client-secret',
    token_url='https://oauth-provider.com/token'
)

Some libraries attach the credential per request instead of at initialization, such as an API key in a header. In that case you may have no code change at all, because Agent Proxy adds the header for you. Client library patterns for Agent Proxy shows where the placeholder goes for OAuth SDKs, API key headers, and database drivers, and links the official SDK documentation for common services.

Send a request and verify

1. Run your application in the environment where you deployed Agent Proxy.

2. Make a request to the target Server Workload.

3. Confirm the request succeeded, then check the authorization event in your Aembit Tenant.

Test and debug your integration covers the verification end to end, including authorization events, credential delivery checks, and the common failure modes.

How the credential reaches the service

The Server Workload’s configured authentication method and scheme determine how Agent Proxy attaches the injected credential to your request. The credential can arrive as an Authorization header, a named header, a query parameter, a protocol-level password, or a certificate in the TLS handshake. Knowing the configured combination tells you what the target service receives, which is what you compare against when the target rejects a request. For choosing and configuring a combination in your Aembit Tenant, see Authentication methods and schemes.

Most methods inject credentials into the application protocol. mTLS Authentication presents the credential during the TLS handshake, beneath the application protocol.

The following table lists all supported combinations of authentication methods and schemes, along with their compatible application protocols and credential providers:

Auth Method	Auth Scheme	Application Protocols	Credential Provider	Description	Specification
HTTP Authentication	Basic	HTTP	Username & Password	Encodes username:password in Base64 and sends it in the HTTP Authorization header.	The ‘Basic’ HTTP Authentication Scheme
HTTP Authentication	Bearer	HTTP	Any single-value	Sends a Bearer token in the HTTP Authorization header.	Bearer Token Usage
HTTP Authentication	Header	HTTP	Any single-value	Injects credentials into a user-defined HTTP header as part of HTTP authentication flow.	n/a
HTTP Authentication	AWS Signature v4	HTTP	AWS STS Federation	Signs the HTTP request using AWS Signature v4.	Create a signed AWS API request
API Key	Header	HTTP	Any single-value	Injects API key credentials into a user-defined HTTP header for API-based authentication.	n/a
API Key	Query parameter	HTTP	Any single-value	Injects credentials into a user-defined HTTP query parameter.	n/a
Password Authentication	Password	MySQL, Postgres, Amazon Redshift, Redis	Username & Password	Injects credentials according to protocol-specific requirements. Applies only to protocols with a single auth method.	n/a
JWT Token Authentication	Snowflake JWT	Snowflake	JWT	Modifies the body of an HTTP request to /session/v1/login-request, injecting USERNAME and TOKEN.	n/a
mTLS Authentication	x509 Certificate	HTTP	X.509-SVID	Authenticates an Access Policy’s Client Workload and Server Workload using a SPIFFESPIFFE: Secure Production Identity Framework For Everyone (SPIFFE) is an open standard for workload identity that provides cryptographically verifiable identities to services without relying on shared secrets.Learn more(opens in new tab)-compliant X.509-SVIDX.509-SVID: A SPIFFE Verifiable Identity Document in X.509 certificate format. X.509-SVIDs are certificates that embed a workload's SPIFFE ID as a URI Subject Alternative Name (SAN) and enable mutual TLS authentication between workloads. Aembit issues SVIDS with short lifetimes and automatic rotation.Learn more certificate that Agent Proxy presents during the mTLS handshake.	SPIFFE X.509-SVID Standard

Agent Proxy can also add static HTTP headers

A Server Workload can define static HTTP headers, which are name and value pairs that Agent Proxy adds to every HTTP request it forwards to that workload. If your request already carries a header with the same name, the static value replaces it, so check the Server Workload definition before debugging an unexpected header value. See About static HTTP headers.

Next steps

• Client library patterns for Agent Proxy - Placeholder placement for each library type, plus service-specific SDK resources
• Test and debug your integration - Verify interception, credential delivery, and access end to end
• Local development - Get credentials while developing on your own machine
• Server Workload guides - Service-specific configuration