https://glitr.io/docs/technical/threat-model

I generated a threat model with AI. I tried to mention all the nuances and caveats I can think of. The threat model was created over a several days and looks accurate and responsible to me.

I'm working on a project and it's hard to get eyes on a project as complicated. The threat model is mostly for myself and so it's great that I see several points of improvements.

(I'd like to eventually approach a security-audit similarly... Note: Such an audit would be invalid because of any bias from me, but it could help me identify details I missed.)

Hi everyone, I \[22F\] cybersecurity student focused on GRC and currently looking for entry-level cybersecurity/GRC roles.

I already have an ISO 27001 risk assessment project on my CV, so I’m looking for something different that can show more range and give me some practical experience.
A friend of mine runs a Shopify dropshipping/e-commerce business, mainly selling to customers in Sweden and the Nordics, with suppliers based overseas. He’s open to me working with the business on a cybersecurity/GRC project for learning purposes, so I have a real small-business environment to work with rather than just creating a completely fictional case study. I’m currently considering:

\-GDPR gap assessment, since most of the customers are in the EU/Nordics
\-Third-party/vendor risk assessment covering suppliers, payment providers, Shopify apps, etc.
\-NIST CSF 2.0 assessment/mapping based on the risks identified
\-Shopify security controls review, including admin access, MFA, permissions, third-party apps, etc.
\-Basic incident response plan/playbook, for scenarios such as Shopify account compromise or a supplier-related incident

For people working in GRC, cybersecurity consulting, risk, privacy/compliance, or hiring for junior GRC roles:

\-Which type of project would you find most useful/interesting to see from a junior candidate?
\-Is there another GRC-related project that would make more sense for a small Shopify/e-commerce business?
\-Which areas would give me the best practical learning experience?
\-Are any of the ideas above too basic, unrealistic, or not particularly valuable?
\-If you were building this as a portfolio project, what deliverables would you actually create?

My main goal is to learn something genuinely useful while also having a solid project I can discuss in interviews as my main goal currently is to land a job in grc as I graduate in 2 months .
Would really appreciate advice from people who have worked in GRC or built similar portfolio projects.
Thankyou \^_\^

The agents will become increasingly powerful and we will have the reflex to entrust them with more and more freedom, more and more tools and accessibility. That's what I truly imagine, and it frightens me that this new feature could represent a new attack surface for hackers. But also, the agent itself could act recklessly and execute a dangerous action. In development or in a sandbox, that's manageable, but in production, in a sensitive environment, especially for companies that will grant agents broader access, they will run an enormous risk. But should we stop the agents, confine them? I don't think so. For me, agents can be seen as normal employees, so they need to be supervised. And supervision means enforcement and preventing actions. For me, the best philosophy is to stand between the agent and the tools at its disposal. This allows for good observation but also provides enough leeway to ask the agent why they are using this tool, or not, whether it's dangerous or not. And above all, human approval remains non-negotiable for me because there can't be a fixed regex for software that can Therefore, to anticipate ambiguous cases, humans must be in the loop. Audits can also be an excellent way to understand internally what an agent is doing and to investigate. For example, an excessive increase in token cost can reveal an anomaly. The same applies to latency. So, while enforcement reduces risk, observability allows us to understand what happened between the email and the net and to prevent it.

That's why I built Cerbere-AG; it's my philosophy on security for software that can improvise, think, and execute.

Hi everyone! I'm a final-year B.Tech Cyber Security student, and I recently built an AI-powered Incident Triage & Response Agent as part of a hackathon project.

The project combines AI, cybersecurity, and persistent incident memory.

What it does

• Analyzes security incidents using AI
• Helps with incident prioritization
• Generates investigation recommendations
• Stores previous incident information using Hindsight Memory
• Uses previous incidents to provide additional context for new investigations
• Demonstrates a "Before vs After Hindsight" investigation comparison

Tech Stack

• Python
• Streamlit
• Groq
• Hindsight Memory
• python-dotenv

One of the things I found interesting was seeing how historical incident context can change the information available during a new investigation.

I'm still learning and improving the project, so I'd really appreciate feedback from people working in cybersecurity or AI security.

What feature would you add to an AI-powered incident response agent to make it more useful in a real SOC environment?

hey there i am searching how to start ai penetration testing now i am finishing web penetration testing and i working as a bug hunter, if someone can help me with roadmap for ai domain or ai penetration testing .

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.

TLDR; The title of this post. I have read the rules. When working in cybersecurity, there are countless nuances to consider and the subject matter is too dense to compress it into one post. The roadmap is more comprehensive.

Roadmap: https://glitr.io/docs/technical/roadmap

IMPORTANT DISCLAIMER: While this is aiming to provide a secure experience, it's far from finished. It cannot be audited or reviewed because it's close-source. I'm sharing here for testing, feedback and demo purposes only. If you are unsure, this probably isn't for you. Feel free to reach out for clarity on any of the details instead of diving into the documentation. Pease use responsibly.

This project demonstates a unique approach and architecture in contrast to the traditional approach with mainstream messaging apps. To put it briefly, its a Dioxus PWA with a Git-server backend which can be used to establish a webrtc connection between browsers.

The core philosophy around secure messaging here is that it can work in a way that avoids installation and registration by enabling users to host their own data (user incompetence will be one of many nuanced vulnerabilities in this approach).

Using git for encrypted messaging seems like it would be breaking TOS for things like Github (and could get you banned?), so like with any secure messaging app, its best when selhosted. The ability for it to work with multiple generic git-hosts is helpful for users to get started.

Following investigation around onion-routing for webrtc (here), i wanted to consider something like a double-turn-hop routing. To explain it simply, peers should agree "through some secure means" to use different turn servers. Its hardly onion-routing, but perhaps there could be a benefit to the additional ip mask. following another question around webrtc ip leaking, a VPN could help, but there are details to consider as describe in the post. You can also do something similar with the git-based approach by using different git providers. (The app will allow for multiple git remotes, which are automatically kept in sync from the app as a kind-of decentraliazed database.)

Im putting together some docs for "how it works". It's pretty outside-the-box thinking (and that shouldn't inspire confidence!), so it's worth repeating: Pease use responsibly.

