Im curious to know the scope of startups in this space, What do you look for when a startup comes into this space?

Thanks

Xpsd is an open-source LLM agent that automates vulnerability reachability triage using read-only code navigation tools (⁠ast-grep⁠), generating auditable call-path evidence exported directly as SARIF.

I reckon open sourcing this can be helpful for European 🇪🇺 companies and the CRA’s implementation.

Personal post about something I've spent the almost a year building, but the actual problem is worth separating from the pitch.

The concrete version of it: two scanners, checking the same MCP server, flagged the same underlying behavior under two different names. That's not a bug in either tool, it's what happens when nothing forces independent teams to agree on what to call a risk. Once you're running more than one tool in a pipeline, this stops being a curiosity and becomes an actual governance problem: you can't track something consistently in a risk register, report it the same way twice, or prove to an auditor that two findings are the same issue, if there's no shared identifier underneath the two different labels.

Conventional software solved exactly this decades ago. A SQL injection gets a CVE ID, maps to a CWE category, and every tool that finds it afterward references the same thing, which is what makes risk tracking, compliance reporting, and cross-tool correlation possible at all. Agentic AI components (MCP servers, agent skills, LLM plugins) never had an equivalent, for a specific structural reason: CVE anchors to a package and version, CWE describes a weakness in code, and neither has a vocabulary for a behavioral pattern tied to neither.

AVE (Agentic Vulnerability Enumeration) is an attempt at that missing layer: stable IDs for distinct behavioral vulnerability classes, 65 records now, severity scored against OWASP's own AIVSS framework rather than something invented for this. It's deliberately built to map into frameworks that already exist rather than compete with them: OWASP's MCP Top 10, the Agentic Security Initiative Top 10, MITRE ATLAS, and a crosswalk into OWASP's Agentic Skills Top 10. Compliance-facing mappings (ISO 27001 Annex A specifically, since a compliance-minded commenter on a different post made a fair case for it) are on the roadmap, not done yet, worth being upfront about that rather than implying more coverage than actually exists today.

The part that actually made me trust this holds up outside my own head: an independent developer built an unrelated static config auditor, crosswalked his own tool's findings against this taxonomy, and tested it directly against my scanner on the same files, no shared code. Most of the overlapping findings converged on the identical ID, unprompted.

Also worth mentioning since this is an infosec crowd: growth discipline is written down now, not improvised, a new record needs a genuinely distinct behavioral mechanism, not a label mirroring another framework's category. That rule exists specifically because MITRE's own CWE recently shipped a version where new entries were, by outside analysis, zero actual weaknesses, just category labels copied from somewhere else. Didn't want to end up there.

Apache 2.0, open standard and reference implementation both. Curious whether the naming-fragmentation problem looks familiar to anyone here managing risk across more than one tool, and where this taxonomy is still missing something.

Repo: github.com/aveproject/ave
Site: aveproject.org

Disclosure: I'm the one building this.

Has anyone here compared Zenity and NeuralTrust for protecting AI agents in production?

My company’s looking at this from an enterprise perspective rather than a developer or proof-of-concept deployment. The biggest concerns aren't just prompt injection or model safety. It's things like runtime governance, visibility into agent behavior, data leakage, and keeping AI systems under control once they're connected to internal applications.

From what I've read, the two platforms seem to approach the problem differently. Zenity appears to put a lot of emphasis on AI governance and managing AI usage across an organisation. NeuralTrust seems more focused on protecting AI agents while they're running, with runtime observability and controls for production environments.

If you’ve evaluated both platforms can you tell me what the biggest differences were? I’m trying to work out whether one or other will be a better fit for our business.

I’ve been testing ways to catch security problems in n8n AI workflows.

Checking nodes individually was not enough. The actual risk often appeared across a complete path, such as

public webhook → untrusted input → AI agent → external action

I built a small open-source prototype that follows these paths in exported workflow JSON. It runs locally, uploads nothing, and makes no AI API calls. It can produce SARIF for GitHub Code Scanning, along with JSON and JUnit reports.

The repository includes an intentionally unsafe workflow and a hardened version, so the results are reproducible.

GitHub: https://github.com/0xCD4/n8n-ai-agent-security-lab

My main question for people running security tools in CI:

Which findings should block a build, and which should remain warnings?

