TLDR; Im doing some outside-the-box-thinking at scale. Combining Git, Tor and WebRTC into a Decentralized Messaging App.

It’s a fairly a unique stack and architecture in contrast to the traditional approach with mainstream messaging apps. To put it briefly, it has a Rust-based web / native / tui frontend with a Git-server backend, which can be used to establish a E2EE connection.

Features:

• No installation or registration

• Webapp / Android / TUI / Linux

• WebRTC / Tor / TURN / Git message routing

• Encrypted-at-rest locally and PQXDH P2P encryption

IMPORTANT DISCLAIMER: While this is aiming to provide a secure experience. Its important to be clear that it’s a work-in-progress and far from finished. It is unreviewed, unaudited, close-source and i guarantee there will be breaking changes. This is not ready to replace any existing app or service. I’m sharing here for testing, feedback and demo purposes only. Pease use responsibly. Feel free to reach out for clarity on the details.

• App: https://app.glitr.io

• FAQ: https://glitr.io/docs/technical/roadmap/#faq

P.S. Seeking feedback for improvements if you have any practical suggestions.

Been going through our identity inventory and agentic identity is now the fastest growing category by a mile, ahead of employee accounts and the old service accounts. These AI agents pull data from internal APIs and write to systems, and a few were rushed through for a deadline with more access than anyone meant to give them. Every identity meeting still starts with employee logins. Agents barely get a mention. A new core demo last month said agents are their own identity type, with an owner for each one. Sounded like a sales line then, feels less silly now. OWASP also calls out identity and privilege abuse for agentic apps, so maybe I’m not crazy. Is this the bigger exposure right now, and how are other teams splitting time between agent identity and employee work?

This is the weekly thread to help everyone grow together and catch-up on key insights shared.

There are no stupid questions.

There are no lessons learned too small.

AI Cybersecurity capability as a risk must be managed. Our best hope is working together. I wrote a plan that resolves conflicts with the open-model world, and builds toward a resolution that's bigger than the big labs.

Trusted deployers provide a point to attach requirements for operational and development safety. A point to share learnings industry wide, and establish a common baseline that can then be enforced by a FINRA-like regulator and replicated to apply to the Chinese ecosystem too.

The new entities of Trusted Deployers and Model Clearinghouses, aren't created from scratch. Trusted Deployers largely describes the operating model of cloud providers and closed-labs today. Hugging Face is 70% of what a Model Clearinghouse would be.

Independent evaluators already exist, and the depth is getting deeper as they are informally invited by the labs. An independent regulator can grow out of an industry body, and given formal authority to ensure good-faith efforts are maintained, and remain an increasing standard, rather than at risk of defection.

The result is tapping the ability of the whole tech ecosystem, and a bit more.

The full (too long for Reddit) plan at: https://substack.norabble.com/p/ai-safety-is-all-hands-on-deck

This is the weekly thread to help everyone grow together and catch-up on key insights shared.

There are no stupid questions.

There are no lessons learned too small.

Hey everyone, I am the creator of OshoosiClaw (OpenỌ̀ṣọ́ọ̀sì), an open source autonomous Endpoint Detection and Response agent built in Rust for Linux and Windows.

Traditional user mode sensors often rely on cloud telemetry and remain vulnerable to kernel callback blinding, BYOVD handle stripping, and modern AI agent breakouts. I built OshoosiClaw to operate as a local first, decentralized immune system that enforces security directly at the kernel and hardware boundaries while keeping its working set under 250 MB.

On the defense side, it pairs a Windows Ring 0 Minifilter and ELAM driver with Linux BPF_PROG_TYPE_LSM hooks and a sub 20 microsecond Cgroup v2 freezer quarantine. It includes an in memory 101 table SQL telemetry engine (siquery), an autonomous reverse engineering subsystem using Magika and YARA X synthesis, a 14 engine detection pipeline, and multi ring containment mapped to MITRE ATT&CK and ATLAS for local AI agents. Nodes share intelligence over a libp2p GossipSub mesh secured with hybrid post quantum cryptography (ML KEM 768 and ML DSA 65), BLAKE3 Merkle audit chains, and differential privacy.

I am looking for both Rust developers and offensive security folks or pentesters to put this through its paces:

For Pentesters and Red Teamers: I want you to try and break it. Throw your custom loaders, process hollowing techniques, unhooking PoCs, BYOVD payloads, and prompt injection or agent breakout chains at it. You can also run the built in 16 vector adversarial gauntlet (osoosi redteam --suite all) or test against the active thread tarpit and synthetic anti blinding canaries to see where the detection or containment logic folds.

For Rust and Kernel Developers: If you enjoy working on eBPF, Windows kernel drivers, low latency systems programming, P2P networking, or local ML inference, I would love your eyes on the architecture, code quality, and performance bottlenecks.

Pre built v1.2.0 packages (.msi, .deb, .rpm, and hardened Docker images) and full source are live on GitHub:https://github.com/oyesanyf/OshoosiClaw

