TL;DR: Teleport's interview with its senior sales director argues that many enterprises still stop identity governance short of the infrastructure layer, leaving humans, machines, workloads, and AI agents outside the same cryptographic and policy controls that govern access. The control gap is not a sales detail; it is a governance failure in how identity is applied to infrastructure itself.
At a glance
What this is: This interview frames infrastructure identity as the gap where identity governance stops at users and leaves infrastructure access, machines, workloads, and AI agents unevenly controlled.
Why it matters: It matters because IAM teams cannot close risk with human identity controls alone when infrastructure access is increasingly exercised by non-human and autonomous actors.
👉 Read Teleport's interview on the infrastructure identity gap and leadership perspective
Context
Infrastructure identity is the governance problem of proving, authorizing, and controlling access to systems that run workloads, automation, and administrative actions. In this interview, Teleport's sales leadership uses that framing to argue that many enterprise identity programmes still treat infrastructure as separate from the main access control plane.
The practical issue for IAM and security teams is not just who can log in, but what identity controls extend into servers, clusters, operational tooling, and agent-driven workflows. Where those controls stop at the perimeter of the application stack, the organisation inherits an access gap that conventional SSO and directory-centric programmes do not close.
The article is a leadership profile, not a technical deep dive, so the value lies in the problem statement it surfaces: infrastructure identity is now part of the broader identity security programme, not a side concern for platform teams.
Key questions
Q: How should security teams govern infrastructure identities alongside user identities?
A: Treat infrastructure identities as part of the same governance programme, but manage them with tighter lifecycle controls. Every service account, workload credential, certificate, and agent identity should have an owner, a purpose, a rotation schedule, and a documented revocation path. Without that structure, infrastructure access becomes shadow IAM with little accountability.
Q: How should security teams unify IAM for humans, workloads, and AI agents?
A: Security teams should unify IAM around shared identity data, policy, and telemetry so access decisions can follow the full lifecycle. The goal is not one product for everything, but one control model that can see issuance, usage, renewal, and revocation across humans, service accounts, and agents.
Q: What breaks when non-human identities are managed outside the IAM operating model?
A: What breaks is accountability. Without IAM ownership, non-human credentials drift into fragmented secrets tools, inconsistent review cycles, and orphaned access that persists after the workload changes. That is how machine identities become invisible trust dependencies.
Q: How do teams know if identity security controls are actually working?
A: Identity security controls are working when teams can show a current view of high-risk entitlements, detect privilege drift quickly, and remove access before exposure spreads. A useful sign is reduced time between entitlement change and policy review. Another is fewer unresolved conflicts between approved access and actual production permissions.
Technical breakdown
Why infrastructure identity does not fit cleanly into app-centric IAM
Application-centric IAM usually assumes a person signs in, gets a session, and then works inside a bounded business application. Infrastructure identity breaks that model because the access subject may be a human, a service account, a workload, or an AI agent acting through cryptographic identity. The control point moves from user authentication to continuous authority over infrastructure actions, which means session boundaries, policy enforcement, and auditability must apply outside the application layer. Teleport's framing reflects a wider shift: the trust boundary is moving downward into operational infrastructure, where traditional IAM coverage is incomplete.
Practical implication: Map which infrastructure systems are still governed only by directory or SSO controls, then identify where policy enforcement ends before the admin plane begins.
Why humans, machines, workloads, and AI agents need one identity layer
The article's core architectural claim is that infrastructure identity has to unify multiple actor types rather than treat each as a separate exception. That matters because the same infrastructure resource can be reached by a human operator, a workload credential, or an AI agent invoking tools. Without a single governance model, teams end up with fragmented authentication methods, inconsistent policy, and uneven logging across the operational stack. The real technical problem is not just access grant, but identity continuity across actors that all need cryptographic control and policy-based authorization in the same environment.
Practical implication: Inventory every infrastructure access path by actor type so policy, authentication, and audit controls can be aligned across human and non-human use cases.
Why cryptographic control matters in infrastructure access
Cryptographic control is the difference between identity that can be asserted and identity that can be trusted at machine speed. In infrastructure contexts, certificates, keys, and other secrets often become the actual enforcement mechanism for access, especially where machines, workloads, and agents operate without interactive sign-in. That makes identity governance inseparable from secret lifecycle, trust anchor management, and policy binding. The interview's emphasis on cryptographically secured infrastructure identity points to a fundamental reality: if access is not tied to verifiable cryptographic identity, the programme is relying on assumptions rather than enforceable control.
Practical implication: Treat keys, certificates, and workload credentials as identity assets with lifecycle ownership, not as backend implementation details.
NHI Mgmt Group analysis
Infrastructure identity is now a control-plane issue, not a product category issue. The article surfaces a familiar enterprise blind spot: identity programmes often cover people and applications, but stop short of the infrastructure layer where operational privilege actually lives. That gap matters because the same governance failure can expose servers, clusters, automation, and administrative tooling at once. Practitioners should read this as a signal that infrastructure access must be brought under the same identity discipline as user access.
Identity governance breaks when the actor is no longer only human. The article explicitly places humans, machines, workloads, and AI agents inside one infrastructure identity model, which means separate handling models create policy drift. Once multiple actor types can reach the same infrastructure, the useful question is no longer whether authentication exists, but whether authority is consistent across all actors that can execute privileged actions. Security teams need a common governance model, not four disconnected exceptions.
Cryptographic identity is the operating assumption that makes infrastructure governance scale. If infrastructure access depends on ad hoc trust, manual approvals, or loosely controlled secrets, the programme cannot prove who or what acted at runtime. That makes cryptographic identity the minimum viable trust fabric for infrastructure security. The implication for identity architects is straightforward: the identity control plane must extend into the operational layer or remain incomplete.
Infrastructure identity closes a policy gap that human IAM alone cannot see. Human IAM tools are optimised for login, sessions, and user lifecycle, but infrastructure systems increasingly consume identity through certificates, tokens, and workload credentials. That creates a separate governance surface with its own issuance, scope, and revocation problems. Practitioners should treat infrastructure identity as a first-class programme boundary, not a technical side effect of cloud operations.
Named concept: infrastructure identity gap. This is the space where enterprise identity governance ends before it reaches the infrastructure layer that runs real work. The interview uses that gap to show why identity programmes can appear complete while still leaving operational systems under-governed. The practical conclusion is that identity coverage must be measured by where authority is enforced, not by where users authenticate.
What this signals
Infrastructure identity gap: Many identity programmes still measure success by user coverage, while the real exposure sits in the operational layer where machines, workloads, and agents act. The next governance step is to measure whether infrastructure privilege is issued, logged, and revoked with the same discipline as human access.
The shift toward unified identity for infrastructure means IAM leads should stop treating workload and admin access as cloud-adjacent exceptions. Once the organisation can no longer distinguish user login from machine authority in practice, governance has to move to the identity boundary that controls execution itself.
For practitioners
- Map the infrastructure identity boundary Identify where current IAM controls stop at the application layer and do not reach servers, clusters, deployment tooling, and admin planes.
- Classify infrastructure actors by type Separate human operators, service accounts, workloads, and AI agents so each access path has a clear authentication and authorization model.
- Bind policy to cryptographic identity Require certificates, keys, or tokens to be issued and governed as identity assets rather than treated as unmanaged implementation artifacts.
- Review where secrets replace governance Find places where static credentials or shared tokens stand in for accountable identity controls and mark them for lifecycle ownership.
- Extend audit coverage into the infrastructure layer Verify that privileged infrastructure actions are logged with actor attribution, not only with infrastructure event records.
Key takeaways
- The article surfaces a governance gap, not a product discussion: enterprise identity often stops short of infrastructure, where real operational privilege is exercised.
- The operational risk is that humans, machines, workloads, and AI agents can all touch the same infrastructure without a single, consistent control model.
- The practical response is to extend identity governance into the infrastructure layer and bind privilege to cryptographic identity, policy, and auditability.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 — Overprivileged NHI | The article centres on infrastructure identities holding authority beyond human IAM boundaries. |
| NHI-04 — Insecure Authentication | Cryptographic identity is central to the article's infrastructure security framing. | |
| NHI-07 — Long-Lived Secrets | Infrastructure access still depends on secrets and credentials that need lifecycle governance. | |
| Recommendation — Apply NHI-05 to reduce standing access on infrastructure identities that exceed operational need. Harden infrastructure authentication so workload and machine identities cannot rely on weak trust assumptions. Replace long-lived infrastructure secrets with governed short-lived credentials wherever possible. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle management is directly relevant to infrastructure identity and secret governance. |
| Recommendation — Use IA-5 to govern issuance, rotation, and revocation of infrastructure authenticators. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is fundamentally about where access control extends across the infrastructure layer. |
| Recommendation — Apply PR.AA-05 to align infrastructure entitlements with the actor performing each action. | ||
Key terms
- Infrastructure Identity: The identity layer used to authenticate and authorize access to infrastructure rather than business applications. It covers humans, workloads, service accounts, and AI agents when they reach servers, clusters, and operational tooling. In mature programmes, it is governed with the same lifecycle discipline as user identity.
- Cryptographic Identity: Cryptographic identity is a trust model in which authentication depends on verifiable keys, certificates, or signed assertions rather than shared secrets alone. It is essential for machines and agents because it gives the organisation a stronger way to prove identity and revoke access quickly.
- Infrastructure Identity: Infrastructure identity is the set of credentials and trust relationships that allow systems, workloads, and automation to authenticate to other systems. It is the machine-facing layer of identity governance, and it often carries more operational risk than human access because it is persistent and widely reused.
- Workload Identity: The identity assigned to a software workload, such as a containerised application, serverless function, or microservice, enabling it to authenticate to other services without storing static credentials.
What's in the full article
Teleport's full article covers the leadership interview detail this post intentionally leaves for the source:
- John Solazzo's leadership background and hiring context at Teleport
- The sales-team operating cadence and coaching approach described in the interview
- Direct quotes on why infrastructure identity mattered in the move from Okta to Teleport
- The culture and team-building commentary that sits outside the identity governance takeaway
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.
Published by the NHIMG editorial team on May 14, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org