Modern infrastructure is increasingly run by automated systems, not people. Bots push code. Runners deploy to prod. Agents orchestrate cloud resources. And increasingly, AI models trigger actions directly through prompt-driven automation.
Welcome to the era of non-human identities (NHIs): the invisible workforce operating behind modern digital systems.
But here’s the catch: while human users authenticate with SSO and MFA, most NHIs still access critical resources with static credentials, excessive permissions, and minimal oversight. This creates both a security risk and a threat to infrastructure resiliency.
Teleport Machine & Workload Identity was built to bring order, trust, and traceability to non-human access, replacing static secrets with short-lived, cryptographic identity to enable secure, scalable automation.
Below, we’ll step through four common use cases that demonstrate how our customers are using Teleport to regain visibility and control over NHIs.
1. Securing CI/CD pipelines
CI/CD pipelines are fast and repeatable, but often operate with more trust than is warranted. Automation tools like GitHub Actions, Jenkins, or GitLab runners access cloud resources, push containers, run migrations, and deploy infrastructure. But under the hood, most still rely on hardcoded secrets: long-lived tokens, shared SSH keys, or environment variables that are rarely rotated.
Teleport issues short-lived certificates to non-human identities like CI/CD runners and bots. These credentials expire automatically and are tightly scoped to each job, enabling secure CI/CD automation. Static credentials like API tokens or SSH keys are eliminated completely, NHI access is tightly scoped and time-bound, and all machine-to-machine activity is logged for full auditability.
Example
Deploying a container to Kubernetes from GitHub Actions without storing any kubeconfigs or cloud credentials:
- Enroll the GitHub Actions runner as a trusted workload in Teleport with a just-in-time identity token from a GitHub App integration
- The runner starts a job and uses
tbot(Machine & Workload Identity agent) to fetch a short-lived x.509 + SSH identity, issued based on workload identity instead of a stored secret tbotwrites short-lived credentials (e.g., kubeconfig, AWS creds, SSH certs) to a secure local directory, which are valid for 20 minutes- The workflow uses the issued kubeconfig to deploy the container to Kubernetes
- No long-lived secrets were stored in GitHub, passed between systems, or rotated manually, ensuring the complete workflow is ephemeral, auditable, and identity-based
2. Infrastructure-as-Code (IaC) deployment
When deploying infrastructure with tools like Terraform, Pulumi, or CloudFormation, automation manages critical assets like VPCs, clusters, databases, and secrets. But many IaC workflows use cloud service accounts with broad permissions, or rely on injected environment secrets to execute tasks.
Teleport’s Machine & Workload Identity model issues ephemeral, per-job certificates tied to cryptographic identity, not secrets. This makes it easy to enforce least privilege per repository, deployment, and environment.
Example
Terraform deploying to AWS from GitHub Actions, without long-lived IAM keys:
- Configure GitHub Actions as a trusted workload using Teleport’s GitHub OIDC integration
- On job start, the runner uses
tbotto fetch a short-lived identity with an AWS role assumption policy tbotwrites AWS credentials valid for 15–20 minutes, scoped to exactly one role- The AWS role is assumed via Teleport’s AWS integration with least privilege per workload, and based on workload identity and Teleport roles instead of per repo or team
3. Federated identity across multi-cloud environments
NHIs often require access across AWS, GCP, Azure, and edge environments. But each provider has its own identity system, making federation complex and error-prone.
Teleport acts as a unified identity authority for machines and workloads. This reduces the complexity of cloud federation by issuing standard cryptographic identities (e.g., x.509 certificates with SPIFFE ID) to NHIs across all environments.
The result is uniform workload authentication across clouds and platforms without shared credentials or tokens. Access governance across cloud environments is simplified through consolidated identity policies, reducing the risk of misconfigurations.
Example
A GCP workload needs access to an AWS resource:
- A GKE workload runs a sidecar with Teleport’s Machine & Workload Identity agent
- At startup, the agent authenticates with Teleport and receives
- A x.509 certificate with SPIFFE ID:
spiffe://yourorg/workload/payment-processor
- A x.509 certificate with SPIFFE ID:
- The workload uses this cert* to:
- Call an AWS API via mTLS (proxying through Teleport), and to authenticate to AWS STS using
AssumeRoleWithWebIdentity
- Call an AWS API via mTLS (proxying through Teleport), and to authenticate to AWS STS using
- All logs, trust policies, and expirations are managed centrally by Teleport
*Note: Certs are not single purpose. If the workload in this example also needed to communicate to a database, the same credential could be used as a multi-purpose identity
4. Securing Model Context Protocol (MCP)
The Model Context Protocol (MCP) defines how LLMs securely access infrastructure context and tooling. But without strong identity and access controls, MCP-enabled systems can expose secrets, perform unauthorized actions, or be abused through prompt injection.
Teleport brings trust to MCP environments by issuing short-lived, cryptographic identities to AI agents and model contexts, ensuring that every AI action is authenticated, scoped, and auditable. Zero trust principles are applied to every query or interaction, full traceability from LLM prompt to action is maintained, and safe boundaries for prompt-driven automation are established.
Example
A developer uses an internal LLM agent (via MCP) to query system logs and restart Kubernetes pods:
| Without Teleport | With Teleport |
|---|---|
| The agent uses a shared API key with admin permissions | When the LLM is instantiated, it requests a short-lived identity from Teleport scoped to read-logs and restart-pod operations |
| There is no visibility into which action was triggered by which prompt | These actions are authorized using Teleport’s RBAC policies, tied to the AI agent’s assigned role |
| If the key is leaked, any attacker can restart services | Each action (e.g.,kubectl delete pod) is executed using mTLS over a secured channel, and logged with the agent’s workload identity |
Bring trust to NHI and infrastructure everywhere
Teleport Machine & Workload Identity is built to solve the challenges of non-human identities within modern infrastructure.
By unifying access control and replacing static credentials with short-lived, cryptographic identity, Teleport enables secure automation across CI/CD pipelines, infrastructure provisioning, multi-cloud federation, and platform operations.
Engineers move faster, infrastructure resiliency grows stronger, and non-human identities are efficiently managed and secured.