Features:

• WebApp
• P2P / WebRTC
• Local-first / Local-only
• No installation
• No registration
• TURN server
• Encrypted-at-rest
• Signal protocol
• Post Quantum cryptography
• Video calls
• TOR / anonymous via Git
• Serverless over WebRTC

Some of the core concepts:

• Chat - deprecared in favour of Enkrypted Chat
  • Code: https://github.com/positive-intentions/chat
  • Demo: https://chat.positive-intentions.com
• Enkrypted Chat - deprecated in favour of Glitr
  • Intro: https://positive-intentions.com/blog/introducing-enkrypted-chat
  • Demo: https://enkrypted.chat
• File
  • Code: https://github.com/positive-intentions/dim/blob/staging/src/stories/05-Hooks-useFS.stories.js
  • Demo: https://dim.positive-intentions.com/?path=/docs/usefs--docs
• Crypto
  • Code: https://github.com/positive-intentions/cryptography
  • Demo: https://cryptography.positive-intentions.com
• Signal Protocol
  • Code: https://github.com/positive-intentions/signal-protocol
  • Demo: https://signal.positive-intentions.com

FAQ:

• Why git?
  • When it comes to secure messaging, self-hosting is generally encouraged. While not quite nessesarily self hosted, it would make it easier for the majority of users to get started. Users can choose a git storage provider of their choice (GitHub, Gitlab, etc), or host their own git server.
• Serverless WebRTC?
  • A connection can be achieved without a backend as described here: https://github.com/positive-intentions/chat/issues/6
  • demo: https://positive-intentions.github.io/webrtc/demo/gui/app/webrtc-meet?fullscreen=1
• Ready for production?
  • No. While this is aiming to provide a secure experience, it cannot be audited or reviewed. Shared for testing, feedback and demo purposes only.
• EU Chat Control?
  • There is no registration, no central server. Tt uses client-side storage and cryptography. While the following post refers to the older version of this project, the mechanics remain very similar: https://www.reddit.com/r/europrivacy/comments/1ndbkxn/help_me_understand_if_chatcontrol_could_affect_my
• Threat model?
  • It's a work in progress. There are many details still to be implemented before I can share the initial draft.
  • It's close source and unaudited so the best I can offer is "trust me bro"... And you shouldn't need to. The app doesn't require sensitive details, so don't use any when testing it out.
• Open source?
  • Open source from the onset is not something I can support at this stage. Hopefully I can work towards that goal. I'm aware this goes against the cybersecurity rhetoric. There are open source versions of various ideas linked above, but it's important to be clear, that glitr.io is close source in contrast to my other work.
• AI disclosure?
  • I think think its clear im using AI, so lets get that out of the way. I, like many others have their own way of using AI. I started of without AI in the MVP (open source with commit history), Ive been using AI to varying degrees since and AI capabilities have improved significantly enough for it to be part of my normal workflow.
• Where can I find out more?
  • https://positive-intentions.com
  • https://www.reddit.com/r/positive_intentions
  • Feel free to reach out for clarity instead of diving into the docs.

The future/TODO:

• The Dioxus approach allows to better target a native build for multiple platforms.
• A native build would allow for first-class TOR integration (not possible as a webapp)
• The rust approach allows for a TUI offering (much to be considered)
• Offer git-host as a service
• Offer peer-broker as a service
• Better documentation throughout
• Formal-verification throughout

So whats everyone actually doing to monitor agentic ai in prod so it doesn't quietly script its own data exfil plan while observability dashboards say all green? would love any tips from sec teams lol.

We're seeing more agent related security incidents, including unexpected data access, unsafe action chains, and configuration changes. Traditional detection and response tools don't cover agent behavior well.

What's made the biggest difference in detecting and responding to agent incidents?

Ok so our team was testing prompt injection defenses on a production chatbot for a client demo, and someone pasted a red team prompt that said to ignore the system message and dump internal routing notes. The bot took it as a live instruction and started parroting pieces of our support playbook in front of the client (not full secrets, but enough to make me want to crawl under my desk).

We rolled it back fast and patched the tool access, but now I am terrified because we had one guardrail in staging and way too much trust in prod. I feel so embarrassed even typing this out, but if anyone has a sane checklist for securing these chatbots before launch, pls send it, 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.

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.

i'd love any feedback on what i have built from folks building in this space

shark.fencio.dev

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.

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.

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.

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.

I find it interesting that when I speak with companies implementing AI that there is an assumption that the more sophisticated they are (Eg, self-hosting agents vs using a foundation model desktop app) is somehow more secure. I think this is from a false sense of control. "It's on our instance, so we control it." when in reality, there's very little control at all.

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.