Deepgram has integrated its speech recognition models on Amazon SageMaker AI using AWS temporary IAM delegation. Instead of managing static API keys to access the service, SageMaker assumes an IAM role, obtains credentials that expire after a defined time, and uses them to call the Deepgram API.

For anyone running AI agents or pipelines in production on cloud, credential management is one of the most concrete operational challenges. Static keys are a security risk and a daily headache: they expire, get lost, end up in logs or repos. With this integration, the time to first investigation on a SageMaker support ticket has dropped from days to minutes (source: AWS ML blog, July 27, 2026).

The fact that a vendor puts models in production on AWS and chooses temporary delegation as an integration criterion, and that AWS shares it as a reference case, is the signal. If you’re building agents that talk to external services, this is the approach to watch.

Security risks are one of the criteria in the lesson on costs, latency, and security in production.

In detail

Temporary IAM delegation is an AWS mechanism where a role grants permissions to an entity for a limited time interval. SageMaker assumes an IAM role, obtains temporary credentials, and uses them to call the Deepgram API. When the token expires, it disappears.

What came before. Anyone wanting to use Deepgram on SageMaker had to manage the service’s API keys manually: paste them in environment variables, rotate them periodically, make sure they didn’t end up in logs or shared notebooks. It’s the classic pattern of a secret living where it shouldn’t, and anyone who’s managed secrets in production knows how it ends: eventually someone commits them in plain text to a repo, or leaves them in a forgotten config file.

What changes. With IAM delegation, the flow reverses. SageMaker assumes an IAM role and obtains temporary access to Deepgram. The application no longer carries any key to the service. AWS cites a concrete number: time to first investigation on a support ticket drops from days to minutes, because support can immediately see what permissions are involved without having to reconstruct the manual key chain.

Why it matters for those building agents. An agent that talks to external services (third-party APIs, databases, cloud tools) needs credentials to do so. The question is where those credentials live. If they live inside the agent or inside the prompt, they’re a problem waiting to happen. If they live in a role the agent temporarily assumes, the risk narrows. The fact that a vendor like Deepgram chose this approach as an integration criterion, and that AWS presents it as a reference case, means the approach is becoming standard for those putting models in production on cloud.

Limits of what we know. The announcement comes from the AWS blog, which has an interest in promoting the integration. Complete architectural details aren’t verifiable beyond the post. Missing are numbers on additional latency from delegation, IAM role costs, or impact on speech model throughput. Replicability across other vendors or workloads isn’t documented.

For those building agents in production, the operational lesson is direct: credential security decides how you structure integration from the start. Those who leave it for last end up redesigning. It’s the same principle as OneCLI and claude-thermos: keep keys out of agents as early as possible.