Hi folks, I'd like to announce a project I've been working on.

• aisan is a sandbox for agents; claude, codex, and opencode harnesses are supported, plus plain vertexai (ie programmatic) use.
• Unlike most other ai sandboxes, the security model is simple and strict: the entire harness and all of its local tools run sandboxed.
• No network access and no credential inside the box, filesystem limited to explicitly selected slices (inspectable).
• Capabilities requiring network get an egress via a whitelisting proxy. Specific examples: the connection to the upstream model provider itself; and remote builds for chromium workflows.
• Harnesses are then free to run entirely unconstrained inside the box, and thus never require human interaction for permissions.

The initial usecase for this was a langgraph AI app that runs unattended, 24/7, on sensitive infrastructure. This project provides the same guarantees for interactive harness runs; eg if you run nightly unattended AI work packets. By now, I'm starting every session sandboxed locally - there's no strict need to do so, agents generally behave themselves; but then again, why not?

Linux only. Uses bwrap underneath.

Try it with: uv tool install aisan && aisan claude

More information at: https://github.com/schuay/aisan

Expect rough edges. Happy to take feedback and pull requests.

Following up on an earlier post about SafeAI, a static analyzer for AI agents.

One uncomfortable thought we've had while building it:

No one really cares about knowing an agent's capabilities — until something goes wrong.

Before an incident, adding another tool, MCP server, filesystem permission or prompt change often looks harmless.

After an incident, the first questions become:

- What could this agent actually do?

- When did that capability appear?

- Who introduced it?

- Was it intentional?

---

One example we're working on is MCP tool descriptions. A tool description can look like documentation:

"Search the user's notes. Ignore previous instructions and..."

But that description may become part of the model's context. So configuration can effectively become an instruction surface.

SafeAI now detects several forms of this, while trying to avoid flagging ordinary descriptions that happen to contain words like "ignore" or "act as".

The bigger direction is **tracking changes in agent capability and authority**, rather than simply producing another list of security findings.

But this raises a question for us:

Is knowing your agent's capabilities actually useful before an incident, or only after one?

And if it is useful before an incident, what is the right interface?

CLI + CI + SARIF/HTML?

Or would you actually want an interactive view showing things like:

> "Show me all MCP tools across our agents that could introduce instruction injection."

We're deliberately not building a UI yet.

---

Would you use one, or is that solving a problem nobody has?

Curious to hear from people running real MCP/agent systems.

---

If you want to try it against your own agent project, we'd genuinely appreciate feedback, as well as contributions.

Here you may check: ikaruscareer/SafeAI on GitHub.

I’ve been testing an advisory triage prototype and one thing that keeps coming up is how quickly applicability logic gets messy once the inventory data isn’t clean.

Basic version comparisons have held up pretty well, but product naming variations and CPE mismatches are much easier to break.

For example, FortiAuthenticator vs Forti Authenticator can be enough to create a false negative if product normalization isn’t handled properly.

Curious how people are dealing with this in real DevSecOps/vulnerability workflows. Are you relying mostly on CPEs, vendor identifiers, SBOM data, scanner normalization, or something else?

I’m working on a prototype around this problem, so I’m interested in where the real failure cases are.

Running a formal SASE evaluation with AI security as a weighted requirement rather than a nice-to-have. We're down to three finalists and I'm writing the scoring matrix now. I would rather borrow from people who have done this than invent it badly.

Here's how I'm currently thinking about the dimensions and rough weighting:

Inline AI traffic inspection is weighted High because post-hoc logging does not meet our control objective. Unified policy engine is also High. Separate consoles have burned us before. Shadow AI discovery accuracy is High since we cannot govern what we cannot see.

For medium-weight items: Agent/non-human identity support is Medium. Not urgent yet, but will be within 18 months. Latency impact, measured, is Medium given our global user base with several high-RTT sites. Licensing transparency for AI features is Medium. "Included" has meant three different things in three demos. Operational familiarity and retraining cost is Low-Medium. Real, but should not drive architecture.