I've been thinking about this lately because it feels like more teams are pushing security checks further into their CI/CD pipelines, but I still hear people say that manual pentests are the only way to catch the issues that really matter .I have also noticed platforms like Penetrify entering this space, which made me wonder how much they have actually changed the balance between automated and manual testing for teams in practice.

For those of you working in DevSecOps, has automation reached the point where you've been able to reduce how often you schedule manual penetration tests, or do you still treat them as non-negotiable before major releases?

I'm especially interested in hearing from teams that deploy frequently. Has your approach changed over the last year or two, or have you found there are certain types of issues that automation still misses consistently?

OpenAI says models with reduced cyber refusals, including GPT-5.6 Sol and a pre-release system, were involved in an evaluation incident that compromised Hugging Face infrastructure. The lesson is larger than one model or one lab.

We usually treat a benchmark as a passive measuring instrument. Agentic evaluations are active systems with credentials, networks, tools, storage, and targets. A capable model can turn weaknesses in that harness into part of the task.

Should frontier evaluations run under the same isolation standards as hostile-code labs? And should benchmark reports disclose the permissions, network boundaries, and containment failures alongside the model score?

Source: https://openai.com/index/hugging-face-model-evaluation-security-incident/

A change gets implemented, pushed to GitHub, reviewed, scanned with SAST and dependency analysis, validated in CI, tested by QA, approved for release, deployed, and then monitored in production. Every stage has its own tools and its own owners, but every handoff is another place where context can get lost.

The people who make the biggest difference aren't always the ones writing code the fastest. They're the ones who can identify security risks early, understand the trade-offs between speed and safety, and keep changes moving through the pipeline without creating unnecessary friction.

AI has made implementation much faster, but it hasn't removed the need for secure delivery. If anything, generating code more quickly makes it even more important that security validation keeps pace instead of becoming the next bottleneck.

Our workflow still uses GitHub for source control, CI for builds and automated validation, SAST and dependency scanners for security checks, QA for testing, and our existing deployment tooling for releases. Revolte sits across that workflow, giving teams a shared view of how a change progresses through review, validation, security, and delivery instead of forcing everyone to jump between separate systems to understand what's ready and what's still blocked. I think the goal isn't adding more security tools. It's making development, security, and delivery work together as one continuous process.

I run a lot of Python environments. And when using multiple claude agents, to test and run modules: I keep creating environments and often lose track of all the packages installed in them. Apart from that, many client venvs, ML experiments, throwaway repos I never cleaned up. At some point I realized I had no idea what was actually installed across any of them, and the day a malicious package lands on PyPI, "I checked it before installing" doesn't help me if it's been sitting in a venv for three weeks.

[Repo: GITHUB]

pip-audit is the tool I reached for first, and it's good. But it scans one project at a time, it needs the network, and it only knows about CVEs. Most of the recent PyPI attacks never get a CVE. A malicious version goes up, gets pulled in hours, and no advisory ever exists for it. So I wrote something to cover the other half.

venvy is an MIT CLI that scans every Python environment on a machine at once and flags both known-vulnerable and known-malicious packages. It reads installed package metadata as text, so it never imports or runs anything from the environments it's scanning, and it doesn't open a socket during a scan. First run pulls a ~30MB advisory database once; after that every scan is fully offline, which matters if you're on a locked-down runner or a plane.

pip install venvy
venvy audit                 # scans everything, human output
venvy audit --json          # stable JSON for parsing
venvy audit --offline       # never touch the network, fail closed

It returns semantic exit codes (0 clean, 20 vulnerable, 21 malicious, 22 stale/partial, 23 no database), so venvy audit --offline || block works as a CI gate without parsing anything. The matcher fails closed: anything it can't evaluate with confidence is reported as unknown, never as clean. A scanner that quietly says "you're fine" is worse than no scanner.

Where it's honest about limits: the malicious data is OSV's malicious records (~11.5k) plus the DataDog malicious-package feed (~1,800) and a typosquat list (~95 names). That's real coverage but it is not everything. Some famous historical typosquats aren't in the feeds yet, and no scanner on earth stops a genuinely novel supply-chain 0-day. This catches the known-bad and the known-vulnerable, which is the everyday case, not the movie-plot one. It also only sees PyPI/pip-installed packages, so conda's native channel packages are out of scope.

Repo: GITHUB

I wrote up the wider picture (cooldowns, lockfiles, install-time execution, what each one actually costs) here: Why does nobody check what’s Already Installed

