Teleport gRPC API shows how NHI clients should be governed

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Teleport's blog post: API clients of Teleport's gRPC API are authenticated and authorized as non-human identities.

Why it matters: It matters because IAM and NHI teams need to treat service clients as governed identities, not as implementation details hidden inside tooling.

👉 Read Teleport's guide to governing gRPC API clients as non-human identities

Context

Teleport’s gRPC API is designed for clients that manage dynamic resources inside a Teleport cluster, including tctl, the Terraform provider and the Kubernetes operator. The core identity question is not whether these clients can connect, but how they are authenticated, authorised and constrained as non-human identities.

The article makes the governance gap explicit: API clients need their own lifecycle, permission model and credential handling, rather than inherited access from whichever automation happened to call them. That is a familiar NHI problem, even when the interface is exposed through developer tooling rather than a dedicated secrets platform.

Key questions

Q: How should teams govern API clients that manage infrastructure like NHIs?

A: Give each client its own identity, role and credential lifecycle. When a tool can create, read or change resources, it needs the same governance discipline as any other privileged non-human actor, including narrow permissions, traceable ownership and revocation when the integration ends.

Q: Why do client certificates and mTLS still need lifecycle governance?

A: Because authentication only proves the caller once. Without rotation, revocation and offboarding, a valid certificate can become a standing access path long after the client or integration should have changed, which leaves machine identities harder to govern than the transport layer suggests.

Q: What breaks when multiple automation tools share one API identity?

A: Attribution and privilege control degrade quickly. Shared identities blur which tool performed an action, make access reviews less meaningful and encourage broader permissions than any single client really needs, which increases the blast radius of a compromised integration.

Q: Should teams use dynamic identity files for long-running machine clients?

A: Yes, when the client must stay online while credentials rotate. Reloadable identity files reduce manual intervention and help continuous workloads keep access aligned to current credentials, provided the underlying issuance and revocation process is still tightly governed.

Technical breakdown

mTLS as the authentication boundary for API clients

Teleport uses mTLS to authenticate the client-server connection for its Auth API. The client presents TLS certificates signed by the Auth Service, which means the API is not relying on simple bearer tokens or ambient trust. In NHI terms, the certificate becomes the machine credential that establishes who the caller is before any API action is authorised. This is a stronger model than ad hoc script access, but it still depends on issuance, trust anchors and lifecycle control. The important architectural point is that transport security and identity assurance are being bound together at connection time.

Practical implication: govern the certificate issuance path as part of the API access model, not as a separate transport setting.

User-bound client certificates and role-scoped authorization

Teleport associates the client certificate with a specific user, and that user identity is then used to authorise API requests. The guide recommends creating a new user and role for each client so actions can be tracked and permissions kept narrow. That design mirrors NHI governance patterns where a workload or tool should have a distinct identity, a discrete policy boundary and a clean audit trail. It also avoids the common anti-pattern of one shared automation identity doing everything, which makes attribution and privilege control much weaker.

Practical implication: give each API client a distinct identity and role so access reviews and audits can trace actions back to a single non-human caller.

Credential loaders and dynamic identity file rotation

The credentials model is broader than one static key. Teleport supports profile credentials, identity files, dynamic identity files, key pair credentials and TLS credentials, each with different operational trade-offs. Dynamic identity files are especially relevant for machine and workload identity because they can reload when underlying identity files rotate. That matters for NHI governance because it separates how a client authenticates from how its underlying credential is refreshed. The architectural risk is assuming a client is secure because it uses certificates, when the real issue is whether those certificates can be rotated, reloaded and retired without manual drift.

Practical implication: choose a credential type that supports rotation and reload where the client runs continuously or depends on workload identity.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

NHI clients need first-class governance, not inherited trust: Teleport’s API pattern shows that tooling identities such as Terraform providers and Kubernetes operators behave like durable machine actors, not transient request headers. Once a client can manage cluster resources, it has governance significance regardless of whether a human triggered it. The implication is that identity programmes must inventory API clients as NHIs and assign them explicit lifecycle ownership.

