Give Partner Agents Scoped Credentials That Expire

According to The Hacker News, the attacker in the Klue incident seems to have used a long-disused but still active credential, one created to prototype an integration that was later abandoned.

The attacker obtained OAuth tokens customers had used to connect the vendor to third-party platforms, then queried customers' CRM data. Salesforce disabled the app integration and said the issue didn't arise from a vulnerability in its platform.

Make the credential fit the work

Name the operations. A partner doing lookups might require read_customer_record and list_orders. Its credential can be limited to those calls, with a later request to change customer data treated as a new permission decision.

A partner credential has:

• A separate identity for that partner.
• Scope limited to named operations the integration requires.
• An audience bound to your service.
• A short-lived access token, with rotating refresh tokens where they're used.
• A named owner and an end date tied to the work.

Separate credentials let a prototype end independently. Revoking its access leaves another partner's integration with its own credential and agreed permissions. The person closing the pilot can identify exactly which access belongs to that work.

Check which service the token is for

When an MCP server uses the spec's HTTP authorization, the client must send a resource parameter naming the server it wants to reach. The June 2025 revision of the MCP authorization spec requires the receiving server to validate that the token was issued specifically for it as the intended audience.

For example, a token issued for a file service isn't authority to call your CRM service. The CRM service checks its own expected audience when deciding whether to accept the token. That check makes the intended service part of the access decision at the receiving end.

The same revision prohibits passing a received token through to upstream APIs. If the MCP server reaches another system to complete the partner's task, that connection has its own authorization.

A review limited to the token presented at the front door can miss the upstream credentials. Account for what the server can reach on the partner's behalf when agreeing the pilot's access.

Expiry has to cover the renewal path

The cited revision recommends short-lived access tokens and requires refresh-token rotation for public clients using its authorization. A refresh token lets the client obtain further access tokens.

Suppose an access token expires after an hour while its refresh token still works. The integration can obtain a replacement and continue.

So the access plan has to explain how renewal ends when the pilot ends. Rotation belongs in that plan, along with a way to revoke the access the partner still holds. Check what remains usable after revocation, including refresh tokens issued by rotation and credentials for any upstream connection.

Close access when the experiment ends

A compact inventory connects each partner's credential to its scope and the work's end date, with the owner named in the same entry. That makes temporary access visible when the team reviews ongoing integrations.

A completed or abandoned pilot closes with its credential revoked. If the work continues, its inventory entry gets a new end date and a reason for retaining those permissions.

For a paused pilot, revoking the credential makes the pause apply to access as well. Restarting the work then calls for a new access decision, with the operations and expiry agreed for that phase.