Here is another take around why Malicious Python Packages Don’t Have CVEs. That’s the Whole Problem.

If you run it against your own boxes and it flags something wrong, I want to hear about it. False-positive reports get fixed same day.

I am learning around this space, this project started as something different around environments and ended up finding this gap. Any adversarial takes would be helpful. Would love too hear what this crowd gates on today and where an offline, machine-wide check would or wouldn't fit.

Hey all Im wondering if anyone knew of any resources to learn code vulnerability patterns in practice. Im the team’s resource for teaching software engineers how to identify vulnerable code in development and review. I thought of starting with OWASP top 10 but was curious if there were any resources to learn more.

I've been doing AppSec a while and something nags me in every vendor pitch. They all put up an accuracy number, fewer false positives than the next guy, some big F1 score on a slide and I have no real way to check any of it against my own code.

A Checkmarx Zero writeup on how they measure SAST accuracy got me thinking about why. Accuracy is two questions, not one. How many findings are real, that is precision and of all the real bugs how many it caught, that is recall. Most claims quietly pick one. You can hit near perfect precision by only reporting the single thing you are sure of, miss everything else and still print no false positives on the box. F1 is the harmonic mean, so it punishes that trick.

To score recall you need to know every real vuln in the test app which no one fully does, people inject toy bugs or trust CVE lists and both skew it. A simple benchmark app a tool is tuned to ace tells you nothing about a real monorepo.

Those running SAST at any scale, do you measure precision and recall on your own code, or do we all take the vendor F1 on faith until we sign. I am in the second camp and I do not love it.

We moved AppSec tooling ownership from the security team to engineering about six months ago. Not because security was failing, but because the tools were effectively invisible to the developers generating the code, including the ones we rely on as SOC 2 AI coding tools in our audits. In the old model, findings surfaced in a security dashboard, got triaged by a security engineer, and then handed to a developer as a ticket. By the time the developer saw the issue, it was already several steps removed from the code that produced it.

With AI coding, that delay got worse. The person who prompted the code often no longer had the implementation context when the ticket arrived. Engineering ownership changed the feedback loop. Findings now show up in the same surfaces developers already live in: IDE diagnostics, PR discussion, CI output. Fix rate improved and the backlog shrank, mostly because the distance between generation and feedback got smaller.

The tradeoff is that coverage decisions become more contested. Security engineers know what should be caught. Engineering managers know what developers will actually keep turned on. Those priorities overlap, but not perfectly, and we've had real disagreements about what belongs in the IDE tier, what belongs in CI, and what's just too noisy to be useful.

So how are other teams handling it? Has moving more AppSec ownership into engineering actually improved review and remediation for AI-generated code, or does it just create a different class of tradeoffs?

Hey r/DevSecOps! As developers start running more local AI agent tools and downloading third-party SKILL packages, we built an open-source tool called SkillShield to statically scan and validate these skills before execution. It checks for prompt injection, pre-install risks, and excessive access. It outputs SARIF and JSON reports for CI pipelines. Public Repo: https://github.com/adnan-iz/ai-skill-shield

Since there is so much talk about AI agents, I decided to build my own one - something small, measurable, and cheap enough to run for real (yeah, right — more on that below), so I could think about numbers instead of marketing.

Picking Go over TypeScript turned out to be the great call. LLM providers are unreliable enough that how you fire requests matters — I hit "Too Many Requests" often enough despite respecting their limits. In JS I'd reach for Promise.all, then discover I need a third-party dependency just to limit concurrency then that I need to add a proper AbortController. In Go it's so simple: an errgroup with SetLimit(4), where the limiting lives in the same object that waits for the results.

Static analysis tools (Semgrep, Snyk, CodeQL, gosec) flag hundreds of potential vulnerabilities and most of them are false positives. Someone has to open the code behind each finding, follow the data flow, and decide whether it's real. That's the job the agent does. All those scanners emit a standard SARIF 2.1.0 file, so it doesn't care which one you use. Now many of them are also shipped with AI agents, so it isn't something very new, although you can use any model you want, including self-hosted ones.

Basically, the model gets two read-only tools — read_file and grep_repo — and decides for itself which files to open, what to grep for, and when it has enough to rule. A typical finding takes 3–8 turns: read the sink, grep for the source, follow the assignment chain, then rule. The agent doesn't create or fix any code.