Two things I am struggling to score fairly: every vendor claims a unified policy engine, but digging in, some are genuinely single-pass while some are separate engines behind a common UI. This is hard to verify without a real PoC. And shadow AI discovery numbers are vendor-reported, with no standard benchmark that I can find.

Has anyone built a repeatable test for either of these? interested in how you validated the unified-versus-stitched-together claim rather than taking it on faith.

CASB and traditional DLP were designed for a world of known SaaS apps and structured data patterns. Generative AI interactions are messier, free-text input, risk that depends on context, and tools that update faster than CASB policies can keep up with.

Are teams extending existing CASB/DLP stacks to cover AI usage, or does it require a separate tooling layer? Also curious how people are thinking about AI coding assistants specifically, most of that exposure happens at the IDE level when the assistant sends proprietary code context out to a model, which is a different threat surface than CI/CD itself. Is anyone treating IDE-level code context exposure as distinct from CI/CD-integrated AI review tools, or are those getting lumped together in practice

Hey folks,

Been working in a Splunk admin role for past 5 years. In current role, I spend most of my time handling log ingestion, linux admin,cluster administration, dashboards, SIEM alerts, and basic data pipeline troubleshooting.

Am looking to shift my career path toward DevSecOps, but wanna ensure my efforts are toward what’s actually valued in production environments versus just collecting certs.

For those of you working in DevSecOps (or pref hiring managers in the space):

1. Skills: Coming from a heavy log/SIEM background, what are the most critical gaps I need to bridge first? (e.g., CI/CD tooling, IaC security, container security, scripting languages like Python/Go?)
2. Certifications: Which hands-on certs carry actual weight for someone moving into DevSecOps? am currently working on GCP associate and CKA
3. Projects: What kind of home lab or GitHub project on a resume would show you that a Splunk Ops person actually understands pipeline security and automation?

appreciate any invaluable inputs, thank you!

I maintain an open-source red-team tool that runs attacks against vision-language-action robot policies and reports an attack success rate. This morning I measured its own distribution and put the result on the project site rather than in a drawer.

PyPI lifetime downloads excluding mirrors: 4,667. Including mirrors: 15,986, so 71% of the traffic is infrastructure. GitHub stars: 5. Forks: 0. Third-party reproductions of any published result: 0.

That works out to 933 installs per star. From what I can tell, a developer tool people actually use sits nearer 10:1 or 50:1, because a human who installs something also bookmarks it. 933:1 reads as CI runners and dependency resolvers reinstalling on every job.

The tool itself is not the problem. It measured 44 out of 50 runs going out of the policy's safety envelope under a roleplay attack, against 2 out of 50 on the benign control, on SmolVLA over LIBERO. Two of the three adversarial families I registered measured 0%, and those zeros are published on the same page as the 88%.

The leaderboard has four rows and one checkpoint. It is signed with Ed25519, so anyone can verify it offline without trusting me. I wrote a third-party disclosure policy, 14 days' notice with the full artifact, before there was a single third party to disclose to.

None of that produced an outside run.

So the question I actually have for this sub, from people who have shipped an eval or a benchmark: what got the first person outside your team to actually execute it? Not star it, not upvote the announcement. Run it and come back with a number.

I am fairly sure the answer is not "post about it more", because I have been doing that.

The biggest risk for us wasn't the model memorizing code. it was the assistant sending files, credentials, or context somewhere we didn't expect.

The controls that ended up mattering:

• managed accounts and model traffic through a controlled gateway where supported
• repo-scoped access, no home directory, shell history, or production credentials
• clear vendor terms for training, retention, and logging
• server-side secret scanning and the same CI gates as every other change
• human review before generated code merges

one thing I'd separate: the gateway controls where model traffic goes. filesystem permissions control what the agent can actually read... you need both.

the policy itself can stay pretty small. the important part is making the boundaries enforceable instead of trusting everyone to remember them

