lmeyerov

Those are standalone products and professional services, not internals they use

A problem is some people and teams are world class at a big company... But not everyone, everywhere. For a fun time, read about the rollout and internals of Azure.

Yes, files up the hierarchy to the root, as the app will have broader security etc requirements that all components must abide by (unless they explicitly say otherwise etc).

It's ultimately AI-controlled, so this is more about hints for inclusion, vs being overly prescriptive nor imperative.

We gave a go for cyber on botsbench.com , and this is both more expensive and less capable than Reflection's Beam 1.0 . It'll take a lot of price cuts for us to care on this particular one. Instead, I view more directionally: similar to glm 5.2 -> glm 5.3 flash, I'm curious what Medium 4.1 will look like.

We moved from an ai-maintained wiki in source control (ai_kb/...) to placing specification markdowns right next to the relevant code (src/featXYZ/SECURITY.md, ARCH.md, CONCURRENCY.md, ...). Importantly, we instructed our review/SKILL.md to find and load the spec hierarchy in as context. This helped a lot.

For change justifications, so far we have told the AI to strip change statements from code, and leave that kind of thing to the PR and commit messages. Making that more accessible than hammering git, GitHub can make sense. I'm hoping git protocol and tools catch up to make that more agent friendly, vs the trend of folks making their own new protocols and tools!

Median is < 1d for major ones

We did a small survey of major incidents after shai-hulud and came to 2d cooldowns through that

Awesome

I've suspected for awhile that the frontier models work this way bc from a speed + quality perspective this feels pretty intuitive

yeah for botsbench.com side where we do cybersecurity investigation evals of models + harnesses, we've been having to play with:

1) time budget model gets (5min / task) -- this became a real problem with opus/astra/fable at high+

2) tuning which effort level we report on (when not all)

It's incredible how well talking points on wedge issues get consumed, accepted, and amplified by both bots and people. And even though AI can now detect this in seconds, the problem seems worse nowadays, not better.

(Source: we help power tools used by the big boys to analyze posts like this & their underlying narrative campaigns)

GLM 5.3 Flash even more so... But yes :)

We were able to do a full port of GFQL from pandas to polars, cypher graph queries on dataframes, including both our CPU + GPU modes, and hit massive speedups: https://www.graphistry.com/blog/cypher-on-polars-cpu-gpu-gra...

It's been impressive!

Funny enough, GFQL (oss cypher on CPU/GPU dataframes, no DB needed) runs optimized graph queries with the usual CSR-like indexes... But underlying data is columnar as in duckdb. Likewise, for fast billionscale perf on single node, maps graph compute to pure vector ops. Storage, data representation, & reasoning are largely separated concepts.

If you can't tell bytes are leaving a node, you probably shouldn't be selling security services or testifying to congress you are taking the lead in AI security

For us it's ~easy: we do security investigation CTFs against log dumps / DBs like Splunk. We run the AI CTF as usual.. except without the DB nor internet access. If they still get some right, that's a problem. (And most public CTFs are contaminated now for that reason.)

There's a funny middle where they may not know the exact answer confidently, but do know where to get them, or aspects of the problem. That's still a potential lift in the competition . So we also check the traces to see if there is any knowledge during intermediate step DB queries that it shouldt have based on the previous steps.

I gave a recorded talk at BSides Las Vegas a few weeks ago on 'adversarial evals' that gets into the kind of cheating we've been having to deal with.

My intuition is that many of the better & bigger 'private' code bases, at least in terms of claude code and codex... are not in fact private at this point.

One lesson of running botsbench.com, in a slightly different domain, is to measure for model contamination every time.

Much earlier, I tried to set up some static analysis tools so that the coding agent would have access to dataflow analysis etc. tools instead of just grep for typed python. If there were benefits, they weren't easily apparent :(

OpenAI says deidentified data from the private sessions go into training. (Well, explicitly said they will not rule that out.) That changes a lot of the conversation.

Very much agreed in the former

I'm not so sure on the latter -- that introduces a bunch of tool calls, while the text patches are much closer to the semantic space imo and easy for harnesses

If we rephrase this as instruction following alignment, what is the concern here in practice vs a skill? (Which a model eventually internalizes)

It doesn't detract from the research - as a paper, it shows more crisply the structure is useful. I'm just not sure how necessary the encoding, and given durable tasks, novel the insight. Is there new alpha here somewhere, esp given the similarity?

I wonder if the graph part is a distraction (data representation / syntax), and once you step back, if/how this relates to the wider concept of 'durable task lists' used in this kind of structured dynamic planning.

Ex: Durable task lists generally use more textual representations, eg, a hierarchical text list that supports named references -- so a graph. Likewise, they're mutable, contain statuses, etc. They're fairly popular and AI models at this point have internalized them at this point.

Wonderful data point!

It's been interesting investing into different classic verification & testing methods for gfql (CPU/GPU graph queries on dataframes) and Louie (agentic investigation harness) over the last couple of years with different model & harness generations. The ones below are fewer but more longitudinal efforts compared to the shallower ones Dan worked through, and seem largely consistent:

Overall, my takeaway on standard software has been LLMs favor smart, guided fuzzing, natural language specifications deployed as iterative parallel adverserial AI review (e.g., context-reset subagents) after the functional prototyping. For formal methods / static analysis, cheaper/faster/lighter ones, though for the next level of quality, I can see this changing. The concolic testing world's heuristic results carried through a lot for me vs most others, which is unsurprising as they went deep on engineering ROI curves for fuzzing large code bases and specializing for different bug classes.

Highlights:

- alloy for gfql fell on its face relative to fuzzing, even with guidance. This was disappointing as it was intended as a cheap experiment to justify doing more expensive formal methods.

