Is anyone else being sick of vendors dismissing clear reports of security issues as “Intended Behaviour”/“By Design” and “not a security issue“?

I’ve even had two claim it’s “theoretical” or “not reproducible” despite screenshots and syntax for a POC tool and advice that there is a private repo for the exploit tool they can be added do.

Lazy triage?

This isn’t aimed at a single vendor. A friend and I have reported one to 4 major vendors who are all vulnerable to the same issue and attack vector and the response from 3/4 so far is as above. Which means that then the other vendor presumably responds in the same way, we will end up disclosing because if we don’t, someone with less scruples/morals will find it and use it anyway - if in fact it has not already been widely used because it’s incredibly simple to do and to deceive defences that just aren’t looking at this attack before at all.

RE: https://infosec.exchange/@cirriustech/116327853523673428

Parts 2 and 3 are live now (I was gonna make you wait a week between each post but…)

https://cirriustech.co.uk/blog/agent-harness-abuse-part-2/

https://cirriustech.co.uk/blog/agent-harness-abuse-part-3/

Yesterday I saw that Anthropic had (accidentally) leaked Claude Code source via a source map in an npm package.

There’s already debate about whether it was “really” a leak or if the code was effectively public anyway.

I wasn’t that interested in the discourse.

I was interested in the source.

Specifically:
• What it tells us about AI agent plumbing (the harness)
• And what that means for security - beyond prompt injection and model-centric thinking

So I pulled it apart.

The result ended up being… longer than expected 😅
So I split it into a 3-part series.

Part 1 is here:
https://cirriustech.co.uk/blog/agent-harness-abuse-part-1/

If you know me, it won’t surprise you:
This is very much about identity, trust boundaries, and systems thinking.

None of this is new.

But it is increasingly relevant as agent runtimes become distributed systems in their own right.

Curious what others think - especially if you’ve looked at similar architectures

OID-See v1.1.0 is live.

This one’s a bit different - it shifts from scoring signals in isolation to looking at when those signals actually matter.

Permissions, publishers, reachability... none of them are inherently risky on their own.
Risk shows up when they intersect with tenant posture.

So instead of:
“this looks risky”

You get:
“this becomes risky under these conditions”

Less noise. More context. More defensible output.

Also a big shoutout to my first external contributor Suryendu Bhattacharyya for adding new auth methods - much easier to just run it now 🙌

Release + write-up: https://cirriustech.co.uk/blog/oid-see-v1.1.0/