I know it’s a long shot, but saw someone else do this and get a few referral offers, so I thought I’d try it.
I have a decade of federal law enforcement and crisis negotiations experience and Im interested in the current Incident Response Team Analyst position, or any roles that would be a good fit with LERT. Im happy to share more of my background and why I’d be a string fit specifically for the IRTA role.
Thanks in advance!
I'm doing research on how trust and safety and platform integrity teams at tech companies think about fraud and abuse, specifically the messy stuff that happens after someone's already been let in.
If you work on this or know someone who does, or can point me in the right direction, I'd love to connect. Compensated interview, 30 min, totally low key.
Interesting paper on a fairly under-discussed issue in DNS: what happens to expired or repurposed domain names that remain embedded in DNS dependencies across systems. The core finding is that these “orphaned” or changed domains can persist in resolution paths and integrations long after their original context is gone, creating real security and reliability implications.
My take: this becomes even more relevant in modern AI systems, where agents, tools, plugins, and third-party APIs are rapidly stitched together. In that environment, domain names and DNS-level dependencies can quietly extend the AI supply chain attack surface in ways that are easy to overlook.
This isn't a hypothetical. It's a benchmark result published last year, and the people deploying AI into critical infrastructure are still moving forward anyway.
A 2025 evaluation of 40 AI models found that all but four were more likely to give a confident, incorrect answer than a correct one on difficult questions. Not uncertain. Not flagged for review. Confidently wrong, delivered in the same authoritative tone as a correct answer.
That's the actual problem. Not that AI makes mistakes. Every system does. The problem is that when an AI model lacks certainty, it has no mechanism to recognize that, it generates the most probable response based on training data patterns whether that response is accurate or not.
In a chatbot, that's annoying. In a system managing access controls for a hospital network or a water treatment facility, it's a different category of risk.
Where this is already happening
AI is now embedded in incident response, network configuration, vulnerability triage, and access management across critical sectors. In network infrastructure, errors or unexpected behaviors can lead to outages or security exposures, and the organization's fault tolerance for AI-driven mistakes is rarely defined before deployment.
When AI provides an inaccurate answer and mechanisms aren't in place to catch it, the implications can reach beyond a single enterprise to critical infrastructure and entire nations. Unfixed errors compound over time.
The issue gets worse because of how humans respond to confident outputs. Operators under pressure don't re-verify answers that sound certain. That's not negligence, it's how cognition works under load. Attackers already exploit this in social engineering. AI hallucinations create the same vulnerability from the inside.
And it's not just accidents. Operations like Salt Typhoon have specifically targeted critical infrastructure, and insiders warn that AI models themselves can exhibit manipulative behaviors under adversarial conditions.
The scale of the exposure
In March 2026, Iranian drones struck Amazon Web Services facilities in the UAE and Bahrain, the first time commercial hyperscale data centers became explicit kinetic targets in modern conflict. Digital infrastructure is now physically contested.
Meanwhile the systems running on that infrastructure are making confident wrong calls at a rate nobody has publicly accepted accountability for.
What actually reduces the risk:
No AI output should trigger a sensitive action, infrastructure change, access update, incident response, without human sign-off. The review requirement applies whether the output looks right or wrong. Models sound equally confident in both cases.
Treat AI-generated security recommendations the same way you'd treat an anonymous tip. Useful starting point. Requires verification before action.
Audit the training data feeding your AI tools. AI hallucinations often trace back to outdated records, biased datasets, and inaccurate information baked in at the training stage. Garbage in, confident garbage out.
Define fault tolerance before deployment, not after the first incident. What's the acceptable error rate for an AI making firewall decisions? Most organizations haven't answered that question.
We spent years worrying about AI being used against us by attackers. The less discussed version is AI being trusted too much by defenders, and failing at the exact moment it matters.
What decisions in your organization are already being made by AI without a human in the loop? Are you afraid that more and more decisions will be made not by humans but by AI?
I’ve spent ~10 years working in Trust & Safety in tech (policy, operations, enforcement / risk / integrity work). I’m now exploring the path toward becoming an independent consultant.
I’m not looking for generic “just start freelancing” advice. I’m specifically hoping to hear from people who have actually made this transition (or similar transitions from internal tech roles to consulting).
I’d love to understand any of the following
How you got your first consulting clients (especially without prior consulting experience)
Whether you positioned yourself as a niche expert or general
What your first 3–6 months actually looked like in practice
Whether you went solo or joined an existing consultancy first
What you wish you had done differently early on
My background is primarily in Trust & Safety (youth safety in UGC, product, policy , regulations , operational scaling, risk mitigation). I’m trying to understand what actually works in practice for monetising this experience independently.
Any real-world examples or honest experiences would be hugely appreciated.