- prompts & skills need tuning: auto-memory doesn't transfer across harnesses by default, and one-shot auto-authored skills evals badly. More about iterating. Manual version of iterating would be editing skills when we hit new/repeat classes of bugs, though not guaranteed faithfulness: this is what we do the most. Positive experiments automating here, but not enough to invest deeper when we have to do manual anyways.

- natural language specifications are now a thing. Our significant new features now come with a security.md, policy.md, concurrency.md, etc., and important for them to be close to the code and taught to the review skill. Coding and review agents then can triangulate between tests, specs, code, and their own skills & general knowledge. However, we find we prefer not to do localized invariants in method comments as that gets verbose and drifts, and instead, do those as tests. This gets a bit into the global cost question of better code gen iterations and/or better review phases.

- staging coding vs reviewing. Overtesting early kills progress, so we stage heavier quality engineering at the end, and architectural research at the beginning.

- Lessons from the concolic execution era: staging static LLM analysis early with dynamic LLM testing later. Test amplify findings by area, kind, etc to convergence.

- We love community suites. GFQL builds against known Cypher language standards correctness conformance and benchmark suites, and Louie tools often start with community agent evals/benchmarks before we add our own specializations.

I don't know how big and deep the experiment Dan ran was. Something like formal methods is generally a big & invasive investment, and the target of each kind is often a much higher quality rating for a narrow set of properties. This complicates benchmarking setup. Imagine building entire compilers, and experimenting with different combos of methods & having those methods come in at different times & places.

I expect the AI security vulnerability analysis world to have similar findings. We end up baking that into our review harness as well without changing our overall methods above.

Picking rust also felt problematic as also somewhat out of distribution historically

... And it looks like everyone keeps using the same security startup to run the higher risk tasks, where individual staffers may be great yet, yet as an organization, the biggest labs got hosed in different ways

That indemnity card excuse is burned, multiple public security fails in a year makes a repeat a "shame on you" moment

(The one org who didn't use the startup did seem to learn: AISI supposedly stopped intentionally pointing attack agents at the public internet and switched to simulating it)

Moving towards streaming and generally out-of-core is great

We recently added a Polars backend to GFQL (cypher graph queries on dataframes, no DB needed), both CPU and GPU mode, and super impressive. Noticeable improvements vs pandas/cudf, and enabled GFQL to beat out popular systems on more categories like low-latency, not just big datasets: https://www.graphistry.com/blog/cypher-on-polars-cpu-gpu-gra...

Yep!

Congrats!

For those into the `pip install ...` flow and kuzu is gfql, which we developed around the same time in a non-VC-funded oss manner:

- cpu columnar engine + optionally the only open source gpu engine mode for bigger graphs / faster queries

- removes the need for a database file: purely functional compute tier engine you can write to parquets if you want, play with parallel reader/writers in simple ways b/c that, and TBD iceberg writebacks

- adds full graph analytic pipeline support, eg, feature engineering

- also millisecond/submillisecond times on small graphs like that small 100K edge graph benchmark

Main box not formally checked is streaming. Funny enough, we're designed for GPU firehose workloads, so would be fun to demo and see what gaps are left.

Interestingly, while we don't fine-tune generative models for Louie.ai, we found fine-tuning embedding models to be a major $ saver. Instead of 1K-2K wide frontier embedding vector lens... Just 64. Huge savings on vector DB $$$.

I'm curious how that works with something like turboquant. Not needed any more, still dominant, better together, ... .

It's been fascinating doing a custom variant for GFQL, the first OSS embeddable Cypher property graph query engine for CPU+GPU -

- accelerated launch of our new backends like polars, including a new lazy mode & planner, which are fundamentally new paths

- while we initially aimed for top GPU benchmark scores, we now also maintain top CPU scores too!

Long-term, more interesting to me is this opens rethinking what it means to be a query engine. Right now we are making it the fastest in general, especially on workloads from our own use, major industry benchmarks, and our users. At the same time, similar to jit and multistage computing, we're looking at new ahead-of-time optimization techniques users can do that are more interesting than plugging in custom indexes. Essentially, if our agents can do fast specializations, there should be safe hooks that we can expose to our user's agents too!

A graph is a fancy way of saying a few async await calls, which a REPL can do

(We added the same to louie.ai, not complicated)

Fwiw, without naming names, I helped someone at a hackathon make their first app on something he was passionate about, later found out he had been recently homeless living on an abandoned boat, and now years later, afaict he turned that into a $10m/yr business with ~millions of users

Persistence > Intelligence , and being able to code isn't some sort of superiority thing, it's just one skill of many

Edit: being able to take risks, and doing so, does lead to higher variance outcomes, so that is something I have also come to appreciate and look for in people. It may look reckless, and attracts weirder people almost by definition, but that is what startups are ultimately about, betting you can do better than the regular path!

agreed. gfql already gives this best-of-both for oss cpu+gpu cypher as we've been steadily working through benchmarks like ldbc, pokec, etc.

The HPC lessons for graph algorithms is less obvious as the substrate the OP is working through is close but not quite what HPC folks figured out, so the trade-off of fast to write and maintainable (dataframe/db-based) vs at the achievable magnitude of performance is tricky. LLMs change the calculus here too IMO, so I've been thinking a lot about more NUMA-exposed ideas that before were relegated to PhD land.

see graph500

we use igraph cpu / cugraph gpu in pygraphistry/gfql projects, and our experience is cugraph is ~10X+ on tiny cheap GPUs over igraph. looking at that table, where all seem same magnitude as igraph, I'd therefore expect much better than all the options listed. And when things get bigger and it merits a bigger GPU, even better. The team has been doing a great job over the last decade, and all free.