When agentkit auth admin sso-setup / publish is run with temporary
credentials (VOLCENGINE_ACCESS_KEY / VOLCENGINE_SECRET_KEY /
VOLCENGINE_SESSION_TOKEN), every OpenAPI-based provisioning step
succeeds, but publish_discovery() constructs the TOS client with only
AK/SK and drops the session token. A temporary AK without its session
token is invalid, so TOS rejects the request with 403 InvalidAccessKeyId.
Fix by threading the session token through:
- publish_discovery() accepts a session_token parameter with the same
VOLCENGINE_SESSION_TOKEN env fallback used for AK/SK, and passes it
to tos.TosClientV2 via security_token.
- sso_setup() forwards session_token=api.token so the publish step uses
the same credentials as the earlier provisioning steps.
Backward compatible: with long-lived AK/SK the token is None and
behavior is unchanged.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
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:
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:
A temporary access key is invalid without its session token, so TOS rejects the request.
Fix
Three small changes to agentkit/auth/admin.py:
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:
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