Teleport Provides Unified Infrastructure Access. Access Control Is Not Cryptographic Governance.
by Nick Clark | Published March 28, 2026
Teleport has built one of the strongest identity-based infrastructure access platforms in production use. SSH servers, Kubernetes clusters, Windows desktops over RDP, internal applications, and databases all sit behind a single Teleport proxy that issues short-lived, certificate-bound credentials in place of static keys and passwords. Teleport Identity layers role-based access controls, dual-authorization workflows, and just-in-time access requests on top of that proxy. Teleport Connect gives engineers a desktop client that handles certificate refresh transparently. The certificate machinery is ACME-grade, with proper key rotation, audit logging, and session recording. The unified access layer is well-designed and well-implemented. But Teleport controls who can access what; it does not cryptographically govern what operations are performed within authorized access sessions. A user with SSH access can still run any command the target host permits. A user with database access can still run any query the target database permits. Access control is not operation governance, and the gap matters. This article positions Teleport against the AQ cryptographic-governance primitive.
1. Vendor and Product Reality
Teleport, the commercial product of Gravitational Inc. operating under the Teleport brand since 2020, is the de facto modern replacement for the bastion-host-and-VPN architecture that defined infrastructure access for the previous two decades. The flagship offering, Teleport Access Platform, unifies SSH, Kubernetes, database, Windows desktop, and internal web application access behind a single identity-aware proxy with certificate-based credentialing. Teleport Identity adds role-based access control, just-in-time access requests with peer review, dual-authorization for sensitive resources, and session moderation. Teleport Policy provides a graph-based view of access relationships across the connected fleet. The customer base spans high-growth software companies, fintechs, and increasingly regulated enterprises that have outgrown static-key SSH workflows and want an auditable, identity-bound access plane.
The architectural shape is well-defined. An identity provider — Okta, Azure AD, Google Workspace, or a self-hosted SAML/OIDC issuer — authenticates the human or workload. Teleport's auth service issues a short-lived X.509 certificate with role attributes embedded as extensions and SSH user-certificate equivalents for SSH endpoints. The proxy service brokers connections between client and target, terminating the user's connection and re-establishing a server-side connection authenticated by the same role-bound certificate. Session recording captures keystrokes, terminal output, structured database queries, and Kubernetes API calls, persisting them to S3-compatible storage with optional encryption. Access requests flow through Slack, PagerDuty, or Teleport's native UI. The certificate authority can rotate without disrupting in-flight sessions, and the entire control plane is operable as a self-hosted cluster or as Teleport Cloud.
Within its scope Teleport is genuinely first-rate. The connector library covers the resources engineers actually need to reach. The certificate hygiene is correct. Session recording is real, structured, and reviewable. Just-in-time access with peer approval is mature, and dual-authorization for production resources reflects a thoughtful posture toward sensitive operations. Teleport has internalized zero-trust access principles and made them implementable for organizations that lack a dedicated platform-security team. The product solves a problem the industry needed solved, and it solves it cleanly. This article does not contest any of that. The gap analyzed here concerns a layer above the access plane that Teleport's architecture does not occupy and was not designed to occupy.
2. The Architectural Gap
The structural property Teleport's architecture does not exhibit is cryptographic governance over the operations performed within an authorized session. Teleport governs the boundary of access — who reaches what resource, for how long, with whose approval. It does not govern, in any cryptographic sense, what occurs once that boundary is crossed. A user authorized for SSH access to a production host carries a session certificate that the host accepts; the operating system on that host will then execute whatever command the user types, subject only to the file-system permissions and shell capabilities of the target Unix account. A user authorized for database access can run any query the database role permits, including queries entirely unrelated to the access request that motivated the session. Teleport sees the operation and records it; it does not decide on it.
Session recording is observation, not governance. Recording captures actions that have already occurred. It does not prevent actions that should not occur. A user issuing an inappropriate DROP TABLE against a production database is recorded doing so; the table is still dropped. A user executing a destructive shell command against a production host is recorded doing so; the host is still affected. The recording is forensic evidence after the fact. Compliance teams treat it as a deterrent, and as a deterrent it has measurable effect, but a deterrent is not a control. Cryptographic governance, by contrast, binds an enforceable, signed policy decision to each operation at the moment of issuance, not to the session that surrounds it.
Access requests with peer approval do not close this gap because the approval is bound to access, not to operations. When a reviewer approves a request for production database access to investigate a specific incident, the resulting session can run any query the database role permits — not only queries relevant to the incident. The Teleport model has no construct for "approved to run these read-only queries against these tables, for this stated purpose, and no others." That construct does not exist because the governance unit in Teleport is the session, and the session is bounded by access scope rather than operation scope. Organizations compensate with after-the-fact review of recordings, with database-side row-level policies, and with cultural norms about appropriate use. None of those compensations is cryptographic. None produces a signed, verifiable record that the operation was authorized under a specific policy at the moment it executed.
Teleport cannot patch this from within its current architecture because the platform was designed as an access plane: a proxy that brokers connections and issues credentials. Adding a per-operation policy decision point inside the SSH session would require Teleport to terminate and re-encode every shell command, which is incompatible with how SSH actually works and would degrade the user experience the platform exists to deliver. Adding it inside the database session would require Teleport to become a query firewall — a different product category with different operational properties. The architectural shape that delivers operation-level governance is structurally distinct from the shape that delivers identity-bound access, and Teleport is, correctly, the latter.
3. What the AQ Cryptographic-Governance Primitive Provides
The Adaptive Query cryptographic-governance primitive specifies that every operation in a conforming system carry a cryptographically signed governance token bound to the specific operation, the specific governance policy version under which it was authorized, and the lineage of approvals that produced that authorization. The token is not merely a session credential. It is an operation-level artifact: a structured object that names the operation (the SQL statement, the shell command, the Kubernetes API call, the file mutation), the policy clauses that admit it, the authority that signed those clauses, the corroborating context (incident ID, change-management ticket, peer attestation), and the constraints under which the operation may execute (time window, target scope, reversibility class).
The primitive makes operations first-class governed objects. A query reaching a database arrives carrying both the access-plane credential (which proves who is connected) and the governance token (which proves that the specific query has been admitted under signed policy). The database, or a governance-aware sidecar, validates the token against the signed policy bundle before executing. Validation is local and deterministic: the policy bundle is a content-addressed, signed artifact; the token references it by hash; the sidecar verifies the signature chain back to a published authority. If the token is missing, expired, or inconsistent with the operation, the operation is refused or downgraded to a non-mutating mode. The decision is cryptographic, not procedural.
Equally load-bearing is that the governance decision is recorded as a verifiable artifact at the moment of execution. Where session recording produces evidence after the fact, the governance primitive produces evidence concurrent with the action and bound to it by signature. The token itself, once consumed, becomes a lineage record: a permanent attestation that this operation was admitted under this policy, signed by this authority, in response to this antecedent approval. The lineage chain composes recursively — the approval that authorized the token is itself a signed observation, the policy version is itself a signed publication, and the authority's credential is itself a signed delegation from a higher authority within a published taxonomy. Forensic reconstruction does not depend on replaying a recording; it depends on traversing a signature chain.
The primitive is technology-neutral. Any signature scheme (Ed25519, ECDSA, post-quantum lattice signatures), any policy-encoding language (Rego, Cedar, custom DSL), and any transport (gRPC sidecar, HTTP middleware, in-process library) satisfies the structural requirement, provided the resulting artifact binds policy to operation cryptographically and produces a verifiable lineage record. The inventive step disclosed in the cryptographic-governance provisional is the binding of signed, per-operation governance tokens to a recursive lineage chain such that authorized access does not silently confer unconstrained authority — and such that every executed operation is, by construction, accompanied by a verifiable record of the policy that admitted it.
4. Composition Pathway
Teleport composes with the AQ cryptographic-governance primitive cleanly, and the composition is non-disruptive to Teleport's existing surface. What stays at Teleport: the identity provider integration, the certificate authority, the proxy service, the session recording infrastructure, the access-request workflow, and the entire user experience of Teleport Connect and the web UI. Teleport's value as the unified access plane — the part the engineering customer base actually loves — is preserved without modification. Teleport remains the answer to "who is connected to what, with what role, for how long, and under whose approval."
What is added beneath Teleport is a governance plane that consumes Teleport's identity and session attestations as input and emits operation-level governance tokens as output. The integration points are well-defined. When a Teleport access request is approved, the approval is signed not only as a Teleport audit event but as a governance authorization that names the operations or operation classes the session is permitted to perform. When the session opens against a target resource, the governance plane issues short-lived, operation-scoped tokens upon demand: a token for each shell command, each database query, or each Kubernetes API call, derived from the session-level authorization and bound to the specific operation by signature.
On the target-resource side, a governance-aware sidecar — a database proxy, a shell-execution wrapper, a Kubernetes admission controller — validates the token before executing the operation. The sidecar is thin; its only job is signature verification against a published policy bundle and emission of the lineage record. The sidecar pattern keeps the target resource itself unmodified, which matters because the database vendor, the Kubernetes distribution, and the operating system are not part of the governance commercial relationship and cannot be required to change. The token-and-sidecar pattern composes with any resource a Teleport connector reaches today and with any future connector Teleport adds.
The user experience does not regress. Engineers continue to work through Teleport Connect, run shell commands, and issue queries as they do today. In the steady state, the governance plane issues tokens automatically based on the access request's scope, and operations succeed without additional friction. Friction appears only at the boundary where an operation falls outside the authorized scope — at which point the sidecar refuses the operation and the engineer is prompted to request an extension, exactly as they would today request an access escalation. The governance plane elevates the existing access-request UX into an operation-request UX, with the same Slack-and-PagerDuty integrations and the same peer-review workflow Teleport customers already operate.
5. Commercial and Licensing Implication
The fitting commercial arrangement is an embedded substrate license under which Teleport incorporates the AQ cryptographic-governance primitive into Teleport Identity and Teleport Policy as a first-class governance layer beneath the access plane. Pricing is per-protected-resource or per-governed-operation rather than per-seat, which aligns with how regulated customers actually consume governance: their cost scales with their attack surface and their mutation rate, not with the size of their engineering team. Teleport sub-licenses chain participation to its enterprise customers as part of a Teleport Enterprise tier.
What Teleport gains: a structural answer to the "approved access still confers unconstrained authority" problem that current session recording only addresses forensically; a defensible position against in-platform competition from AWS Systems Manager Session Manager, HashiCorp Boundary, and StrongDM by elevating the architectural floor from access to operation governance; and a forward-compatible posture against EU NIS2, SEC cyber-disclosure rules, and emerging operational-resilience regimes that are converging on per-operation authorization evidence rather than session-level audit. What the customer gains: cryptographic, per-operation governance that survives platform changes and that produces audit-grade lineage portable across vendors. The chain belongs to the customer's authority taxonomy, not to Teleport's database, so the customer's governance history outlives any particular vendor relationship — which paradoxically makes Teleport stickier, because the platform's connector library, certificate hygiene, and operator UX become the differentiated route to that substrate.
Honest framing: the AQ primitive does not replace Teleport. It gives Teleport the operation-governance layer that the market is beginning to demand and that the Teleport architecture, by design, does not deliver. Teleport remains the unified access plane. Cryptographic governance becomes the layer above, supplied by the AQ primitive, embedded into the Teleport product, and made commercially available as part of the Teleport relationship. Access control and operation governance become distinct concerns, addressed by distinct mechanisms, and combined into a coherent posture in which authorized access does not silently confer unconstrained authority — and in which every executed operation is accompanied by a verifiable record of the policy that admitted it.