A defined methodology, applied honestly — not a claimed track record that doesn't exist yet.
AI red teaming here means a defined, repeatable methodology applied to a specific system — discovering weaknesses, exploiting them safely, reproducing the result, measuring real impact, and recommending controls. It is not presented as an established specialism with a long track record; the methodology and its evidence base are being built openly through the Shah AI Security Lab.
Methodology-driven capability under active development in the Shah AI Security Lab. Evidence is published as labs move from planned to completed — see the Lab for current status of each area.
What This Covers
Related Areas
Selected Experience
Supported a major Saudi government organization's migration from a local cloud provider to Google Cloud under Saudi data-residency and cybersecurity requirements. Scope included Windows/Linux workloads, DNS, networking, security architecture, migration, administration and operational support.
Led/supported ISO/IEC 27001 implementation and certification-readiness for a major government organization, including ISMS, risk, controls, remediation and audit preparation.
Architecture and migration work across smaller organizations and large enterprises, including AWS architecture, IAM, networking, Windows/Linux workloads, cloud security and operational planning.
25+ years across Europe, international environments and Saudi Arabia, including experience associated with CERN, the Swedish Defence Research Agency (FOI), Saudi government and regulated/research environments.
How an Engagement Works
Every engagement starts with your situation, not a methodology deck. Four steps, each with a clear output — and a no-obligation free 30-minute review if you want to test the fit first.
A short conversation about the decision in front of you: the environment, the constraints, the objective and who has to sign off.
We agree what is being solved, what information and access are needed, what you receive at the end and where the engagement stops. NDA and confidentiality requirements are accommodated where required.
Architecture and documentation review, stakeholder discussions, technical assessment and/or workshops — whichever the agreed scope needs.
You receive clear executive findings plus technically actionable recommendations. Implementation or ongoing advisory can be scoped separately if you want it.
Common Questions
Through structured testing against retrieval-specific failure modes — cross-tenant leakage, context leakage, over-broad retrieval and vector database authorization gaps — not just testing the model in isolation. See LLM & RAG Security Assessment.
Potentially, via indirect prompt injection or malicious document content embedded in what gets retrieved. This is assessed directly as part of RAG and agentic AI security review.
This is the core question behind Agentic AI & MCP Security — reviewing tool permissions, delegation, identity propagation and human-approval boundaries so a manipulated agent can't act outside intended scope.
Agent identity and delegated authority should be explicit, scoped and auditable — not inherited implicitly from a user or service account. This is reviewed as part of an AI security architecture review.
It depends on data sensitivity, latency, cost, regulation and operability — an architecture decision, not an ideological one. See Secure Private / Sovereign AI.
Through an AI inventory, an acceptable-use policy and, where appropriate, an LLM gateway that enforces model allowlists and data-protection controls centrally rather than per team.
With enough context to investigate an incident — identity, prompt, retrieved context, model used, tool invocation and the authorization decision made — designed in from the start rather than added after a gap is found.
By treating AI-specific events (prompt, retrieval, agent/tool activity) as another log source feeding existing detection engineering and incident-response processes, not a separate silo.
Through an AI security posture assessment covering the vendor's model/data handling, authentication, data residency, sub-processor use and incident-response commitments — alongside the usual vendor-security review.
ISO/IEC 42001 is designed to extend an existing ISMS, not replace it — AI-specific risk management and lifecycle controls sit alongside ISO/IEC 27001's information-security management system rather than duplicating it.
They shape where models and data can run, what monitoring and human oversight are expected, and how third-party AI services are governed — addressed directly in Secure Private / Sovereign AI and AI Governance & Assurance.
Tell me what is being decided and what is at stake. I will first say honestly whether my experience fits — then we talk about scope, not before.
Or connect on LinkedIn first.