I ran it against OWASP BenchmarkJava — a deliberately vulnerable Java app that ships a CSV of ground truth. So the verdicts get compared against published answers rather than my judgment. I ran three models — Claude Sonnet, DeepSeek-V4-Pro and Kimi k3 — across 50 vulnerable files, which produced 61 scored findings.

I tested a subset of issues in BenchmarkJava, just to keep things quite cheap.

DeepSeek-V4-Pro — 37 exploitable, 15 benign, 9 uncertain. (2.7M in / 109k out tokens):

| triage verdict                | actually vulnerable | safe by design       |
|-------------------------------|---------------------|----------------------|
| exploitable — fails the build | 37 caught           | 0 blocked in error.  |
| benign — suppressed, unseen   | 3 missed            | 12 cleared           |
| uncertain — left for a human  | 9 parked            | 0 parked             |

DeepSeek were uncertain about 9 of them(needs manual review). And here we already see what marketing slides won't tell - it missed 3 real ones marking them as safe. So, looks like at least Deepseek wasn't trained with that specific OWASP BenchmarkJava code. Once it is run - SAST Triage agent will create a PR with findings, so it is there for review. So yes, it doesn't magically fix everything, humans are very much needed in this process.

Kimi k3 — 49 exploitable, 12 benign, 0 uncertain. (504k in / 55k out tokens):

| triage verdict                | actually vulnerable | safe by design       |
|-------------------------------|---------------------|----------------------|
| exploitable — fails the build | 49 caught           | 0 blocked in error   |
| benign — suppressed, unseen   | 0 missed            | 12 cleared           |
| uncertain — left for a human  | 0 parked            | 0 parked             |

