In modern technical environments, applications, services, scripts, and APIs frequently need to communicate with each other and access shared resources like databases, SaaS platforms, or other internal services. These automated systems operating without direct human interaction are Non-Human Identities (NHI) or just workloads.
Use the links in each section to dive deeper into specific topics related to how Aembit works or start configuring and using those features.
The core problem Aembit solves
Section titled “The core problem Aembit solves”Most organizations secure workload access using static, long-lived secrets (API keys, passwords, tokens) that are:
- Difficult to securely distribute and store
- Prone to leakage and theft
- Hard to rotate regularly
- A significant security risk when compromised
Introducing Workload IAM
Section titled “Introducing Workload IAM”Aembit solves these challenges by providing its Workload Identity and Access Management (Workload IAM) platform.
At their core, workload-to-workload interactions involve one workload (Client Workload) initiating a request to access another workload or service (Server Workload). Examples include a microservice calling an API, a script accessing a database, or a CI/CD job deploying to a cloud provider.
Aembit shifts authentication away from what a workload knows (static secrets) to who a workload verifiably is based on its environment and context. Instead of using a traditional password or API key, Aembit verifies a workload’s identity cryptographically using evidence from its runtime environment, such as:
- Where the workload running
- What platform issued the workload’s identity
- Cloud instance metadata
- Kubernetes service account tokens
- SPIFFE Verifiable Identity Documents (SVID)
Client Workloads
Section titled “Client Workloads”Client Workloads are the initiators of requests to access Server Workloads. Client Workloads can be any service, API, or resource that needs to access another service, API, or resource.
More on Client Workloads See Core Concepts
→
Configure Client Workloads See the Aembit User Guide
→
Server Workloads
Section titled “Server Workloads”Server Workloads are the target of Client Workload requests. Server Workloads can be any service, API, or resource that a Client Workload needs to access.
More on Server Workloads See Core Concepts
→
Configure Server Workloads See the Aembit User Guide
→
Secure workloads with Access Policies
Section titled “Secure workloads with Access Policies”Aembit manages workload-to-workload access through Access Policies. Access Policies serve as the central control mechanism to define who (which Client Workload) can access what (which Server Workload) under what conditions. This policy-driven approach replaces the need for Client Workloads to possess static secrets for every service they need to access.
Instead of relying on secrets embedded in the client, Access Policies work by leveraging the inherent identity of the workload. Aembit verifies a Client Workload’s identity from its runtime environment and orchestrates the secure provisioning of necessary credentials just-in-time (JIT) to the Server Workload its trying to access.
Access Policies link a specific Client Workload to a specific Server Workload and define the security checks required for access.
More on Access Policies See Core Concepts
→
Configure Access Policies See the Aembit User Guide
→
The components of an Access Policy include:
- A Client Workload (who wants access)
- A Server Workload (what they want to access)
- A Trust Provider (how to verify the client’s identity)
- Access Conditions (when/where/under what circumstances to allow access)
- A Credential Provider (what credentials to issue)
The following sections briefly describe these key components of an Access Policy:
Trust Providers
Section titled “Trust Providers”Trust Providers are fundamental to Aembit’s “secretless” approach. Trust Providers cryptographically verify the identity of Client Workloads without clients needing a pre-shared secret to authenticate itself to Aembit.
Trust Providers authenticate the workload’s identity by examining verifiable evidence from its environment, such as cloud instance metadata, Kubernetes service account tokens, or OIDC tokens from CI/CD platforms.
Aembit calls this Workload Attestation. If the Trust Provider can’t verify the workload’s identity, Aembit denies access to the Server Workload.
More on Trust Providers See Core Concepts
→
Set up Trust Providers See the Aembit User Guide
→
Once Aembit successfully verifies the identity of a Client Workload through a Trust Provider it goes to the next step in the Access Policy Evaluation flow: Access Conditions.
Access Conditions
Section titled “Access Conditions”Once a Client Workload’s identity is successfully verified by a Trust Provider, Aembit evaluates any Access Conditions you may have defined in the Access Policy. Access Conditions add contextual checks to the access decision. You can enforce rules based on factors like the time of day, geographic location (GeoIP), or even the security posture of the workload’s host derived from integrations with tools like Wiz or CrowdStrike.
All Access Conditions you configure must evaluate successfully for authorization to proceed. This provides a level of dynamic, risk-adaptive security, providing a Multi-Factor Authentication (MFA)-like strength for non-human access.
More on Access Conditions See Core Concepts
→
Set up Access Conditions See the Aembit User Guide
→
Once Aembit successfully verifies the context of a Client Workload through Access Conditions it goes to the next step in the Access Policy Evaluation flow: Credential Provider.
Credential Providers
Section titled “Credential Providers”If a Client Workload’s identity is verified by a Trust Provider and the Client Workload meets all Access Conditions, Aembit then invokes the necessary Credential Provider. The role of the Credential Provider is to obtain the specific access credential required by the target Server Workload.
This could involve interacting with systems like cloud Security Token Services (like AWS STS, Azure WIF, Google WIF), OAuth servers, or internal credential stores to get a short-lived token, API key, or other required secret.
Credential Providers abstract away the complexity of how the target Server Workload expects to authenticate Client Workloads.
More on Credential Providers See Core Concepts
→
Set up Credential Providers See the Aembit User Guide
→
Aembit’s architecture
Section titled “Aembit’s architecture”Aembit’s ability to execute its identity-first, policy-driven access flow is enabled by its two main architectural components working together: Aembit Cloud and Aembit Edge.
Aembit Cloud
Section titled “Aembit Cloud”Aembit Cloud is Aembit’s centralized control plane, where all the configuration and policy management occurs. Aembit Cloud is where you define and manage your Client Workloads, Server Workloads, Access Policies, Trust Providers, Access Conditions, and Credential Providers.
Aembit Cloud receives requests from Aembit Edge (more on that in the next section), and performs Access Policy decision-making logic and administrative tasks such as:
- authenticating Client Workloads using Trust Providers
- evaluating Access Conditions
- interacting with Credential Providers to obtain necessary credentials
- centralizes all access event logs for auditing and visibility
It then sends the authorization decision and any credentials back to Aembit Edge.
Aembit Cloud is explicitly designed not to process or log the actual application data exchanged between workloads; it only handles metadata related to the access control decision.
More on Aembit Cloud See Core Concepts
→
Configure Aembit Cloud See the Aembit User Guide
→
Aembit Edge
Section titled “Aembit Edge”Aembit Edge is Aembit’s distributed data plane and enforcement point, deployed directly within your environments, close to your workloads. Aembit Edge’s primary job is to transparently intercept outbound network requests from Client Workloads destined for Server Workloads.
Upon interception, Aembit Edge gathers identity evidence from its local runtime environment, communicates with Aembit Cloud for authentication, policy evaluation, and credential retrieval. Once Aembit authenticates a Client Workload’s identity, Aembit Edge injects the credential just-in-time (JIT) into Client Workload’s original request before forwarding it to the target Server Workload.
If Aembit Cloud denies a request, Aembit Edge blocks it. This interception and injection capability allows Aembit to secure access for many existing applications without requiring code changes (“no-code auth”). Aembit Edge also sends detailed access event logs back to the Cloud.
More on Aembit Edge See Core Concepts
→
Deploy Aembit Edge See the Aembit User Guide
→
Logging and auditing
Section titled “Logging and auditing”Aembit provides comprehensive, centralized logging and auditing critical for security and visibility. Its logging is identity-centric, linking events to verified workload or administrator identities. Aembit’s logging capabilities include recording workload access attempts or Access Authorization Events and administrative actions.
You can export logs using Log Streams to external destinations like AWS S3 and Google Cloud Storage for retention and integration with SIEM platforms.
Aembit’s logging directly supports compliance requirements, by generating detailed, identity-based audit records. It also aids security incident response and forensic analysis by providing clear context and attribution for workload activities.
More on Auditing See Core Concepts
→
Audit Aembit logs See the Aembit User Guide
→
Access Policy flow: Putting it all together
Section titled “Access Policy flow: Putting it all together”Putting all these components together, Aembit provides a powerful and flexible solution for managing workload access without the need for static secrets.
The following simplified Access Policy evaluation flow illustrates how all Aembit’s components work together to provide secure workload access:
-
Request Initiation and Interception - A Client Workload attempts to connect to a Server Workload.
-
Identify the Workloads - Aembit Edge observes the Client Workload’s identity using metadata from your environment—such as Kubernetes service account names, VM identity tokens, or cloud-specific signals.
-
Match request to an Access Policy - Aembit Cloud compares the request to existing Access Policies. If no policy matches both workloads, Aembit denies the request.
-
Verify Identity with Trust Providers (optional) - Aembit checks with a Trust Provider (like AWS, Azure, or Kubernetes) to verify the Client Workload’s identity. This process removes the need for long-lived secrets by leveraging native cloud or orchestration signals.
-
Evaluate Access Conditions (optional) - If the request matches a policy, Aembit checks whether it satisfies any extra conditions. For example, it might require the workload to run in a specific region or during certain hours.
-
Retrieve Credentials from a Credential Provider - When the request passes all checks, Aembit contacts the Credential Provider to retrieve the appropriate credential—such as an API key or OAuth token.
-
Inject the Credential - Aembit Edge injects the credential directly into the request, typically using an HTTP header. The Client Workload never sees or stores the credential.
The following diagram is a simplified illustration of the Access Policy evaluation flow:
