We issue a credential that anyone who obtains it can copy, then build a substantial amount of machinery to stop it being copied. Put it in a vault. Arrange for the application to retrieve it. Control who can read the vault, record when they do, rotate the credential, scan repositories for it and prepare to revoke it when a copy turns up somewhere it should not. Each precaution has a sensible explanation. Taken together, they are a remarkable amount of work to preserve the secrecy of a string.
Secret management is necessary when this is the credential an API expects. That necessity should make us question the API contract. If copying the credential also copies the authority to spend money, the people operating the application inherit a problem they must keep solving for as long as the credential works.
A new launch, the same clipboard
Take Jev. TypeSafe announced it on 15 September, alongside its System One Models, with ambitions to change how software uses AI. A new product, a new model architecture, developers coming off a waitlist. Open the API quickstart and the familiar instruction is there: get an API key from the dashboard, then send it as a bearer credential.
We can rethink the model and still launch with a secret for the developer to copy and paste. Every wave of sign-ups sends more developers through the same credential-handling routine.
For a metered API, what passes through that clipboard is authority to spend. Before the key reaches the carefully configured production vault, it has been on somebody's end-user device. Whatever protection comes afterwards cannot undo that exposure. Clipboard protections vary, but Microsoft's Win32 documentation is unusually direct: “The clipboard should not be used to transfer sensitive data.”
The clipboard should not be used to transfer sensitive data.
The developer may trust their laptop, their extensions and their clipboard manager. They may be certain they would spot a compromise. None of that confidence is evidence the API can verify when someone presents a copy of the key. Unless further controls intervene, possession is enough.
This convention extends well beyond AI. Stripe's key documentation describes copying a secret into a vault, restricting its permissions and access, and rotating it when necessary. Those restrictions matter. They also show how much work follows the decision to issue a copyable credential. Payments, messaging, compute: the authority differs, but the customer inherits the handling problem.
I want API vendors to offer a lower price for production workloads using short-lived workload identity, with a larger discount where they can verify hardware-backed proof of possession. The commercial pitch is that fewer credential incidents should cost the vendor less to handle, leaving a saving it can share with the customer. A successful new launch should be an opportunity to establish that arrangement from the start.
The work after the first request
Both OpenAI and Anthropic now document workload identity federation for their direct APIs. An application obtains a signed identity token from a trusted provider and exchanges it for a temporary credential to call the API. The customer no longer needs to distribute a standing vendor secret to that workload.
This does require configuration. An administrator must establish which provider to trust and which workloads it may admit, then map those workloads to appropriate permissions. A rule that admits the wrong repository or deployment can undo the benefit. Federation gives us different work to do, with different consequences when we get it wrong.
The convenient experiment still needs a route into production. Somebody must decide when to replace its key, who will do it and what other work can wait. Until then, keeping the secret safe becomes part of operating the application.
Time-bounded network authentication has a history stretching back through Kerberos. We have better tools than a string you can commit to a repository and then spend the weekend trying to revoke. Vendors can help make those tools the ordinary way to consume a service.
A published discount would give that engineer something useful: a calculable reduction in the API bill to put alongside the migration cost. Security improvements compete for time with features, reliability work and other security improvements. A price signal could change that decision without requiring every team to invent a financial estimate for a future credential leak.
What earns the lower rate
Here is one way I would make the offer concrete. Let a customer enrol a service account in the discounted programme. The vendor checks its federation configuration against published requirements: narrowly matched identity claims, short token lifetimes and limited permissions. Enrolment disables static API key access for that service account. Requests made with its qualifying federated credentials receive the lower rate.
A static key would therefore fail for that account. A customer could still operate other accounts using keys at the ordinary rate, but checking a federation box would not discount those requests. This is a proposed product and billing arrangement, not a description of an existing vendor programme.
The important objection is that federation still gives the application something an attacker can copy. OpenAI's exchange reference describes a bearer token valid for at most an hour; Anthropic also uses bearer tokens. Someone who steals a valid token can use it until it expires. Someone who controls the workload may be able to keep obtaining fresh ones.
That limits what the discount can honestly recognise. Removing the standing vendor secret and shortening the life of a stolen credential are worthwhile changes. They do not establish that every subsequent request comes from the intended machine, and a compromised identity provider or careless trust rule remains dangerous. I would still pay to encourage this migration, but I would not describe the resulting account as theft-proof.
A stronger claim needs stronger proof
The larger discount would require the access token to be bound to a cryptographic key, with proof that the caller possesses that key when it makes an API request. Copying the token alone would then be insufficient. Standards such as DPoP describe this kind of sender constraint, including the checks needed to limit replay.
Hardware protection adds value if it prevents an attacker extracting that private key and using it elsewhere. The vendor would need verifiable evidence of the key's protection. Crucially, the binding must survive through to the API call. Using a hardware-backed key to obtain an ordinary bearer token still leaves that final token copyable. OpenAI's certificate-based exchange illustrates the distinction: it uses mutual TLS during exchange but returns a bearer token. The higher discount would require more than that documented flow provides.
Nor does keeping a key inside hardware stop a compromised application asking it to sign malicious requests. The OAuth security guidance supports protected keys as a defence against offline use of stolen tokens, not as a cure for workload compromise. That narrower benefit is what the larger discount should recognise.
I would keep this option separate. A team ready to remove its standing API secret should be able to receive the first discount without undertaking a hardware attestation project. The additional saving should become available when the vendor can verify the additional protection. It should not depend on a customer's willingness to buy one favoured cloud platform simply because that is the only integration the vendor has made practical.
Share the saving
There is a commercial case for the vendor as well as the customer. A stolen key can consume resources nobody intended to buy, trigger an investigation and leave a dispute over the bill. Where the vendor refunds or waives the charge, it still has to absorb the cost of providing the service and handling the incident. Where it collects, the customer pays for somebody else's usage and has good reason to reconsider the relationship.
This exposure predates the current AI market. Twilio has warned investors that compromised customer authentication credentials and fraudulent usage could harm its financial results. A customer's credential handling can become a supplier's cost.
The offer I would put to vendors is simple: spend less cleaning up avoidable compromise, retain part of the saving, and return part through lower prices for customers who adopt the qualifying controls. The customer gets a financial reason to do the integration. The vendor gets a financial reason to make that integration usable. Both have something to gain from security working.
The discount has to fit the economics. Run a bounded trial and compare the costs of delivering equivalent legitimate usage, including authentication support, integration failures and credential incidents. Account for the fact that early adopters may already be more careful. A refunded retail charge is not the same as the vendor's cost, and federation will not prevent every kind of abuse. The test is whether avoided costs exceed the expense of the programme and the discount. Publish enough of the result for customers to understand the offer.
That uncertainty is a reason to measure, not to leave the incentive untouched. Vendors asking customers to take security seriously should be willing to investigate a business model in which doing so benefits both parties. For a new service, the quickstart and the price list can establish that expectation before copying a key becomes thousands of teams' production design.
A vendor may find that the numbers do not yet work. It should be able to explain what would need to change. A much less acceptable answer is that compromised usage is still billable usage, so preventing it would hurt revenue. That answer makes the customer's poor security practice part of the vendor's commercial interest.
If that is the business a vendor wants to defend, do you really want to be its customer?
(Views in this article are my own.)