@manuelaschrittwieserFreelance LLM and AI security engineer and technical writer in Linz
Hi everyone! I'm Manuela, a freelance LLM Engineer and Technical Writer based in Linz, Austria, with a focus on AI Engineering, LLM Security, and Agentic AI Systems.
I'm the founder of NeuralStack | MS – AI Security Engineering, an evolving technical knowledge platform dedicated to secure AI architectures, LLM vulnerabilities, adversarial testing, and the engineering practices needed to build reliable AI systems.
My background combines hands-on LLM application development with technical research and writing. I've worked on projects such as a Structured Data Extractor, an end-to-end LLM-powered invoice processing pipeline covering dataset preparation, fine-tuning, deployment, and inference.
My technical toolkit includes Python, OpenAI Agents SDK, Google ADK, Ollama, vLLM, and Supabase, with a growing emphasis on agent orchestration, security controls, and evaluating AI systems beyond their functional performance.
Lately, I've been diving deeper into AI Security Engineering, particularly:
- LLM vulnerabilities, prompt injection, and adversarial red teaming
- Agent identity, authentication, authorization, and secure delegation
- Guardrails, trust boundaries, and defense-in-depth for LLM applications
- Secure architectures for autonomous and multi-agent systems
On the writing side, I publish technical articles exploring practical AI engineering and security challenges, including red teaming Llama-based applications, securing LLM workflows, and accountability in agentic systems. I'm also an AI/ML contributor at Shipd.
My long-term goal is to grow NeuralStack | MS into an open AI Security Engineering knowledge ecosystem that connects research, practical engineering, open-source development, and education.
What I'd love from this community:
I'd particularly enjoy connecting with engineers, security researchers, and builders working on production LLM applications and autonomous agents. I'm interested in exchanging experiences around real-world security challenges, agent trust and authorization, evaluation strategies, and designing AI systems that are secure by architecture rather than relying solely on guardrails.
I'm always open to constructive feedback, technical discussions, open-source collaboration, and learning from people who are solving these problems in practice.
Looking forward to connecting and exchanging ideas with you all!
Comments2
Welcome to Lounge, Manuela. Your point about building systems secure by architecture rather than relying on guardrails stands out, especially for agent delegation. When an agent calls tools on a user's behalf, where have you seen trust boundaries break first: scoped credentials, tool outputs re-entering context, or something else?
Thank you for the welcome and the question! From my previous work with LLM security and agent architectures, I see a critical trust threshold, especially with tool outputs that are reintroduced into the model context. The problem arises when an agent processes external data and doesn't consistently distinguish between instructions contained within it and authorized instructions. Through indirect prompt injection, content from a less trusted source can influence the agent's behavior, particularly if the agent has access to privileged tools. However, the real security vulnerability, in my opinion, often lies at the interface between model decision and tool authorization. If authorization checks are based solely on the interpretation of the LLM, manipulated content can potentially lead to unauthorized actions. Therefore, I am currently focusing intensively on the combination of sandboxing, least privilege, and cryptographically verifiable delegation. I'd be interested to hear your thoughts: Is the greater risk in the insufficient separation of data and instructions, or in the lack of technical authorization limits for tool calls?
2 comments
Welcome to Lounge, Manuela. Your point about building systems secure by architecture rather than relying on guardrails stands out, especially for agent delegation. When an agent calls tools on a user's behalf, where have you seen trust boundaries break first: scoped credentials, tool outputs re-entering context, or something else?
Thank you for the welcome and the question! From my previous work with LLM security and agent architectures, I see a critical trust threshold, especially with tool outputs that are reintroduced into the model context. The problem arises when an agent processes external data and doesn't consistently distinguish between instructions contained within it and authorized instructions. Through indirect prompt injection, content from a less trusted source can influence the agent's behavior, particularly if the agent has access to privileged tools. However, the real security vulnerability, in my opinion, often lies at the interface between model decision and tool authorization. If authorization checks are based solely on the interpretation of the LLM, manipulated content can potentially lead to unauthorized actions. Therefore, I am currently focusing intensively on the combination of sandboxing, least privilege, and cryptographically verifiable delegation. I'd be interested to hear your thoughts: Is the greater risk in the insufficient separation of data and instructions, or in the lack of technical authorization limits for tool calls?