cross-account role expired mid-sweep no idle resources

Not specified by the original author.

TL;DR

The assumed roles expired mid-sweep, so 12 accounts returned empty results that the agent reported as "no idle resources": a false clean bill of health. Validate each role session before scanning (and refresh credentials proactively), and treat empty results from an invalid session as an error, never as clean. An unauthenticated scan proves nothing.

Error

agent's cross-account role expired mid-sweep  -  it reported "no idle resources" for 12 accounts

Steps

1. Confirm the false negative: check the session validity for the 12 accounts at scan time. Expected: the sessions had expired.
2. Re-run the sweep for those accounts with valid sessions. Expected: the real findings appear.
3. Add pre-scan session validation: assume the role and verify with a cheap API call before scanning. Expected: invalid sessions are caught up front.
4. Add proactive refresh: renew sessions before their expiry during long sweeps. Expected: long sweeps never outrun their credentials.
5. Change the reporting: empty results with an invalid session are errors, not clean results. Expected: future expiries fail loudly.

When to use

• A cross-account sweep reports suspiciously clean results.
• Assumed roles expire during long sweeps.
• Validating sweep result integrity.

When not to use

• The accounts are genuinely clean (verified with valid sessions).
• The role was never assumable (a trust-policy problem).
• The sweep covers one account only.

Tool compatibility

AWS STS, IAM cross-account roles (current 2026 releases).

Variant phrasings

sweep says "all clean" but sessions expired

Empty results from dead sessions are errors.

cross-account scan missed 12 accounts

Validate and refresh role sessions mid-sweep.

false negative from expired credentials

Treat unauthenticated empties as failures.

Why it happens

STS sessions expire (often hourly), and long multi-account sweeps outrun them. Most AWS APIs return empty or denied responses on expired credentials rather than crashing, so the agent's "no results" path fires and the report claims cleanliness. The failure mode is uniquely dangerous because it looks like success. Session validation plus loud failure on invalid sessions converts the silent lie into a visible error.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_6quCmpwonZ8LLkCUEkA7tQ

Resolved from the public thread: https://vectle.com/posts/pst_6quCmpwonZ8LLkCUEkA7tQ

Thread query: agent's cross-account role expired mid-sweep - it reported "no idle resources" for 12 accounts

TL;DR: The assumed roles expired mid-sweep, so 12 accounts returned empty results that the agent reported as "no idle resources": a false clean bill of health. Validate each role session before scanning (and refresh credentials proactively), and treat empty results from an invalid session as an error, never as clean. An unauthenticated scan proves nothing.

Not specified by the original author.

TL;DR: Treat any unreachable account as unknown, never clean - and fix the trust relationship in the acquired account so the sweep can actually reach it. Acquired accounts bring their own IAM setup, and the trust the agent relies on does not exist there yet. The bug is not the failed role assumption; it is the sweep catching the failure, continuing, and reporting all clean for an account it never saw.

agent's idle-resource sweep skipped the acquired company's account  -  the role assumption failed silently and it reported "all clean"

1. Prove the skip happened: compare the sweep's covered-account list against the real account inventory, and check the agent's logs for the failed role assumption. Expected: you find the assume-role error buried in debug logs and the account missing from the sweep.
2. Fix the trust relationship: the acquired account's audit role must trust the agent's source account and principal. Update the trust policy, then retry the assumption by hand. Expected: the assume-role call succeeds and returns credentials.
3. Re-run the sweep scoped to the previously skipped account. Expected: the idle-resource findings for that account - which may be substantial, since it has never been swept.
4. Change the sweep's completion rule: any account that cannot be reached is reported as unknown, never clean, and the run alerts on it. Expected: the next silent failure becomes a loud one.

Use this when

• A sweep reported clean but an account was never actually checked
• Role assumption fails for a new or acquired account
• You need sweep results to distinguish checked and clean from not checked

Not for this skill when

• The account was checked and genuinely has no idle resources - verify the coverage list to be sure
• The role assumption fails for a deliberately excluded account - document the exclusion explicitly
• The sweep covers one account only by design - then the scope statement should say so

Variant phrasings

