upvote

points

by raphman23 hours ago |
comments
upvoteby allan_s15 hours ago|
next
[-]
Each knowledge could be signed, and you keep a chain of trust of which author you trust. And author could be trusted based on which friend or source of authority you trust , or conversely that your friend or source of authority has deemed unworthy.
reply
upvoteby raphman14 hours ago|
parent|
[-]
How would my new agent know which existing agents it can trust?

With human Stack Overflow, there is a reasonable assumption that an old account that has written thousands of good comments is reasonably trustworthy, and that few people will try to build trust over multiple years just to engineer a supply-chain attack.

With AI Stack Overflow, a botnet might rapidly build up a web of trust by submitting trivial knowledge units. How would an agent determine whether "rm -rf /" is actually a good way of setting up a development environment (as suggested by hundreds of other agents)?

I'm sure that there are solutions to these questions. I'm not sure whether they would work in practice, and I think that these questions should be answered before making such a platform public.

reply
upvoteby allan_s12 hours ago|
parent|
next
[-]
the same as your browser trust some https domain. A list of "high trust" org that you can bootstrap during startup with a wizard (so that people who don't trust Mozilla can remove mozilla), and then the same as when you ssh on a remote server for the first time "This answer is by AuthorX , vouched by X, Y ,Z that are not in your chain of trust, explore and accept/deny" ?

Economically, the org of trust could be 3rd party that does today pentesting etc. it could be part of their offering. I'm a company I pay them to audit answers in my domain of interest. And then the community benefits from this ?

reply
upvoteby PAndreew14 hours ago|
parent|
prev|
next
[-]
I think one partial solution could be to actually spin up a remote container with dummy data (that can be easily generated by an LLM) and test the claim. With agents it can be done very quickly. After the claim has been verified it can be published along with the test configuration.
reply
upvoteby ray_v12 hours ago|
parent|
next
[-]
A partial solution sure, but the problem is that you need a 100% complete solution to this problem, otherwise it's still unsafe.
reply
upvoteby weego9 hours ago|
parent|
prev|
[-]
You're using 1000x the resources to prove it than inject the issue, so you now have a denial of business attack.
reply
upvoteby dymk8 hours ago|
parent|
[-]
How in the world is a container 1000x resources? Parent comment is saying try running things in a container.
reply
upvoteby actionfromafar12 hours ago|
parent|
prev|
[-]
That's scary - my first thought was that "yes, this one could run inside an organization you already trust". Running it like a public Stackoverflow sounds scary. Maybe as an industry collaboration with trusted members. Maybe.
reply
upvoteby perfmode21 hours ago|
prev|
next
[-]
No symmetric, global reputation function can be sybilproof, but asymmetric, subjective trust computations can resist manipulation.
reply
upvoteby Edmond22 hours ago|
prev|
[-]
Just released:

https://github.com/CipherTrustee/certisfy-js

It's an SDK for Certisfy (https://certisfy.com)...it is a toolkit for addressing a vast class of trust related problems on the Internet, and they're only becoming more urgent.

Feel free to open discussions here: https://github.com/orgs/Cipheredtrust-Inc/discussions

reply
upvoteby quietbritishjim16 hours ago|
parent|
[-]
That doesn't answer the parent comment's question of how the dangerous claims are identified. Ok, so you say you Certisfy, but how does that do it? Saying we could open a GitHub discussion is not an answer either.
reply