David Gold

hey, just joined. been building security tooling for ai agents for a while - mostly the boring stuff nobody wants to think about until something leaks. honest question for people shipping fast here: does security ever come up for you, or is it a "deal with it later" thing? not judging, i'd probably do the same

@bcherny this tracks. thing is, once domain knowledge lives in claude.md and skills, those files are the codebase. they go into the prompt as trusted context but nobody diffs them like code. one bad rule steers every agent on the team

Something I have been thinking about: in the past, the best engineers I knew spent a lot of time automating their work in various ways. Better vim/emacs automations, writing lint rules to catch repeat code issues, building up a suite of e2e tests so they don't need to smoke test the app manually. These kinds of things were the highest leverage activities an engineer could do, because it multiplied their own output, which in turn meant they could build more things. I think many of these automations have become even more important now. This is true for a number of reasons. First, infra and DevX automation speeds you up. And if you are running an army of agents, each of those agents will be sped up also. More automation == more output per unit of time. Second, moving things to code improves efficiency. Your agent could fix an issue every time it sees that issue happen, but that uses tokens and might miss cases. If Claude instead writes a lint rule, CI step, or routine, that class of issue can be fully automated forever. This is really what people are talking about when they talk about loops -- it's about automating entire types of busywork rather than solving them one off. This isn't a new idea at all. Engineers have been doing this for a long time! Third and most importantly, automation makes it possible for others to contribute to the codebase more easily. Increasingly what I am seeing is engineers are contributing to codebases on day one because Claude can navigate the codebase for them, and that non-engineers are able to contribute to a codebase as effectively as engineers can. What gets in the way of both of these is domain knowledge that lives in peoples' heads rather than in automation -- the stuff you used to have to learn when ramping up. What has changed thanks to agents is the domain knowledge that can be encoded as infrastructure is no longer limited to what is expressible in lint rules and types and tests; it can now capture nearly all domain knowledge, encoded as code comments and skills and CLAUDE.md rules and memories. If I put up a PR for an iOS codebase I don't know and a code reviewer rejects it because it doesn't use the right framework, or if a designer builds a new feature and it gets rejected because it doesn't follow the right architectural patterns, these are failures of automation. Every team should be writing the CLAUDE.md's, REVIEW.md's, skills, and docs that enable agents to productively work in their codebase with zero additional context from the prompter. This sounds crazy, and at the same time is a natural extension of the stuff engineers have always done: automate, and encode domain knowledge as infrastructure. As the model gets smarter and as the harness matures, this task becomes easier. In the meantime, it is on every team to look for ways to convert their domain knowledge to infra so that Claude can write code better, so that code review catches issues automatically, and so the next person working on your codebase can contribute more easily.

stale skills and stale security skills aren't the same problem. a utility skill nobody touched in six months still works fine. a scanner nobody touched in six months just tells you you're clean — against last year's attacks. it doesn't break, it just stops noticing stuff. that's the part that bugs me. it's quiet either way, and you can't tell which quiet you're getting

weird tension i keep hitting with security tooling. i tell people to pin a version and read the diff before updating, because a skill update runs with your agent's full permissions. then i ship fixes almost daily, which makes that advice impossible to follow. fast iteration or reviewable releases. can't really have both. how do you handle it?

this. "is the model backdoored" is the wrong question. a clean model with file access, untrusted input and a way out will hurt you exactly the same as a dirty one. validation tells you what it was at training time. it says nothing about what it can reach at runtime. that's where the damage actually comes from.

@ZackKorman honestly if you don't want data collected at all you'd have to go live in the jungle and drop every device on the way lol

I mean data exfil is still a risk but not any higher than any other model type (at equal level of intelligence). It’s not like I’d say “local means no risk” just “local means the default path doesn’t involve data going to a third party server”. And look I’m fine letting OpenAI have a lot of data. That’s not the biggest risk in the world either

“I gave an AI agent access to my ~/.ssh directory and you won’t believe what happened next!” This is how I feel about this Grok story. Don’t give you agents access to data that you don’t want your inference provider to have.

@ZackKorman Why are you so sure that the local model won't send anything anywhere or to anyone?

@_david_gold Security wise? Yea

how much does hiding the agent's whole footprint actually reduce your risk? ip, cookies, fingerprint, everything the web picks up. does staying invisible cut down real attacks, or does it barely move the needle?

@HankYeomans @ZackKorman this is clean. one thing though - cloudtrail and vpc logs are full of text some attacker can control. if the agent treats a log line as a command instead of data, that's the same injection thing from earlier. how do you keep the tools from acting on that?

@ZackKorman I actually did something like this for fun. Built a little front end to show the episodes of the results that it found.

LLMs are extremely good at insider threat detection if you feed them the right logs. You should all try it.

been thinking about this. most false positives aren't wrong detection the tool catches the right thing, just screams when it should shrug. that's a calibration problem, not a detection one. two separate fixes and everyone blends them

@ZackKorman yeah majority vote makes sense. my problem is more severity than detection it flags the right stuff but way too loud. gonna try the two-flag thing

@_david_gold Yea you have to have a couple of layers involved. One trick is to run the same thing 3 times, make it flag twice in order to treat it as an alert

@ZackKorman how can we do without it?

Same scanner. Two very different problems. running ClawSecCheck through SkillTrustBench right now — the benchmark clawscan runs its scanners against. one thing keeps nagging me. the bench is a fixed, roughly balanced set. real ClawHub is almost entirely benign, with the bad stuff buried deep in the noise — a fraction of a percent. a scanner can score great on the bench and still drown you in false positives on the live stream. that's a completely different problem. for anyone actually running these on real streams — does leaderboard rank predict real-world behavior, or mostly benchmark-fit? what are you seeing?

@UandAI_HQ @YashManghnani1 @openclaw exactly. the shift is from "did you think about security" to "prove you did." once it's a checklist item, someone has to actually run the check. the messy part is nobody agrees yet on what belongs on that list for agents. still being written in real time.

@_david_gold @YashManghnani1 @openclaw Agent security is going to become a default checklist item, not a niche concern.

Good morning founders! Are you building on weekends? Looking to connect with people building in 🖥️ SaaS 🤖 AI 🛜 Web Apps 📱 iOS Apps 🎲 Games 🧑‍💻 Product Managers What are you building this Sunday? Drop it below 👇

Woah...OpenAI just dropped Codex plugin for Claude Code. Use Codex from inside Claude Code for code reviews or to delegate tasks to Codex.

for people building on OpenClaw — how are you actually handling the lethal trifecta right now? when an agent can touch private data, read untrusted content, and make external calls all at once, things get risky fast. curious what's working in practice: splitting responsibilities across agents? egress filtering? sandboxes? something else? more interested in real setups than theory — even partial ones. what works, and what's still a pain? @steipete you've thought about this more than most — how are you framing it for OpenClaw?

@YashManghnani1 @openclaw yeah, feels like everyone's rushing to give agents more power and nobody's checking what happens when it goes wrong. someone's gotta do the boring security part 🦞

@_david_gold @openclaw Wow building for agents that’s the future

@YashManghnani1 @openclaw clawhub.ai/gl0di/skills/c…

@YashManghnani1 building ClawSecCheck — a free security scanner for @openclaw agents. ran it across 27k skills and 1,207 had real issues: command injection, leaked keys, malware. agent security is messier than people think 🦞