fix(auth): support STS session token in sso-setup / publish discovery step - #139

Problem

Running agentkit auth admin sso-setup (or agentkit auth admin publish) with temporary STS credentials (VOLCENGINE_ACCESS_KEY / VOLCENGINE_SECRET_KEY / VOLCENGINE_SESSION_TOKEN) fails at the final "publish discovery doc to TOS" step:

TosServerError: 403 InvalidAccessKeyId
The Access Key Id you provided does not exist in our records.

All earlier provisioning steps (UserPool, CLI client, OIDC provider, STS role, ...) succeed because OpenApiClient (agentkit/auth/_openapi.py) already reads VOLCENGINE_SESSION_TOKEN and includes it in the SigV4 signature. But publish_discovery() in agentkit/auth/admin.py builds the TOS client with only AK/SK:

client = tos.TosClientV2(ak, sk, endpoint, coords.region)   # session token dropped

A temporary access key is invalid without its session token, so TOS rejects the request.

Fix

Three small changes to agentkit/auth/admin.py:

1. publish_discovery() gains a session_token parameter with an env fallback (VOLCENGINE_SESSION_TOKEN), mirroring the existing AK/SK handling.
2. The token is passed to the TOS SDK via security_token:

   client = tos.TosClientV2(ak, sk, endpoint, coords.region, security_token=token)

3. sso_setup() forwards session_token=api.token, so the publish step uses the same credentials as the provisioning steps.

The env fallback also fixes agentkit auth admin publish, which calls publish_discovery without explicit credential arguments. Fully backward compatible: with long-lived AK/SK the token is None and behavior is unchanged.

Verification

With temporary credentials configured, a read-only head_bucket call against the affected bucket (agentkit-cli-<account_id>) using the same AK/SK:

• without session token (pre-fix behavior): TosServerError 403, matching the original failure;
• with session token (post-fix behavior): succeeds.

After the fix, re-running sso-setup completes; the command is idempotent and reuses previously created resources, only finishing the failed publish step.

Related observation (not addressed here)

create_bucket errors are treated as "bucket already exists" when the message contains Exist/exist. The auth error message "...does not exist in our records" matches that keyword, so the create_bucket failure was silently swallowed and only surfaced at put_object. Worth hardening separately by matching error codes (BucketAlreadyExists / BucketAlreadyOwnedByYou) instead of message keywords.

🤖 Generated with Claude Code