The short version
I’m Amine Raji, an AI security researcher. I work on what happens to AI systems in production: prompt injection reaching through an agent’s tool chain, MCP servers exposing internal systems, agents running with privileges nobody scoped. Not how to build the model — what it can be made to do once it is deployed and connected to real infrastructure.
My rule is that every claim gets reproduced in a lab before I make it in public. That’s why the attack labs are open source and the talks run live demos rather than slides of screenshots. You can check the work.
Before AI security I spent 15 years on security in banking, defense, aerospace, and automotive — environments where the threat model includes nation-state actors and the systems have to survive twenty years without a patch window. That background is why I look at running systems rather than architecture diagrams. PhD in computer science, CISSP.
Why AI security is a different problem
When your team deploys an AI agent or LLM-powered feature, you’re not just adding a new service. You’re adding a new class of attack surface that most existing security frameworks weren’t designed to handle:
- Prompt injection attacks that manipulate model behavior the same way SQL injection manipulated databases
- Agent privilege escalation when an AI with system access is compromised through its inputs
- Data exfiltration through model outputs — training data, RAG context, and user data leaking through seemingly benign completions
- Multi-tenant vector database isolation failures where one tenant’s data surfaces in another’s queries
- MCP server vulnerabilities that expose your internal tools and systems to manipulation through AI interfaces
- Agentic loops and tool misuse when autonomous agents execute unintended actions with real consequences
Your SOC2 audit doesn’t have questions about prompt injection. Your Kubernetes policies don’t know how to scope LLM inference workloads. Your compliance team has never reviewed a vector database for tenant isolation. This is the gap I close.
From critical systems to AI security
The foundation
My career started with a question that still drives everything I do: How do we help organizations produce secure and reliable software in environments where failure has real consequences?
That question became my PhD research focus, pursued through collaborative work with Airbus and other aerospace partners. Security and reliability aren’t features you add after the fact. They’re architectural decisions that determine whether you can ship, scale, and survive an incident.
Five industries, one repeating pattern
Over 15 years I worked across five industries where security failures carry real consequences:
Banking (Société Générale): Where a breach means immediate regulatory action and lasting customer trust destruction. Compliance isn’t bureaucracy; it forces you to think through edge cases before they become incidents.
Defense & Government: Where threat models include nation-state actors and the consequences of failure are measured in lives, not dollars. Security has to work even when attackers have unlimited time and resources.
Aerospace (Airbus): Where systems must function reliably for 20+ years. I learned to architect for the long term and design systems that degrade gracefully under attack.
Automotive (Volvo Cars): Leading cloud security for connected vehicles: millions of internet-connected endpoints that can’t be easily patched. Modern cloud-native security principles apply even to cars.
SaaS & AI Products: Helping mid-market and enterprise companies deploy AI systems that can scale from prototype to production without a security rewrite.
The pattern I keep seeing
Across all these industries, the same mistake repeats:
Organizations optimize for speed to market, then discover their AI architecture won’t support the security controls they actually need.
A team builds a working LLM prototype. It works in demos. Then they try to add multi-tenancy, audit logging, rate limiting, prompt validation, and compliance controls to code that was never designed for any of it. The refactor takes 6 months and costs hundreds of thousands. Or worse, they ship it anyway.
What’s different about AI
AI systems amplify this problem in ways traditional software doesn’t. An AI agent doesn’t just serve data. It makes decisions, calls external APIs, reads your internal knowledge base, and acts on behalf of users. When that agent is compromised through a malicious prompt in a document it was asked to summarize, the consequences aren’t a 404 error. They’re unauthorized actions with real-world effects.
This is the security challenge I focus on: securing the model’s behaviour as well as the infrastructure, the data it touches, and the systems it can reach.
How I work
Start from the running system
Threat models drawn on architecture diagrams miss what is actually reachable. I start from what is deployed: which models are live, what the agents can call, which credentials those calls carry, and where the data goes afterwards. The gap between the diagram and the deployment is usually where the finding is.
Reproduce before reporting
Every attack I describe has been run against a working system first, in a lab build or a test deployment. If I can’t reproduce it, I don’t publish it. That means I write about fewer things than I could, and it is the reason the labs are open source: you can check rather than trust.
Controls that survive operations
A control that needs a quarterly audit to stay true has already failed. The ones worth recommending live in the pipeline and the platform: policy as code, sandboxing at the runtime boundary, approval gates on high-consequence tools, and audit trails that can still answer a regulator months later.
Plain language
Not “implement pod security policies” but “this stops a compromised container from reaching your database, which is the difference between a contained incident and a reportable breach.” Security decisions are business decisions, and the people signing off deserve to understand the risk they are accepting.
What I’m working on
MCP and agent tool chains. Where the protocol connecting agents to tools breaks down: tool poisoning, meta-context injection, cross-server hijacking. The labs reproduce each one.
Agentic attack surface mapping. How to enumerate what an agent can actually reach, and how far a single injected instruction travels through it. This is the core of the field guide and most of what I write.
Deployment and runtime controls. What actually holds when an agent is live: sandboxing and privilege scope, tenant isolation, approval gates, audit trails that survive a regulator asking how a decision got made. procurement-ai is the reference deployment, with the controls in place from the first commit rather than retrofitted.
Writing. The blog and the AI Security Intelligence newsletter, where the analysis that doesn’t fit a post ends up.
I contribute to the OWASP Agentic Security project, speak at security conferences, and have published peer-reviewed work in cybersecurity and distributed systems.
Who reads this
Security engineers, AppSec teams, and platform engineers running agents in production. Researchers working the same problems. Engineering leaders who need to understand what an AI deployment changes about their risk before it changes it.
If you’re deploying agentic systems and want a second read on the architecture, I do a small number of 30-minute reviews.
Disclosure
I work in industry security alongside this research. Everything published here is my own work and my own opinion — not my employer’s, and not produced on their behalf or with their data. Client and employer systems never appear in what I write; where a real engagement informs the research, it is generalized past the point of identification.
Contact: [email protected] · LinkedIn · GitHub