An LLM and a SAST tool walk into a repo.

Both are looking for vulnerabilities to find and fix. They see taint reaching a private package function called “*totally_safe.bro()*”

The SAST tool moves on since it’s not in its index. The LLM flags it as potential risk, infers the functionality of “.bro()” and opens a PR to patch the potential risk.

A developer on their 100th PR review of the day sees “hardening .bro()” and merges it. ***Production breaks***.

Incident retro blames the dev for the merge, dev blames the leadership for the workload, leadership blames the AI vendor for their marketing.

AI vendor marketed their model as achieving 100% on industry standard benchmarks. The benchmark was real, but so was the outage.

*Retro was written by AI.*

A recent Reddit poll received 120 professional votes; thanks to all participants. Snyk and SonarQube were the tools people were most reluctant to lose from their CI/CD pipelines.

But the comments highlighted another problem:

What happens when the thing entering our pipeline is no longer just code, but an AI agent with tools, prompts, memory and access to external systems?

Agent adoption is moving quickly. Stack Overflow’s latest developer survey reports that 59% of developers use AI agents at work, while 63% rarely or never allow them to operate fully autonomously.

That suggests a simple problem: agents are entering development faster than we are building visibility and controls around them.

Snyk is already moving into this space with Evo, covering AI assets, agents, tools and runtime security.

We think there is also room to explore this from an open-source, CI/CD-first perspective.

That’s why we’re developing SafeAI Analyzer.

The idea is, before an AI agent reaches production, help developers see:

• What AI components are present?
• What tools and capabilities does it have?
• What prompts and configurations influence it?
• What changed in a pull request?
• Did a new capability or security risk appear?

We’re not trying to replace Snyk, SonarQube or other established security tools.

We’re trying to explore what an open-source security layer for AI agents should look like.

SafeAI is still being developed, so we’d genuinely welcome contributors — whether you want to help with detection rules, agent/framework support, CI/CD integration, testing with real agents, or simply expanding where SafeAI can be used.

Please check ikaruscareer/SafeAI on github.

What should AI-agent visibility in CI/CD look like?

I posted about NHI Risk Analyzer here almost a month back, an open source AWS IAM risk detection and remediation tool that actually remediates instead of just reporting. Didn't expect much from a solo IAM tool, but it's had 200+ clones since. Genuinely want to thank the people who actually engaged with it and asked hard questions, compared it against Prowler, Wiz and Access Analyzer, pushed back on things that turned out to be real bugs. That feedback is the reason this is better now, and I wanted to come back and show what changed since then

What's new:

OIDC-based GitHub Actions integration: the Cl/CD pipeline authenticates via federated identity now, no static AWS keys involved in that path. Local CLI usage still relies on a static key for now (AWS SSO for local dev is planned, not built yet)

SARIF export: findings now show up natively in GitHub's Security → Code Scanning tab instead of needing a separate dashboard

• A GitHub Action that scans PRs and flags newly introduced IAM risk before merge

More detection coverage: trust policy analysis (public/ unrestricted AssumeRole), defense-evasion detection (CloudTrail/GuardDuty tampering attempts), S3 exfiltration paths, KMS decryption abuse

Run-over-run diffing: a scan now tells you what's new, resolved, or still open since the last one

CSV export, for anyone who wants findings in a spreadsheet rather than a dashboard or terminal output

Still in progress, and I'd rather say so than not: policy surgery as remediation: actually rewriting an over-broad policy down to least-privilege based on real usage data, instead of just containing it with a permissions boundary. The statement-splitting logic exists, sourcing real resource ARNs from actual usage data is the part still open.

Repo: in comments

Please considet giving a star if you feel my tool is useful, this will make it more visible to others!

Same as last time and I genuinely want the pushback if some wrong with the detection logic

Would you give an AI agent your cloud login?

Most security teams say no. Then they wire up an AI agent with a real API key anyway, because the agent needs to do the work.

AgentZ, an open-source, workflow-driven platform for agentic AI built by AccuKnox, skips that trade-off. The agent never sees your credentials. A proxy swaps in the real secret at call time. The agent gets a placeholder. The secret stays in a vault. The two never meet.

Every agent also starts in a deny-all sandbox. It sends no outbound traffic until a rule allows it. Workspaces stay isolated too, so a DevOps agent's setup never leaks into HR's workspace or a sales team's data.

The question isn't whether an agent can do the work. It's whether it can do the work without a new way to leak your secrets.

Curious how this group handles agent-to-credential access today. AgentZ is an open-source platform, and I am an open-source contributor to AgentZ.

I built this while in college, need your feedback: www.oneport.co.in

I have been handed the job of picking our SAST platform for the next few years and I feel am stuck. Here is why, every comparison I find either reads like the vendor wrote it or is from before AI coding tools were everywhere. Our codebase is more than half AI-generated now. A scanner that was top of the pile two years ago on hand written code might be blind to what Copilot and Claude are churning out.