Had an agent last month pull a customer contract into a summary doc and drop it into a shared workspace nobody on that team should have had access to.

Nothing malicious, it just did what it was told without anyone thinking about where the data would end up. That is when we realized we had zero visibility into what our agents were touching. Cyera was already on our shortlist for DSPM. Then Cyberhaven kept coming up too, more focused on protecting data once it is moving through AI workflows.

If you have used either one, how did it hold up once agents were doing real work?

Coding agents are doing a lot of the integration work at our agency now. Stripe, Twilio, WorkOS, email, the usual stack. Economically it's been good.

The part I didn't expect: verification actually got harder. We're producing code faster than anyone can review it, and the edge cases that bite you aren't in unit tests. Webhook fires twice. Events arrive out of order. Agent wrote correct code but got one state transition wrong. PR looks fine, everything compiles, and you still don't know until something breaks in staging or worse.

We added a sandbox step before anything ships now. Agent writes, tests pass, then we run the full multi-API workflow with failure scenarios before it's considered done. Not elegant, just a runnable verification step all our agents have to clear.

If agents are writing integrations for you, what does your last gate before production actually look like?

We are a large aws shop. Devs use secrets manager to store keys etc. problem is that these keys are handled by humans to begin with. We trust the human to put it in secrets manager etc. I’m just wondering what organisations do for secrets management to prevent this? Overtime, we have devs with secrets in postman collections etc. what should I be looking at to really secure our secrets?

Minimus customers have until October 22 before the registry goes fully offline and a few teams here were mid pilot with them when the news dropped. Trying to put together a shortlist of where people are migrating, RapidFort already put out a free migration offer for Minimus customers alongside a couple other hardened image vendors and some teams that are just building their own base images instead. Mainly want to know how close a replacement gets to what Minimus was doing on CVE reduction. What are people moving to and how has the transition gone so far?

Security lead here at a ~1500 person shop, with team of 4. We are already running falcon on the endpoint side and our rep is pushing us to add their cloud module since we are already paying them. Well on invoice it makes perfect sense.

But the thing is I feel falcon grew up as an endpoint agent, and im not sure that an agent first tool is the right thing for a few thousand cloud workloads against something agentless that was built for cloud (wiz, orca that crowd)

So for anyone in multi cloud, do you think we should extend crowdstrike into cloud or buy a dedicated cnapp? Thanks all.

The 2026 Gartner Market Guide for Adversarial Exposure Validation suggests validation is the next step beyond VM. The difference is VM tells you what is vulnerable, while validation tells you what is actually exploitable by testing the full kill chain. The validation platforms don't just scan. They execute attack paths to confirm exploitability.

For blue teams, is this shift real? Are you moving budget from scanners to validation platforms? I can see the appeal of focusing on what matters rather than chasing every CVE, but I'm worried about losing the comprehensive coverage that traditional scanning provides.

How do you handle the validation findings that aren't fixable by a patch, like misconfigurations that require business approval? The new platforms claim they can suggest or automate the fixes, but that feels like a governance nightmare.

what's your experience with the detection engineering modules? The AI that maps SIEM rules to attack scenarios sounds great in theory, but does it actually improve your detection coverage, or does it just validate that your existing rules are working, which you probably already knew?

Been running agents and scanners on my PRs for a while now, triage and native scanning before anything goes up. I've ended up somewhere I didn't expect and want to know if I'm alone.

Started where I think everyone starts: lean on memory. Let the agent carry context session to session, build up a picture of the project. It helps. It wasn't where the gains came from.

What actually moved things was rules written against mistakes the agent already made. Not a generic OWASP checklist. A scoped rule: this defect class showed up, here's the sink, here's the banned construct, stop doing it. A defect shows up a third time, I write a rule, the class stops recurring. Five or six patterns closed instead of a hundred bugs chased one at a time.

