Single-run keys instead of permanent ones: Vercel, Postman, Pulumi and Auth0 on the same thing

In one week, four companies with no connection to each other wrote about the same thing: the permanent API key in an environment variable should give way to a token that lives for minutes and is issued for a specific task. For a business owner this answers the question “what happens if the contractor leaves or a laptop goes missing,” and the answer depends on how the keys to your systems were issued.

Four posts about one thing

On October 22, Vercel declared war on long-lived keys. Their comparison is with HTTPS: machine authentication today is where HTTPS was in 2010, before it became the norm for everything. Vercel surveyed more than 1000 SaaS vendors, and only 8.4% of them support secure ways to sign in. Vercel itself writes that it has spent thousands of engineering hours on painful key rotations and doesn't want to anymore. Their answer: OIDC federation, which they have run since 2024, a set of OIDC UI forms for API providers, and Vercel Connect, where the application gets a token for the user and the needed scopes at the moment of the request, with no key in the variables.

On October 20, Postman showed how to work with secrets from the command line. In Postman CLI from version 1.69.0, a secret is created with postman secret create, bound to an environment variable by its identifier, and in requests you write the usual {{PAYMENT_API_TOKEN}}. The collection and the environment file hold a reference to the store; the value isn't there. The value itself is entered through a one-time form in the browser or hidden input in the terminal, so an assistant in the terminal can start the process while a person types the key. This is close to how I work: AI helps me with routine work and debugging, and I don't want keys sitting in its command history.

On October 22, Auth0 released Terraform modules; the first of them, b2b-saas-starter, is already in the Terraform Registry. One module block creates the application, the API, tenant settings, attack protection and MFA, and inside it API permission checks, PKCE and refresh token rotation with a three-second window for parallel requests are already turned on. What matters most to me here is that rotation is on by default.

On October 15, Pulumi added OIDC token issuance for any service to Pulumi ESC. The fn::open::oidc provider signs a short token with the needed audience when the environment is opened, the service verifies the signature and grants its own access. The lifetime is from a minute to an hour, an hour by default, and ESC stores nothing. Their wording about a stored key is exact: it works for anyone who has read it, from any machine, for as long as it exists.

What this means for a car rental company

Take a car rental company. It has a booking site, an internal app, AmoCRM, a payment service and email for contracts. Each connection has its own key. One sits in .env on the server, the second in the CRM settings, the third on the laptop of the developer who built the app and has already left. None of them expires. If one leaks, there is no way to find out, and changing it means going through every place it sits and breaking something along the way.

The conclusion: a key without an expiry and without boundaries is dangerous. A fifteen-minute key for one task can leak too, but the damage is limited to those fifteen minutes and that task.

How it works on my side

In the “Coffee Together” service, which I built in September and October 2026, the most sensitive secret is the login credentials for the Tasty Coffee wholesale account. They are kept in the server's private variables, and the supplier token lives only in process memory. All external requests go through Nginx and a gateway on Node.js: it strips the identity headers sent by the client and determines the user itself from a signed HttpOnly cookie. An admin session lives 8 hours; after five failed sign-in attempts from one address, sign-in is blocked for 15 minutes. Requests to the supplier and to the Google Sheet go through internal proxies that can't be reached from the public network. It is the same principle as at Vercel and Pulumi, only on a shared server with 2 GB of memory and without paid services.

At the PDR company in the US, which I have worked with since 2021, the website, the super app, the telephony and the document parsers all call the server, and I have taken the internal API to its third version. I don't disclose which access each connection has. I'll only say that security questions at the company come to me, and I maintain the server, the VPN and the network equipment myself.

A rule I have worked by for a long time: the code, the database, the server and all access credentials belong to the client. When the keys live in a contractor's notebook, rotation turns into negotiation.

What I would do

Make a list of every key and token: to the CRM, the payment service, SMS, email, maps, AI services. Where it sits, what it can do, when it was last changed.

Get keys out of the code and out of files that get copied from machine to machine. On the server, private variables; in the CLI and in tests, references to a store, as Postman does.

Where a service supports OIDC or short tokens, switch to them. For the rest, and by Vercel's survey that is more than 90%, limit the key's permissions and change it on a schedule.

Decide what the AI assistant sees in the terminal and in the code. On my side I let it work with the code, and I type the key values myself.

Check that all of this can be done without the developer: the access is yours, the list is yours.

On the server as the shared center that checks permissions: the article The server: data, access and process execution. By area: API integrations with clear rules for passing data and infrastructure that can be released and restored. The “Coffee Together” server is described in the case about the group coffee orders service, and the PDR company's internal API on the custom API for several applications page. From neighboring reviews: a compromised certificate authority, an AI agent on a production server and sandboxes for agents and a new Git; earlier I wrote about developer credentials as a contract and API keys and leaks. If you don't know how many keys you have and where they sit, start with that list, and then we can go over it together. Discuss your task.