On one side, it means that a certain amount of business will just use it even if you think its not safe/good enough and they will throw out people and will still succeed.
And on the other side: yes because they will also use LLM review or other tooling and will be fine whatever the 'security llm agent' tells them.
Has it been released to the public yet? Genuine question. Because if you didn't try it yourself, you have to rely on others' reports. And different people who tried it on different projects got different results, leading to different conclusions.
I think what they mean is that this sort of competition makes sense because it's about humans competing against each other, so that, even if we could have LLMs do it, the human version is still what captures our interest. In a similar way, we don't look at chess tournaments with computers playing against each others, but we look at chess grandmaster challenging each other. Even if it has been decades now that computers can beat grandmaster.
I don't think rule 7 would be self-contradictory since you indeed don't own the output of an LLM, but crucially, also no one else owns it. I read that rule as don't submit someone else's code without permission, which isn't violated by using an LLM.
The long tradition refers to the use of tooling in general, and could mean that, since past tools were accepted, recent tools like LLMs can be fair game as well.
But, since there can be doubts about this interpretation, them saying explicitly if LLMs are permitted or not could be beneficial. But then again, maybe they don't want to commit to an hard rule and have more freedom to decide on a case by case basis, or just don't advertise that LLMs are welcome to prevent a flood of vibe-coded submissions.
Either you view LLM code as stolen, in which case you cannot get permission of the original owners, or you accept that LLM code is not copyrightable and has no original owners.
On the “stolen” side, so far the courts have not generally agreed with that perspective except in cases where there is actually an existing copyrighted work that the LLM output is substantially similar to.
On the not-copyrightable side, the direct output of an LLM is generally legally seen as not copyrightable, but significant human modification or editing/reworking/steering/compilation (as in compiling a bunch of LLM-generated fragments into a functional whole) is still likely to be copyrightable.
Maybe I'm not getting it either, but it looks like you're imagining a scenario where you deploy multiple instances of the agent, one per user, and then each one gets a different access level based on a key. Is this correct?
Not imagining it, using it in prod. Not sure how you define "multiple instances" here but basically, one agent with multiple concurrent conversations. Access level is based on the point of ingress to the agent, limitations are mechanical (tool access) and semantic (affecting posture, not a true security boundary but you can inflence behavior per entrypoint).
in my case, we're using Docker containers to spwan Hermes instances, so it is easier to define what an instance is. And we need a container per user, because, without modifications, if multiple users talk to the same Hermes instance then they can access each other's conversations by asking the agent.
> The session sharing is something you've layered on top, with extra software
Nope. If you give access to the same agent instance to multiple people, then one user can get access to someone else's data. I'm working right now for a startup facing this issue. The easiest solution is to have a separate agent instance per user, but this increases resource consumption vs having a single agent instance with proper separation between multiple users.
If you're trying to solve this problem right now you should take a look at cast and see if it addresses your problem. Would love to stress test my framework against different use cases.
Yes, but it exists because it was deemed better to be cautious and implement PQC despite the uncertainty and different points of view around the time scale to have cryptographically relevant quantum computers (or, from a different point of view, precisely due to the uncertainties). Their comment was in the wrong tone, but the doubts are there. BTW, PQC can be interesting to learn regardless of the discussion around quantum computers.
"will we have a CRQC soon" is the subject of much debate but "will we have a CRQC ever" is pretty uncontroversially a possibility, and so it is worth defending against harvest-now-decrypt-later attacks in the present - which is why X25519MLKEM768 is widely deployed already.
However, the time needed to get one plays a crucial role. Governments need to protect some piece of data for a very long time, but common people are generally fine with keeping something secret for their lives' duration. I don't care if someone decrypts my laptop's SSD after I'm dead.
Indeed. Is Mythos going to change this?
reply