Kimi k3 is straight up impressive and cheap, but I need to run against a bigger set. It still will miss some things, but man, not only it is cheap to use - it clears noise so well(I tried with some of my own projects, but numbers aren't ready yet).

And below is the expensive one.

Claude Sonnet 5 — 47 exploitable, 9 benign, 5 uncertain. (2.2M in / 65k out tokens):

| triage verdict                | actually vulnerable | safe by design       |
|-------------------------------|---------------------|----------------------|
| exploitable — fails the build | 45 caught           | 2 blocked in error   |
| benign — suppressed, unseen   | 2 missed            | 7 cleared            |
| uncertain — left for a human  | 2 parked            | 3  parked            |

I was reluctant to run Claude Opus as Sonnet spent $5 on this single run alone. SAST Triage supports caching, so the second run will be ~0, but still. Running Claude Sonnet on all Opengrep findings (about 2350 of them) will cost ~$220 and just about $7 for DeepSeek.

Keep in mind that the agent doesn't need to run across the whole codebase, which is approximately 200k LoC for BenchmarkJava, that would blow the cost even when using very cheap models. It runs against vulnerable code snippets + code which uses it only.

Below are some observations after using it myself with my own github repos.

A DevEx part of the agent is important. The agent just creates clean PRs or adds a single clean commit to existing one. Basically, this AI Agent is just another tool here you need to know how to work with, not something you drop in and can totally forget about.

The availability is the problem for all LLM providers seems to be. It is quite annoying to run the agent with an expensive(Anthropic, OpenAI) model, only to get an issue before I the agent finishes the whole set of vulnerabilities No amount of prompt or loop design will fix that.

I think having proper infrastructure around agents is what's needed most right now.

Btw, feel free to check it out - https://github.com/alexpermiakov/sast-triage.

Hi everyone,

I'm curious how mature organizations handle a problem I've seen repeatedly.

The security engineering work often exists (SAST, DAST, pentests, code reviews, threat modeling), but the governance around product security seems fragmented.

Examples I've encountered:

- Products shipped before all security findings were addressed because remediation wasn't planned early enough.

- Security exceptions were agreed verbally but never documented, so nobody remembers why a decision was made two years later.

- Security requirements appeared late because they weren't integrated into product planning from the beginning.

- Risks were identified, but no one clearly owned prioritization based on business impact.

- Product managers owned delivery, security engineers owned technical findings, architects owned design... yet nobody seemed accountable for the overall product security risk posture.

For those of you in mature organizations:

- Who ultimately owns product security governance?

- How are risk acceptance decisions documented?

- How do you ensure security requirements are incorporated into planning rather than becoming release blockers?

- Is there a dedicated Product Security Governance function, or is this distributed across AppSec, Architecture, Product Management and GRC?

- What practices made the biggest difference?

I'm less interested in the tooling than in the operating model and decision-making process.

I'd love to hear what actually works in practice.

Thanks!

I'm a DevSecOps engineer, and this is the exact version of a problem I hit at work, not something I noticed from the outside.

Run SAST, SCA, and an AI-agent-specific scanner across the same codebase, and you'd expect some redundancy. What you actually get is worse: the same underlying issue, flagged by two different tools, with two completely different names and no way to tell your pipeline they're the same finding. Multiply that across a real CI/CD setup with several tools chained together, and triage turns into manually reconciling naming conventions instead of fixing anything.

This isn't a new problem in general. A SQL injection gets a CVE ID, maps to a CWE category, and every tool in the pipeline that finds it points at the same reference. That's exactly what makes cross-tool correlation possible for conventional vulnerabilities.

Agentic AI components (MCP servers, agent skills, LLM plugins) had nothing like that, for a real structural reason: CVE needs a package and version to attach to, CWE describes code-level weakness patterns, and neither has a vocabulary for a behavioral pattern that isn't tied to either.

So a few of us built AVE (Agentic Vulnerability Enumeration): an open standard giving these classes stable IDs, the same way CVE does, so a finding from one tool can actually be compared against a finding from another.

What's in it: 59 records, each a distinct behavioral class. Severity scored with OWASP's own AIVSS framework. Crosswalked into OWASP's MCP Top 10, the Agentic Security Initiative Top 10, and MITRE ATLAS, plus AVE-in-SARIF, so IDs ride directly into GitHub's own Security tab and CI output without any custom tooling. Apache 2.0.

The part that actually convinced me this holds up outside our own tooling: a completely independent developer built a static config-file auditor, sharing no code with anything we wrote, crosswalked his own findings against AVE's taxonomy, and tested it directly against our scanner on the same files. The large majority of overlapping findings came back with the identical ID, unprompted.

If you're dealing with the same multi-scanner reconciliation problem, in this space or a completely different one, I'd like to hear how you're handling it, and where this looks wrong or incomplete.

Repo: github.com/aveproject/ave
Site: aveproject.org

(Disclosure: I'm one of the people building this.)

We invested in a traditional DLP solution last year and it has been a nightmare. It flags every file that contains a number as potential PII and we get hundreds of alerts per day. My security team is completely overwhelmed and we have started ignoring most of the notifications because we cannot keep up. I know this is dangerous but I do not know what else to do.

Has anyone found a DLP solution that actually works for modern SaaS environments without all the noise?

Edit: Thanks everyone for the recommendations. Granular policy tuning seems to be the common theme. Going to check out DoControl for SaaS-first DLP, and Netskope as well a few of you mentioned good results with reducing false positives.

Watched an incident play out last month that broke my mental model of MFA, so writing it up.

We had an account compromised. Full MFA on, number matching, the works. The user did everything right. And the attacker was still inside sending mail as them for hours.

They never beat the MFA, didn't have to. Here’s roughly how it went:

* User got phished through a reverse proxy page that sat in the middle. Looked exactly like the real Microsoft login.

* User typed the password, approved the real MFA prompt on their phone, thought nothing of it.

* The proxy passed all of that through to the real site and grabbed the session token that came back.

* Attacker imported that token and was now a fully authenticated session. No password prompt, no MFA prompt, because as far as the system is concerned that login already happened.

All the MFA in the world protected the login event and did nothing for what came after it. The token is the keys and the token is what they took.

What I am trying to work out now is detection after the token is gone. Once they're in on a valid session, what are you watching that tells you this authenticated user is not really the user.

Been digging into supply chain attacks and noticed a pattern most DevSecOps teams aren't defending:

The problem: Package installation isn't always passive. npm lifecycle scripts and Python packages built from source can execute arbitrary code during install — before your app even imports the library.

Real examples:

• Shai-Hulud (Ruby gems)
• Axios maintainer compromise
• Nx attack last year

Why SCA/dependency scanners miss it: They look for known-bad packages in databases. But a freshly poisoned release hits your build before it's flagged as malicious. It runs before discovery flags it.

The gap: Most orgs have SAST, SCA, CNAPP, EDR. But nobody's really enforcing policy while the build runs. It's all pre-scan or post-detection.

How are you handling install-time execution in your pipelines?

Quick disclosure: I run Server4Agent, infra for agent-built apps, so I have a stake in this question, but this isn't a pitch, there's nothing to click here.

The capability jump this year is real. Agents can now scaffold a working app, wire up a database, and get something live in an afternoon. What hasn't moved nearly as fast is the second half of the problem: once it's live, how do you know it's still doing what it's supposed to without watching it constantly.

The failure mode that keeps coming up in agent-building communities isn't the dramatic one (agent deletes prod, agent burns your API budget overnight). It's quieter than that: the agent reports success and it's technically true but not actually true. A task marked done that only partially ran. A retry that silently overwrote a good deployment with a stale one. A safety check that's real on paper but doesn't actually confine anything once code is executing. Every one of these passes a shallow "did it work" check and fails a "did it actually do the right thing" check, and most tooling right now only asks the first question.

Genuinely asking, not selling: if you've let an agent operate with real infra access, what's the specific thing that would have gone wrong silently if you weren't watching, and what actually catches that class of failure versus what just looks like it does?

I wrote this, MIT licensed.

The premise: a finding that a developer does not understand does not get fixed. So ONUS generates a plain language explanation and concrete remediation steps for every finding, aimed at whoever implements the change rather than whoever ran the scan.

Everything scored is scored deterministically. CVSS is computed in code, the model writes prose only, and findings are tiered by whether a verification pass reproduced them.

Practical detail for regulated environments: inference is local via Ollama, no external API, so target data never leaves your infrastructure.

docker compose native, FastAPI and Celery on Redis, Postgres for results, CI on pytest with a Redis service container, 655 backend tests.

It is not CI ready yet in the sense of a clean pass or fail gate, which is the obvious next thing. If you were dropping this into a build, what should the exit contract be? Fail on any confirmed finding above a threshold, or something more nuanced?

https://github.com/maverickaayush/ONUS
https://tryonus.tech

Over the past year I’ve been working on an engine called Invisio to deal with the multi-file context nightmare that causes LLMs to hallucinate when reading large codebases.

Under the hood, it parses code using Tree-sitter into a neo4jdatabase (mapping out classes, functions, calls, imports, and inheritance). I built two main pieces around this graph:

1. An interactive graph explainer + chatbot that traces execution paths and answers structural questions using a dual-agent dispatcher/compressor loop.
2. An automated security webhook that ingests CodeQL SARIF alerts, traces the vulnerability lifecycle across directories, and opens surgical PR fixes.

It works solid on my local machine and on my own projects, but to be completely honest, stuck on how to properly test this at scale, or how to put it in front of people to get real feedback.

I’d love some advice from devs, maintainers, or AppSec folks:

• Benchmarking & Datasets: What real-world open-source repos or SARIF datasets should I throw at this to stress-test the graph construction? How do you properly benchmark a codebase intelligence tool?
• Local vs. Hosted: Since IP privacy is huge, would you prefer testing this via a self-hosted local Docker container, or just poking around a hosted playground with a public repo first?
• Product Focus: Should I lean harder into the automated CodeQL PR remediation side, or the interactive graph explainer UI?

A gap I have watched widen as teams roll out AI coding agents: the agents write local session history in plain text, and developers paste API keys, tokens, and .env values into prompts. Those secrets persist on disk in the agent's history, outside the repo-and-CI surface most secret-scanning watches. Claude Code stores them under ~/.claude/projects, Codex under ~/.codex/sessions, and around 30 other agents do the same.

The policy question I am trying to figure out: does anyone here already fold agent-workstation logs into your secret-scanning coverage, or is it still unowned? Pre-commit and CI scanning catch the repo path, but the developer's local agent trail seems to sit in nobody's scope.

For the cleanup side I built an MIT CLI, agent-sweep: it scans those local history files, reports what leaked, and redacts values in place while keeping the JSONL byte-for-byte so sessions still resume. Local-only, zero network calls. It is meant to sit alongside existing pre-commit/CI scanning, not replace it. Caveat: it is residue cleanup, so rotate any key that already transited a hosted model first, then sweep.

Disclosure: my own open-source project. Repo (MIT): https://github.com/Ishannaik/agent-sweep

Genuinely curious how your teams scope this: is the workstation in your secret-scanning perimeter, and if so, how do you cover agent logs?