I’m happy to have completed TryHackMe’s AI Security course recently. It gave me an opportunity to explore AI security in a more hands-on way and connect it with questions I already encounter through cybersecurity risk and governance.
One idea stayed with me: AI risk becomes much more concrete when you draw the system.
Why the architecture matters
AI security can sound abstract when it is discussed only as a list of possible threats. Mapping the architecture gives those threats somewhere to land.
What model is being used? Where does the data come from? Which components can call tools or retrieve information? Where are users, services and external providers trusted? Once those relationships are visible, it becomes easier to ask what can cross each boundary and what should be checked before it does.
This is familiar security thinking applied to a system with some unfamiliar components. The diagram does not answer every question, but it makes the questions easier to see.
From a diagram to attack surfaces
With the system mapped, I could connect parts of the design to attack surfaces described by resources such as the OWASP Top 10 for Large Language Model Applications and MITRE ATLAS.
The point was not to collect framework names. It was to understand where a threat could enter, what it could influence and what evidence might show that the system had behaved unexpectedly.
- Inputs can influence model behaviour or downstream actions.
- Retrieved content can cross a trust boundary with instructions that were not expected.
- Tools and plugins can extend the impact of a model output.
- Training, tuning and evaluation data can create risks of its own.
- Monitoring and response need to account for model and application behaviour together.
Secure design at the boundaries
The useful design questions appeared at the boundaries between components:
- What is allowed to cross?Define the data, instructions and actions that a component is permitted to receive or produce.
- What should be validated?Do not assume that a plausible model output is a safe instruction for another system.
- What needs a human decision?High-impact actions may need approval, separation of duties or a clear stop condition.
- What should be logged?Useful records need enough context to reconstruct an interaction without collecting more sensitive data than necessary.
These questions connect technical design with governance. They also make it easier to explain AI risk to stakeholders who do not need to become machine-learning specialists in order to make a responsible decision.
The supply chain is part of the system
Another useful reminder was that the model is only one part of the AI supply chain. Models, datasets, libraries, hosted services, evaluation tools and deployment components can all affect the security and reliability of the final system.
That raises practical questions about provenance, ownership, dependency changes and what happens when a provider or component behaves differently from what was originally assessed. A system diagram that includes those dependencies gives governance conversations a more concrete starting point.
What I am taking forward
I am not presenting this course as making me an AI-security expert. It was a focused learning experience, and the value for me was in connecting hands-on exploration with established risk and security habits.
My main takeaway is simple: draw the system before trying to describe the risk. The architecture helps reveal trust boundaries, attack surfaces, supply-chain dependencies and the decisions that need an accountable owner.
That feels like a useful way to keep AI security practical while I continue developing my understanding of AI governance, risk and security.