FOR PLATFORM TEAMS AND THE ENGINEERS THEY SUPPORT

Manage access like the rest of your infrastructure.

Define roles, resources and policy in Terraform or through the API, so access sits in a repo and goes through review like everything else you run. Your engineers connect with psql, kubectl, SSH and their IDEs, unchanged.

Book a 30-minute walkthrough

Platform teams at these companies run access through StrongDM

Access control only works if nobody has a reason to route around it.

Engineers

An engineer who waits a day for a ticket to clear will use the credential already sitting in the runbook instead.

→ A shared credential nobody owns

Pipelines

A build needs database access at 3 a.m.. Whoever wired it up used a long-lived token because that was the thing that worked.

→ A static token in an env var

Coding agents

Agents in the IDE now ask for the same access, and they get whatever the developer running them can reach.

→ Access nobody scoped

Terraform

Roles, resources, policy and approval workflows in the public strongdm/sdm provider

Go, Java, Python, Ruby

Four SDKs over a gRPC API with signed requests

Headless client

Runs in a container with a service account token in the environment

No per-host agent

Nodes sit in your network. Target hosts stay untouched.

Six things you will want to know before you pilot it

Terraform, or the API directly

The strongdm/sdm provider covers accounts, roles, resources, policies, nodes, secret stores and approval workflows. If you would rather call the API, it is gRPC with signed requests through the Go, Java, Python or Ruby SDK.

Nothing new for your engineers to learn

The local client listens on the loopback interface and gives each resource its own address. Existing tools, drivers and IDE database plugins connect to it the way they connect to anything else, and StrongDM supplies the credential behind the session.

Request in Slack, not in a ticket queue

An engineer requests a resource with a reason, an approver sees it in Slack or Teams, and the grant lands scoped to that resource for a set period. When the window closes, the grant closes with it, so nobody files a second ticket to clean up.

Service accounts, and a client that runs in a container

A service account is its own principal with its own role scope. Run the client from its container image with the token in the environment, and your job connects the same way a person would. Session and idle timeouts apply to people, not to service accounts.

Agents reach tools through your policy

StrongDM can sit in front of a Model Context Protocol server as a proxy, which puts agent tool calls under the same access policy as everything else. An agent inherits the entitlements of the person who invoked it, nothing more, and policy can forbid individual tool calls by name.

Nodes in your network, nothing on your hosts

You run nodes, either gateways that accept inbound connections or relays that do not. Target databases, servers and clusters need no agent installed. Nodes have their own container images, so they deploy the way the rest of your workloads deploy.