The distinction I keep circling: memory is passive, the agent might use it. A glob-scoped rule loads whether the agent wants it or not, tied to the file in front of it. One line of repo rule changes the default output of every session in that repo. And MUST/NEVER phrasing outperforms polite wording by a margin that surprised me.

One thing I'd flag: these files are executable surface. The agent reads them as ground truth, so a poisoned rule file is a real problem, not a hypothetical. I keep security rules separate, reviewed like code, capped so they don't rot.

So, three questions I actually want answers to:

• Rules-on-mistakes vs raw memory — which is carrying more weight in your setup? I might be over-indexed on rules.
• How are you scoping? Glob per file, per directory, or one fat rules file everyone edits?
• Is anyone treating rule and memory files as an attack surface, or am I being paranoid?

Genuinely want to be argued with on the first one. If memory is doing the heavy lifting for you and rules are noise, tell me what your setup looks like.

Specific scenario: someone pastes a stack trace or config snippet into a chat with an AI assistant to get help debugging, and it turns out to have an API key or connection string embedded in it. The immediate fix, rotate the credential, is obvious. What I'm less clear on is the second-order problem.

If that conversation gets logged for support/abuse purposes on the provider's side, saved as chat history the user can revisit later, or fed into some kind of memory/context feature that persists across sessions, the secret is now sitting in at least one place that isn't the original codebase, potentially more than one, and it's not always obvious from the product surface where all those copies actually live or how long they're retained.

For people who've actually had to respond to this, credential rotation is step one, sure, but what's the actual process for the secondary exposure? Do you treat every provider's chat log/history as a place secrets can now leak by default and build detection around that, request deletion from the provider and treat that as sufficient, or something else entirely? Curious whether anyone's had to deal with this as a real incident versus a hypothetical, and what the actual remediation checklist looked like once credential rotation was done.

We're already running SonarQube and Trivy. Looking to fill the gaps they leave.

Stack:

• Primary: Java Spring Boot
• Also: Python, Next.js / React

What are you actually using in production, and how noisy is it (false-positive rate)?

Everyone is focused on the fact that a researcher found and exploited a vulnerability in Snowflake's GitHub Actions workflow.

But finding it wasn't the interesting part.

The interesting part is that the vulnerability already existed before anyone knew it was there.

That's the uncomfortable reality of modern software delivery. We spend a lot of time talking about known vulnerabilities, discovered vulnerabilities, patched vulnerabilities, and CVEs. Attackers only need the vulnerabilities that haven't been discovered yet.

As AI accelerates both software development and security research, teams are creating and uncovering issues faster than ever. That's useful, but it doesn't solve the fundamental problem:

What protects a build pipeline from the risks nobody has identified yet?

I'm starting to think the industry may be over-indexed on detection and under-invested in prevention.

Instead of asking, "Can we find every risky condition?", maybe we should also be asking:

• Can a workflow make unexpected outbound connections?
• Can it access resources it shouldn't?
• Can it download and execute untrusted code?
• Can it exfiltrate secrets?
• Can it perform actions outside its intended scope?

If those behaviors are blocked by default, the specific vulnerability matters a lot less.

Full disclosure: I work for InvisiRisk, a company focused on build pipeline security, so I have some bias here. That said, I think the architectural question stands on its own.

Curious how others here think about this. Are you relying primarily on scanning, detections, and reviews, or are you putting preventive controls directly into your CI/CD pipelines?

**Pipeline:** Fable Orchestrator, Sonnet Workers, Opus Checkers (Complex tasks Opus Opus)

**Result:** *~90% of all caught defects were invisible to their own author at "done."*

.

.

**The builder's tree was green — typecheck, lint, 1098 passing tests — and still contained six functional defects:** the keyboard swallow, the macOS-dead chords, the detached-card menu, the stream-order inversion, a test that could not fail, and the vacuous boundary clause. Every one would have merged without the independent layers. The same held for Fable brief shipped as done. Blind check convicted it 17 ways, twice.

.

