It's really amazing, we've crossed a threshold, and I don't know what that means for our jobs.
> Another AI agent. This one is awesome, though, and very secure.
it isn't secure. It took me less than three minutes to find a vulnerability. Start engaging with your own code, it isn't as good as you think it is.
edit: i had kimi "red team" it out of curiosity, it found the main critical vulnerability i did and several others
Severity - Count - Categories
Critical - 2 - SQL Injection, Path Traversal
High - 4 - SSRF, Auth Bypass, Privilege Escalation, Secret Exposure
Medium - 3 - DoS, Information Disclosure, Injection
You need to sit down and really think about what people who do know what they're doing are saying. You're going to get yourself into deep trouble with this. I'm not a security specialist, i take a recreational interest in security, and llm's are by no means expert. A human with skill and intent would, i would gamble, be able fuck your shit up in a major way.
How do you know these are actual vulnerabilities? You just ran an LLM and it told you something and you came back to dunk on me, with zero context on the project.
Maybe you need to sit down and really think that you have no idea who you're talking to or what the project does. Next time you make a "omg this code is so shit" comment, include something more than "well my LLM says your LLM is bad" so we can have a discussion with facts rather than LLM-aided trashtalk.
EDIT: Out of curiosity, I've ran Kimi K2.5 on the codebase, and all the things it found are invalid, or explicit design decisions. So, next time you decide to tell someone their project "is slop" by running an LLM and relaying its verdict, consider a) the irony of what you're doing, and b) that the other person might know more than you about their own project that you spent "three minutes" running an LLM on.
You should educate yourself more before you go around slandering people.
This can be done via a signal/telegram message, via compromised plug-ins, via file uploads etc. At no stage does there appear to be, as far as I can tell, any attempt to mitigate or limit attack surface. That's just one of the problems. If that's by design, my bad, you do you king.
How is the attacker going to message the bot, genius? Do riddle me that.
You're hyper-focused on the front door, asking how an attacker would even message the bot, but you're ignoring the fact that modern attackers don't bother knocking. Read cloudflare's 2026 threat report, it's eye opening. Between automated session cloning and browser-based info-stealers (among many other modern headaches), the 'whitelisted user' is no longer a static, trusted entity. If a user on your list has their session token scraped via a malicious browser extension or a hijacked desktop app, the attacker effectively becomes that user. At that point, your bot doesn't see an intruder; it sees a 'trusted' account and hands them a loaded gun in the form of arbitrary SQL execution. Now, the problem is you aren't the only one with access to LLM's and obscurity never really was security, even less so now. An llm with credentials could easily probe its way through your bot's capabilities and connected data and exfiltrate everything.
So, the reason I'm calling into question your claims of having a 'safer' personal agent/bot/whatever is a matter of blast radius. A standard bot usually interacts with a restricted API or a set of hard-coded functions, so even if the account is compromised, the damage is capped. By giving an LLM the keys to the entire database, you've created a single point of failure that can result in total data exfiltration or a complete 'drop table' wipe, among any number of other nasty things. That's just _one_ issue in this project.
If you actually want this to live up to the 'safer than average' description, you have to move past the idea that a whitelist is a firewall. You need to distinguish between authentication and authorisation and implement defense-in-depth, starting with a database user that has zero permissions beyond simple 'Select' queries. You should be using a proxy that intercepts the LLM's generated SQL and kills any string containing 'Drop', 'Update', or 'Delete' before it ever touches your server, without some form of parsing/checking. Right now, you’ve built a powerful engine with no brakes, and telling people it’s safer just because it's on Signal is a dangerous misunderstanding of how modern exploits actually work.
Alternatively, fix how the project is described to be more accurate/honest than it is now.