Least privilege becomes meaningful only when client identities are distinct: Teleport’s recommendation to create a new user and role for each client is a governance pattern, not a convenience feature. Shared automation identities collapse attribution, make access reviews noisy and encourage privilege creep. Practitioners should treat client-by-client identity separation as the baseline for auditability and control.

Credential lifecycle is part of the API security boundary: mTLS and signed client certificates reduce unauthenticated access, but they do not solve offboarding, rotation or reuse on their own. In machine identity programmes, the credential lifecycle is the control plane, because expired or over-broad client credentials are what turn a trusted integration into a standing access path. That is why API client governance has to include issuance, rotation and revocation as a single discipline.

Dynamic identity files point to a broader machine-identity operating model: The presence of dynamic identity files shows that long-lived tooling identities need refreshable credentials rather than one-time setup. This is exactly where NHI governance intersects with operational reliability: clients that cannot reload cleanly tend to accumulate exceptions, manual interventions and stale privileges. Practitioners should design for continuous credential continuity without losing revocation control.

Governed API clients are the real control surface for modern infrastructure: As more infrastructure is managed by code and operators, the client identity becomes the enforcement point for every administrative action. That shifts the security question from whether a tool can automate tasks to whether the tool’s identity is governed with the same seriousness as a privileged human account. Teams that ignore this are leaving the most active admin pathway under-governed.

What this signals

Client identities are now part of the privileged estate: Any API client that can manage infrastructure should be treated as a governed non-human identity, with ownership, permission boundaries and offboarding procedures. The operational mistake is to hide these clients inside tooling and assume the surrounding application will absorb the risk.

Machine identity programmes should separate transport trust from authorisation scope. mTLS can prove the client is present and trusted by a certificate authority, but the role attached to that client still decides what it can change, and that is where most privilege creep begins.

For practitioners

• Create a distinct identity for every API client Assign each automation or tooling client its own user and role so permissions, logs and access reviews map to one caller instead of a shared automation account.
• Enforce mTLS for non-human API access Require certificates signed by the Auth Service for all clients that manage cluster resources, and treat certificate issuance as part of the access model.
• Scope client roles to the minimum read or write action Build roles from the exact API operations a client needs, then avoid broad built-in roles when a narrower policy will do.
• Use dynamic identity files for continuously running clients Prefer reloadable credentials for workloads that must keep operating while underlying identity files rotate, so rotation does not force manual downtime.
• Remove ad hoc token handling from enrolment workflows Store invitation or enrolment tokens securely instead of passing them on the command line, where history files and compromised hosts can expose them.

Key takeaways

• Teleport’s API model shows that automation clients need explicit identity governance, not borrowed trust from the systems they control.
• Certificate-based authentication is only part of the control picture, because role scope and credential lifecycle determine the real blast radius.
• The practical control is to bind each client to a unique identity, a minimum-permission role and a rotation-aware credential model.

Key terms

• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.
• mTLS: Mutual TLS is a transport pattern where both sides of a connection authenticate each other with certificates. In NHI programmes, it is often the control that binds service identity to encrypted traffic, but its value depends on certificate lifecycle, protocol version, and enforcement consistency.
• Credential Loader: A credential loader is the mechanism a client uses to find and assemble the certificates or identity material needed for authentication. In practice, loader choice affects usability, rotation support and how cleanly machine credentials can be refreshed without breaking active workloads.
• Least Privilege: A security principle requiring that every identity, human or non-human, is granted only the minimum permissions necessary to perform its function. Least privilege is the single most effective control for reducing NHI blast radius.

What's in the full article

Teleport's full guide covers the operational detail this post intentionally leaves for the source:

• Step-by-step role and user configuration examples for API clients that manage Teleport resources
• Credential loader comparisons that help teams choose between profile, identity file, dynamic identity file and TLS approaches
• Connection setup details for clients that reach the Auth Service directly or through a reverse tunnel
• Production hardening guidance for running Teleport services and clients with minimal privileges

👉 Teleport's full guide covers authentication, authorization and credential handling details for API clients

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.