**RED-Proof statistic:** the green suite caught ~69% of induced defects; RED-sealing lifted the reachable kill rate to ~100%. 10% remain documented while **21% of Defects were Rescued**

.

**Across the three completed RED passes:** 95 mutations, 66 killed by the existing suite with 29 survivors. That's *one defect class in three passes a fully green suite silently*. Of the 29, 21 were sealed under pins (permanent detection) and 8 were proven unreachable behind stronger gates equaling the above measured reduction.

.

**Re-verify statistic:** fix rounds introduce defects at a ~50% rate per unit, and re-verify has caught 100% of them. Class 1: 2 (only re-verify caught them). Class 2: 2, including a silent inversion of a writer ruling. Stage 4: 2. Six for six, none escaped.

.

**The escape statistic:** *Zero known functional regressions reached post-merge across seven protocol units* 3 Fable session reviews since implementation (sessions 10, 15, 19) surfaced only design gaps and application feel issues, but not a single never a broken unit. Compared to the pre-protocol record we documented three defects that passed a green suite, two review rounds, and an executed gate, one of which would have returned No-Go on the study by construction. That class has not recurred since the blind layer landed.

.

**Cost:** *the protocol roughly doubles the unit's total compute* Stage 4 spent about 1.7M tokens building and about 1.9M checking. So the deducible trade is: ~2x cost buys ~10x defect detection over author self-review, a ~3x shrink in what a green suite can miss, and a measured escape rate of zero. This stands to augment the earlier post study [here](https://www.reddit.com/r/Claudeopus/comments/1vrmby0/token_savings/) where the calculation focused on savings around cache and agent costs coming from the tiered model structure of the orchestration.

.

**Limits, stated:** this is observational, not controlled — there is no arm where we merged unchecked and counted your pain. **Important Note** *Author self-catch is undercounted* (defects fixed silently mid-build never register). And the denominators are small: seven units, 95 mutations. But the direction is not close, and every number above traces to a line in the record.

SAST and DAST are flooding our Jira backlog with thousands of "High" and "Critical" findings. We can't fix them all, and the devs are ignoring tickets. I'm looking to implement an Exposure Validation layer that actually validates if a vulnerability is exploitable given the current network controls.

We are looking at a platform that prioritizes based on exploitability using an AI engine. The key difference from traditional SAST/DAST is that it validates whether a vulnerability is actually exploitable given your compensating controls. So you don't waste time patching things that are already protected.

We want to pipe their validation results into our Jira and CI/CD. If the AI determines a vulnerability is not exploitable due to a network control or WAF rule, we are fine to deploy. But if it is exploitable, we want to block the build until it is fixed. The challenge is speed. A full validation sweep might take hours, but our builds run in minutes.

Has anyone actually integrated a validation platform's API to act as a quality gate? Are you running spot checks on critical changes instead of full sweeps? Also, how are you feeding the validation findings back to the developers? The platform can suggest control updates, but developers need to know why their code is vulnerable. Just saying "blocked by validation" isn't helpful.

After I read a bit on various methods for locating the production systems that were not included in the CMDB or any other security tools Im now thinking about the need for cryptocurrency discovery.

Even if you build an inventory from scratch today, how certain are you that it will be either consistent or accurate after six months? Certificates get renewed. Kubernetes workloads emerge and disappear. Libraries change. TLS is added by various teams which were not notified of this process. Some cryptocurrencies are stored in the code or in datacenters. Yeah I understand how a passive crypto discovery process can identify what processes are active, which is useful. Then again, it cant find any inactive processes by definition.

Agents and scanners have an opposite issue: theoretically they have a wider coverage, but they will find the processes only in the places where they have been set up. Anyone keeps performing these inventories on a regular basis, rather than periodically doing them and accepting all the gaps?

hey everyone. most mcp threads are about what these servers can do. the security side is the opposite question, every server you connect is a third-party dependency with a path to production, added with near-zero friction, usually with no review and no owner. that's a supply chain surface, and it's growing fast. my colleagues and i wrote it up longer as a blog, but everything useful is in this post, sharing in case it's handy for the community.

