been using claude code heavily for a while now and yeah the memory files are just plaintext sittng in your home directory. no encryption, no access controls. if you're running it on a shared machine or a dev server that's a real exposure. treat it like any other credential file — restrict permissions and don't put it on machines you don't fully control.
AI generated an IAM trust policy for me that looked perfect — correct syntax, right structure, passed review. except the OIDC sub condition was scoped to the entire org instead of the specific repo. any workflow in the org could assume the role. took a week to catch it because it "worked."
i run claude code pretty heavily for overnight sessions and yeah the inconsistency b/w runs is noticeable. same prompt, same codebase, wildly different quality depending on the day. the frustrating part is when it half-finishes something and you come back to a mess you now have to untangle. still the most capable coding agent i've used but the variance is real.
honest take from someone who spends most of their time looking at how orgs actually get breached — the scariest thing isnt what a frontier model can do, but what orgs have already left wide open. i've been auditing CI/CD setups for years and the amount of GitHub Actions workflows running with IAM trust policies that basically say "any repo in my org can assume this production role" is wild. the EC breach started with a compromised trivy download leaking a static API key. no fancy model needed. i'm not saying capability concerns don't matter but there's a massive gap between "what if AI could hack us" and "we haven't even locked down the machine identities we set up 3 years ago and forgot about"
The part that worries me most isnt AI-generated malware- its AI agents getting their own cloud creds. we're already seeing OIDC trust policies being setup for bedrock and copilot agents with the same 'make it work and move on' attitude that created the static credential problem in CI/CD pipelines. the EC breach happened because a static API key sat in a pipeline untouched for months. Now imagine that same negligence but with the autonomous agents that can act on those creds without human intervention.
Lived this many times. the worst part about these freezes is what happens right before the freeze - everyone will rush to push their changes prior to cutoff, which is exactly when you get the sloppiest commits. and then after the freeze lifts you get a flood of piled up changes all at once. Smaller, continuous deploys with a good rollback are way less risky than big batched releases after a freeze.
great find, irony of a security scanner being the attack vector is brutal. For those who havent read it: attackers poisoned Trivy(widely used vulnerability scanner), which gave them a static AWS API Key from the EC's CI pipeline, leading to 92GB of stolen data across 30+ EU entities.
The root cause is painfully common: long-lived API keys with broad access sitting in CI/CD pipelines that nobody revisits after setup. most orgs treat pipeline creds as a on-time config, not an ongoing security surface.
Nice approach. Confidence scoring on what's the safe one to delete is smart, and that's the hardest part of any cleanup tool. How are you handling false positives?
I've been thinking about similar confidence scoring in a different domain (security) and the calibration is really tricky when the cost of getting it wrong is high.