Skip to main content
← Back to list
01Issue
BugClosedExtensionsPublic
Assigneesstack72

Relationships

#1979 target-domain create/get fail with "security token expired" using valid fresh SSO creds; identical raw AWS CLI call succeeds

Opened by acameron17 · 9/3/2026

Description

create and get methods on the @swamp/aws/securityagent/target-domain model type fail with The security token included in the request is expired, even though the AWS SSO session credentials used are freshly minted and independently verified valid.

Steps to reproduce

  1. Assume a fresh AWS SSO role session (assume <profile>), confirmed valid via aws sts get-caller-identity in the same shell — succeeds.
  2. Run swamp model method run <target-domain-model> create --json in that same shell.
  3. Observe: {"error": "The security token included in the request is expired", "code": "method_execution_failed"}.
  4. Run the identical operation directly against AWS Cloud Control API, same shell, same credentials: aws cloudcontrol create-resource --type-name AWS::SecurityAgent::TargetDomain --desired-state '{"TargetDomainName":"...","VerificationMethod":"DNS_TXT","Tags":[...]}' — succeeds immediately (OperationStatus: SUCCESS).
  5. Run get on the model with the resulting resource identifier — same "security token included in the request is expired" error.

Environment

  • swamp version/sha: 20260817.010424.0-sha.21133ea1
  • Model type: @swamp/aws/securityagent/target-domain
  • Debug log (--log --log-level debug) confirms the model wires zero vault/env CEL expressions for credentials ("Runtime expression resolution: 0 total expressions, 0 runtime (vault/env)"), so the extension relies entirely on the AWS SDK default credential provider chain (ambient env).
  • Ruled out: stale/leftover AWS_SESSION_TOKEN in shell (checked via env | grep -i aws, values fresh and matched AWS_SESSION_EXPIRATION ~12h out), local clock skew (checked via date/date -u, matches wall clock), a stuck/orphaned Cloud Control resource request from a prior attempt (aws cloudcontrol list-resource-requests returned none), and a local swamp daemon holding stale env (ps aux | grep swamp found none).
  • The failure reproduces identically on both create and get, which use the same underlying Cloud Control client path, while the AWS CLI using the exact same session succeeds — pointing at the extension's AWS SDK client construction/credential resolution for the SecurityAgent Cloud Control provider specifically, not at the caller's credentials.

Impact

Blocks provisioning any AWS::SecurityAgent::TargetDomain (and likely agent-space/pentest, same extension family) resource through swamp when using AWS SSO/Identity-Center-derived session credentials — the common case for interactive use.

Upstream repository: https://github.com/swamp-club/swamp-extensions

Environment

  • Extension: @swamp/aws/securityagent@2026.08.21.1
  • swamp: 20260817.010424.0-sha.21133ea1
  • OS: darwin (aarch64)
  • Deno: 2.8.3
  • Shell: /bin/zsh
02Bog Flow
✓OPEN✓TRIAGED○IN PROGRESS◉CLOSED+ 1 MOREASSIGNED+ 3 MOREREVIEWAPPROVAL

Closed

9/8/2026, 4:40:27 AM

No activity in this phase yet.

03Sludge Pulse
stack72 assigned stack729/8/2026, 4:06:12 AM
Editable. Press Enter to edit.

acameron17 commented 9/3/2026, 1:25:11 PM

Update: this is broader than the @swamp/aws/securityagent extension. The identical "The security token included in the request is expired" failure now also reproduces on @swamp/aws/route53/record-set create, using the same freshly-assumed AWS SSO session, independently re-verified valid via aws sts get-caller-identity in the same shell at the same moment the swamp call failed.

Since this reproduces across two unrelated @swamp/aws/* extensions (securityagent and route53), the root cause is more likely in a shared swamp-core AWS credential-resolution layer used by generated extension model types, rather than in either extension's own code. Worth investigating there rather than treating this as an extension-specific bug. Happy to help narrow it further if useful — can reproduce reliably.

stack72 commented 9/8/2026, 4:40:27 AM

Hey @acameron17 — thanks for the detailed report. We investigated this thoroughly and here's where we landed.

What we verified:

  • The generated _lib/aws.ts for SecurityAgent is identical to every other AWS CloudControl model (~249 services) — nothing SecurityAgent-specific in credential handling.
  • We tested the AWS SDK v3 default credential chain end-to-end through swamp's runtime and confirmed it correctly resolves all three credential env vars including AWS_SESSION_TOKEN. The session token is present in outgoing requests.

We couldn't reproduce the failure. The extension code and credential chain appear correct.

What we'd suggest:

  • Update to the latest extension version (swamp extension update @swamp/aws/securityagent) — you're on 2026.08.21.1 and the current version has an improved region resolver that properly follows source_profile chains and sso_session blocks in your AWS config, which may fix a region mismatch that could surface as a misleading credential error.
  • Confirm AWS_REGION is set explicitly in your shell to the region where SecurityAgent is available.

If the issue persists after updating, reopen this and we'll dig in further — it'd help to know whether other AWS models (e.g. @swamp/aws/s3/bucket) also fail with the same credentials, and a --log --log-level debug capture of the failing run so we can see exactly where the error originates.

Sign in to post a ripple.