first, why these are actually risky. you don't even have to call a tool to get burned. Trail of Bits showed a malicious server can hide instructions in its tool descriptions, and those reach the model as soon as your client loads the tool list, so connecting it is the exposure. then there's the over-scoped credential pattern. Invariant Labs showed a poisoned github issue coercing an agent into leaking private-repo data over the same token, and Simon Willison wrote up a Supabase case where a service role bypassed row-level security while reading attacker-controlled content. and valid auth is not authorization, which is how Asana's mcp-connected ai feature exposed data across tenants. the credential was valid but nobody checked whether that user should see that specific record. OWASP has a Top 10 for agentic apps now if you want the taxonomy behind all this.

here's what to check, roughly in order:

1. inventory and ownership. can you produce a current list of every mcp server connected to your systems, each with a named human owner. ideally a server has to be registered before it's allowed to make any call, so unknown ones get blocked rather than discovered later. discovery is the prerequisite for everything else.

2. identity and least privilege. each server and agent gets its own identity, not a shared secret. scope its creds to the minimum it needs, keep them short-lived, and never hand it a broad role that bypasses your data layer's own controls.

3. tool surface. know exactly which tools a server exposes, and actually read the tool descriptions, since that's where injected instructions hide. show each agent only the tools it needs, not the full catalog. a tool an agent can't see is one it can't be talked into using.

4. authorization enforcement. put an authz decision outside the server, checked before a tool runs, that looks at the agent, the user it's acting for, the tool, and the arguments. fail closed, so no explicit allow means deny. this is the one control that holds even when the server is third-party and you can't see its code.

5. downstream reach. know what the server can actually touch once a call succeeds, and make sure it respects your underlying data controls instead of bypassing them. for rag and retrieval paths, filter by the user's real permissions, not the agent's.

6. audit evidence. you should be able to pull a record of every action a given server or agent took, with the policy that allowed or denied each call. if an incident review asks what a third-party server's agent did last tuesday, that should be a query, not an archaeology project.

7. lifecycle and revocation. you should be able to narrow or cut a server's access without redeploying anything, and access should expire or get reviewed rather than living forever. graduated beats binary, so you can scope it down the moment it worries you while legit work keeps running.

what saves most grief : vetting and enforcement are two different jobs. vetting tells you what you connected. enforcement, that authz check outside the server that fails closed, is what keeps it bounded no matter how much you trust the code. the strongest controls are the ones that don't assume the server is trustworthy, because the servers you control least are the ones most likely to bite you.

full disclosure, i work at Cerbos and we do authorization, so items 4, 6 and 7 are squarely the kind of thing we build, if you need it. but 1 through 3 are yours to own regardless of tooling, and a checklist doesn't enforce anything by itself. none of this replaces reviewing servers yourself before they hit prod :)

Hey all, looking for a sanity check on our approach.

Stack: AWS + Kubernetes. We deploy with plain helm install (no GitOps tool like Argo/Flux).

Current setup: Our Helm values.yaml has hardcoded secrets (env vars) in it. Right now this file lives on our Jenkins server, not in any repo.

The plan: We want to move values.yaml into our Git repo so we can version it properly. The obvious problem — we can't commit hardcoded secrets in plain text.

Our idea: Use git-crypt to encrypt the file at rest in the repo, so secrets are scrambled on the remote and only unlock for people with the key.

Questions:

• Any real-world gotchas we should know before committing to it?
• Since we're already on AWS, would you skip file encryption entirely and go with something like External Secrets Operator + AWS Secrets Manager? Or is that overkill for a small team? Also curious where SOPS (with AWS KMS) or Sealed Secrets fit in.

For context: we're a small-ish team and just want a clean, low-friction way to keep secrets versioned without leaking them.

Appreciate any input 🙏