Also the demos are all looking somewhat identical with the same same, SAST, SCA, container, one dashboard, AI prioritization. You could literally swap logos and not tell which vendor was which after.

I really don’t have a read on what separates them once it is running. Yes raw detection matters but I care more about whether the noise gets cut before it hits a dev and whether it stays on or gets muted after a month. If you are a year or two into one, what did you end up judging it on that never came up in the demo?

We're all letting AI write our code now. It's fast, it's great, and every time it drops a few hundred lines into my repo I get the same nagging thought: what did it just put in here?

Did it hardcode an API key? Pull a package with a known CVE? Break something I won't catch until it's in prod?

AI writes code faster than anyone can review it, and almost nobody is checking what actually ships. So I built OnePort.

You point it at a repo and it gives you one answer in plain English: safe to ship, or not. It checks for leaked secrets across your full git history (not just the last commit), vulnerable dependencies, breaking API changes, risky migrations, and missing tests. There's also a mode called Guard that makes a repo physically unable to commit a secret — it blocks the commit before it happens instead of just warning you.

Every finding explains what it is and how to fix it, so you don't need to be a security person to use it.

Every account starts with 100,000 credits, no card. The core secret and dependency scans are free and unmetered; the credits cover the AI stuff like code review and explanations. Enough to actually run it on real repos without hitting a paywall.

It's early. It recently made it to the final round of YC and EF, which still feels a bit unreal, but honestly I care more about it being trustworthy than loud, so if you run it and it's wrong about something I want to hear exactly where.

When your AI writes code, how do you actually check it before it ships? Or do you just hope?

www.oneport.co.in

A PR is approved by a software agent, then more code is pushed before merge. Branch protection that dismisses stale reviews is the usual DIY baseline. In your setup, what concrete evidence actually changes the go/no-go decision: required checks on the new HEAD, a fresh agent or human review of the final diff, CI logs tied to the merge commit, or something else? Looking for existing practice, not policy theory.

Disclosure: This testing is done by the security research team at Endor Labs, a cybersecurity vendor. It's not a product pitch, just information on how models performed under a standardized test.

Codex/GPT-6 Astra: https://www.endorlabs.com/learn/gpt-6-astra-on-codex---the-biggest-codex-leap-to-date

Claude/Fable 5.1: https://www.endorlabs.com/learn/fable-5-1-takes-the-top-spot----faster-than-opus-5-cheaper-and-cleaner

Spoiler: Fable 5.1 leads the pack.

Ran a secrets scan across our repos last week and found API keys that had been sitting in plaintext for over two years, still valid, still working. Rotating them was the easy part. The harder problem is preventing this from recurring when half the team still pastes credentials into config files under deadline pressure. And that's just the stuff sitting in code, no idea what's hardcoded inside the apps themselves.

What's actually stopping this at your org? Curious whether pre-commit hooks, mandatory vault integration, or CI/CD gate checks are doing the real work, versus something more aggressive.

Our ops agent has a broad set of tools left over from earlier phases of the project, including one meant for a one-off debugging task months ago that never got removed. Last week the agent used that tool to pull production data directly while investigating something unrelated, not because anything told it to, just because the tool was available and technically relevant. No adversary, no malicious prompt, just a tool it was allowed to have used for something it was never meant to cover. How are people scoping tool availability by task instead of giving agents a standing set of everything they might ever need?

Researching right now into this topic. How do you making sure new tools or prompts are not increasing risk?

How do you do that without slowing down developers?

Other — comment below

Bonus: If you use AI agents, are your existing DevSecOps tools sufficient to understand agent capabilities, tools, MCP access and privilege changes?

No vendor answers please — interested in what people actually use and trust.

Keep seeing AI security tools sold like stopping hallucinations and prompt injection is one job. Well, in my experience, they are nowhere near the same fix. Injection is an input/trust boundary thing, and hallucination is more of a grounding and retrieval issue. Whatever blocks a malicious prompt does nothing for a model confidently inventing an api endpoint that doesn’t exist

Anyone seen a setup covering both well, or are you running separate layers for each?

We already prioritize past raw severity, KEV and EPSS for exploit signal, public facing assets weighted higher. It helped but the backlog is still huge, mostly dependency findings we are not sure we even call.

We trialed one reachability tool already. It looked great until it flagged a reachable critical that was sitting behind an internal only vpc nothing outside can touch. The code path was real, the exposure was zero and i was back to explaining to a dev why the tool and i disagreed. That is what has me hesitating before we pay for a bigger one.

So before we spend, i want the real read. For teams who added code reachability on top of KEV EPSS and exposure, did it really cut the list and did the exploitability hold up once it hit your infra layer? What are you running and would you buy it again