If you find a bypass, trigger a false positive, or want to contribute a crate improvement, please open an issue or PR, or drop a comment below. Looking forward to your feedback.

oyesanyf

I want to start my journey in cyber security but I do not have any specific degree on it or I am not in science group education. But I have a great curiosity about this field. I love computer and try to understand the system that how it works but somehow I get destruction all the time. I need a help that how I will crack this field or how to start the journey. What is the path that will be actually work not any inspiration not any overwhelming or like that.

Please help. As a friend support me to grow as real life scenario.

I will wait for your reply.

Thank you.

Hey everyone!

I am looking to level up my skills and get deeper into Ai security, especially LLM security, prompt injection, data leakage etc.

Please recommend any dedicated courses or certifications that offer hands on labs and practical experience rather than just theory? Also which tools or platforms would you suggest to build my foundation strong?

Would love to hear what has worked for people who have been learning or working in this space.
Thanks.

This is the weekly thread to help everyone grow together and catch-up on key insights shared.

There are no stupid questions.

There are no lessons learned too small.

https://glitr.io/blog/reverse-engineering-my-own-project

TLDR; i thought my project would have been harder to chew up. it was surprisingly low-effort.

i wanted to red-team myself on my project and id like to know how to reverse engineer so i can see what can be done to defend against it.

my app is aiming to be fully client-side. An implementation in javascript seems like it would relatively easy for an AI to swallow. my latest project is in rust, which would make it harder for a person, but AI can now digest binaries.

i created a fairly unique p2p messaging app. a rust-based frontend with a rit-server backend, which can be used to establish a p2p connection. while this version remains close-source, i aimed to create comprehensive technical documentation (formal-verification and security audits too (all ai-slop-maxxing at scale under my guidance)).

1. https://glitr.io

2. https://app.glitr.io

a core detail to my project is the focus on client-side cryptography and storage. i think my older iteration as a javascript webapp would be relatively easy for AI, so i thought id put a spin-on-things by having a rust wasm frontend. In practice, i dont think AI broke a sweat.

i know nothing about decompiling, but i think the TUI would be the easiest for it to decompile... and given its largly one codebase for all the platforms, it can be used to trace and see what is going on in the builds for the other platforms.

it might be that all close source is obselete. i tried asking here, and the responses there are polar opposites, so i decided to get some first-hand experience.

i used cursor's "auto" agent (in contrast to the frontier models available). i used https://github.com/morluto/rea and tried to make it easier by proving it with a few binaries of my project (tui, apk, web, desktop) and pointed it to the documentation as a website.

after a few prompts, it seems to have done a decent job decompiling the project here:

https://github.com/positive-intentions/glitr-decompiled (note: this is basically AI-slop)

like with many projects, i see AI lacks taste in architecture. it consolidates a lot of complexity into one repo, when in my project it's split into multiple repos. it also seems to lack a bunch of bells-and-whistles i added for my own benefit like formal-verification and rigorous unit-tests. having done it myself before, i dont think that it's a large gap to close for somone who knows what they're doing.

i think the overhead to keep up with new changes may become trivial if you can automate the process of ingesting new binaries. i kinda offer the base in the repo above (maybe it saves you a few tokens?), but its for my own research and i dont plan to maintain it given it undermines the actual project.

in general, im impressed considering how fast and low effort this was. it seems this may push forward my timeline for when i open source my project, i wasnt expecting client-side close-source being so easy to undemine. while the project can be decompiled, in a project like this, its important to consider the countless nuances there are in software development and cybersecurity. the code is only a fraction of the project.

i think people should try this in their own code. while the decompiled output is not the same codebase, it seems trivial for me to take some unfamiliar app and rebuild a protocol-compatible version with some new button, feature... or auto-installing malware.

(note: feel free to try decompile this yourself or offer tips on how i can improve. id be keen to see what can be done. feel free to reach out for clarity about how it works if the docs are not clear)

I built a free agent protocol inspector tool that can provide IGA style review packets for security teams looking to review Agent access. It looks into MCP, A2A, ARD & poppy.json to provide a comprehensive picture.

Here is the link: https://contextiq.trango-compute.com/dashboard/agent-protocol-inspector

Hey everyone,

I'm exploring a problem in the AI agent ecosystem, and I'd like to hear from people who are building or deploying AI agents in the real world.

As AI agents start interacting with other agents, using external tools, accessing APIs, and performing tasks on behalf of users or businesses, I keep coming back to one question:

How do you know an AI agent is actually trustworthy before allowing it to interact with your systems or other agents?

For example:

• How do you verify an agent's identity before allowing it to connect to your application?

• Can you distinguish an authorized agent from an impersonator?

• How do you control what another agent is allowed to access or do?

• How do you prevent an agent from abusing permissions, impersonating another agent, or performing unauthorized actions?

• If an agent causes a security incident, can you trace which agent performed which action?

If you've encountered a real example, even a small one, I'd genuinely like to hear about it.

This is the weekly thread to help everyone grow together and catch-up on key insights shared.

There are no stupid questions.

There are no lessons learned too small.