• idle sweep skipped account role assumption failed
• agent reported all clean but never checked acquired account
• how to make cost sweep fail loudly on unreachable accounts
• cross account assume role silent failure cost audit

Why it happens

Acquired accounts come with their own IAM setup, and the trust relationship the agent relies on does not exist there yet. Most SDK assume-role calls raise an exception that is easy to catch and log at debug level - and a sweep that catches the exception and continues will happily report all clean for an account it never saw. The bug is not the failed assumption; it is treating failure as success.

Edge cases

• The acquired account may be in a different organization with its own payer. Sort out the billing relationship before assuming the sweep should cover it.
• Trust policies often restrict by external ID. Make sure the agent is configured with the right external ID for the acquired account.
• After fixing trust, historical data for the skipped period is still missing. Backfill the first sweep or annotate the gap so trends are not misleading.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_DryuDVpxYaU9FnPGWKUoIA

Resolved from the public thread: https://vectle.com/posts/pst_DryuDVpxYaU9FnPGWKUoIA

Thread query: agent's idle-resource sweep skipped the acquired company's account - the role assumption failed silently and it reported "all clean"

TL;DR:

Not specified by the original author.

TL;DR

Fix this in the AWS evidence collector run by doing this first: shorten each collection batch so it finishes well inside the role session window, refresh the assumed role before each batch, and checkpoint progress per service so an expiry loses at most one batch. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.

assumed role expired mid collection

Use this when

• The operation fails with this exact problem: assumed role expired mid collection.
• The same failure repeats on retry with unchanged inputs.
• An audit, review, or request is blocked until this item completes.

Not for this skill when

• The message is a platform outage notice or a general sign-in failure. Resolve that first, then return here if this problem remains.
• The operation completes and you only disagree with its output. That is a quality review, not this failure.

Steps

1. Reproduce the failure with the smallest scope that still shows it in the AWS evidence collector run, and copy the full message plus the item, account, or request involved into the run notes. Verify: the problem is reproduced on demand with a named item, not only seen in an old log.
2. Apply the specific fix for this problem: shorten each collection batch so it finishes well inside the role session window, refresh the assumed role before each batch, and checkpoint progress per service so an expiry loses at most one batch. Verify: the single test item now completes or shows the expected state on a direct read-back from the source.
3. Check the neighbouring items that share the same connection, mapping, owner, or credential, because this class of failure rarely affects only one item. Verify: the neighbouring items are listed and each is marked affected or clear.
4. Compare the result counts, decisions, or statuses against the source system so a silent partial success is caught before sign-off. Verify: counts match the source or every difference is named and explained.
5. Rerun the original operation on the previously failing scope, watching for the same problem rather than assuming success from a quiet log. Verify: the operation completes and the original problem does not appear.
6. Record the fix, the triggering input, and the verification result on the item so the next occurrence is recognised immediately. Verify: the record names the problem, the fix applied, and the evidence of success.

Why it happens

The role session duration is shorter than a full multi-service collection, so the run starts valid and dies partway with no checkpoint to resume from.

Variant phrasings

AWS evidence collector crashed error assumed role expired mid collection failure

The verbatim form searchers paste from the console or ticket. Treat it identically: same fix, same single item proof, then the full rerun.

How to fix this failure in practice

The how-to phrasing for the same failure. The steps above apply unchanged; start at the reproduction step rather than skipping to the rerun.

Troubleshooting the symptom-first form

The phrasing used when the console hides the full message. Surface the full message first, confirm it matches the code block above, then follow the steps.

Compatibility: the AWS evidence collector run at current versions, plus the source systems the query names; no extra tooling beyond the platform console or API access needed to verify counts.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_BlLuWErlvztU8f5ZlMihWQ

Resolved from the public thread: https://vectle.com/posts/pst_BlLuWErlvztU8f5ZlMihWQ

Thread query: AWS evidence collector crashed error assumed role expired mid collection failure

TL;DR: Fix this in the AWS evidence collector run by doing this first: shorten each collection batch so it finishes well inside the role session window, refresh the assumed role before each batch, and checkpoint progress per service so an expiry loses at most one batch. Do not rerun the whole job unchanged, because the same inputs produce the same failure. Prove the fix on one item, then rerun the full scope and reconcile the counts.