Episode 64 — Domain 3 overview: secure AI technologies using architecture and controls (Task 10)

In this episode, we shift into Domain 3, which is where security starts to feel more concrete because it connects to how A I technologies are designed, connected, and protected. Domain 2 trained your risk mindset, but Domain 3 asks you to apply that mindset to real technical decisions without getting lost in tool details. The central idea is that security is not something you bolt onto A I after it is built; it is something you shape through architecture and controls from the beginning. Architecture is the big picture of what connects to what, what crosses boundaries, and where decisions and data move. Controls are the safeguards that reduce risk inside that architecture, such as access control, isolation, monitoring, and protection of sensitive assets like data and model artifacts. Domain 3 is about making those two ideas work together so the A I system is safe, trustworthy, and manageable over time.

Before we continue, a quick note: this audio course is a companion to our course companion books. The first book is about the exam and provides detailed information on how to pass it best. The second book is a Kindle-only eBook that contains 1,000 flashcards that can be used on your mobile device or Kindle. Check them both out at Cyber Author dot me, in the Bare Metal Study Guides Series.

A useful starting point for beginners is to define architecture in plain terms. Security architecture is a map of how a system is put together, including the major components, how they communicate, and which parts you trust more or less. For A I, the components might include data sources, a pipeline that prepares data, a training environment, a model storage area, a serving layer that produces outputs, and the applications that use those outputs. Architecture is not a diagram you admire; it is a way of thinking that helps you predict where risk concentrates. If you know where data enters, where it is transformed, and where outputs leave, you can ask where attackers might interfere, where mistakes could leak information, and where controls should be strongest. Domain 3 begins by training you to see A I systems as connected ecosystems rather than mysterious black boxes.

The next concept is what it means to secure A I technologies rather than just secure a server or a network. A I introduces assets that are easy to overlook, such as training datasets, labeled data, prompt content, embeddings, inference logs, and model weights. These assets can carry sensitive information or represent valuable intellectual property. If an attacker steals model weights or training data, they may gain insights into what the organization knows, how it makes decisions, or how to manipulate outputs. If prompts and logs are exposed, they can reveal user intent, private data, or internal business context. Securing A I technologies means you treat these assets as first class security concerns, and you place them deliberately within the architecture so they are protected by design.

Domain 3 also brings in a key idea that beginners need early: trust boundaries. A trust boundary is the line where your assumptions change, such as where data leaves your environment and enters a vendor service, or where an internal user request becomes an external A I call. When something crosses a trust boundary, you should assume risk increases, because you have less control and less visibility. Domain 3 wants you to design systems so trust boundaries are clear, because unclear boundaries create hidden risk. If you do not know when data leaves your organization, you cannot manage privacy or compliance. If you do not know which identities can reach the model, you cannot prevent misuse. Architecture is how you make trust boundaries explicit, and controls are how you protect what crosses them.

Controls, in Domain 3, should be understood as guardrails that are chosen because they match real risks. A control might limit access to data so only approved identities can use it. A control might isolate the training environment so it cannot be reached directly from general corporate networks. A control might require logging and monitoring so unusual usage patterns are detected quickly. A control might enforce data classification rules so sensitive data is masked or restricted from certain processing steps. The important beginner lesson is that controls are not random best practices; they are targeted decisions that reduce risk in the places architecture shows you are vulnerable. In other words, architecture tells you where you are exposed, and controls tell you what you do about it.

It is helpful to connect Domain 3 back to the A I lifecycle you already know exists, even if you have not studied it deeply yet. A I systems are built, trained, deployed, and maintained, and the security needs shift across those phases. The training phase might emphasize protecting data sources, controlling who can modify training inputs, and isolating compute environments. The deployment phase might emphasize strong identity control, rate limiting, logging, and protection of the model serving endpoint. The maintenance phase might emphasize safe updates, version control of models, continuous monitoring, and controlled rollback when something goes wrong. Domain 3 does not ask you to become an engineer, but it does ask you to understand that security controls must follow the system across its stages, because the risk moves as the system moves.

Another core Domain 3 idea is attack surface, which is the set of ways a system can be attacked or misused. Beginners often imagine attack surface as only open network ports, but in A I it includes more, such as exposed A P I endpoints, integration points with other applications, ways users can provide input, and places where sensitive data is stored or logged. Every integration adds complexity and potential paths for misuse. Domain 3 encourages you to reduce attack surface through architectural choices, like limiting where the model can be called from, minimizing unnecessary connections, and controlling how data is shared. When you reduce attack surface, you are not guaranteeing safety, but you are shrinking the number of doors and windows an attacker or accident can use.

Identity is another major theme, because access to A I capabilities can be powerful. If a user can query an internal model that has access to sensitive data, that user might be able to extract information through clever prompts or repeated requests. If a system account can call external A I services, that account might leak data unintentionally if it is misconfigured. Domain 3 pushes you to think about who is allowed to do what, from humans to services to administrators. Strong identity controls include clear roles, least privilege access, and separation of duties so no single identity has unnecessary power. Even as a beginner, you can understand that controlling access is one of the most reliable ways to reduce risk, because it limits both malicious actions and accidental misuse.

Data protection is equally central, because data is the fuel of A I and also one of the biggest sources of harm when mishandled. Domain 3 asks you to think about where data is stored, how it moves, and how it is protected at rest and in transit. It also asks you to consider whether sensitive data should be used at all, and whether data minimization can reduce risk. If the system can work without collecting certain data, not collecting it is often the best security decision. When data must be used, controls should ensure it is accessed only by authorized identities, stored securely, and retained only as long as needed. Architecture helps you see data flows, and controls help you keep those flows from turning into leaks.

Monitoring and logging also show up early in Domain 3 because you cannot secure what you cannot observe. A I systems often have usage patterns that look normal until they are not, and small anomalies can signal misuse or early attack attempts. Logging should capture enough detail to understand what happened without turning into an uncontrolled collection of sensitive information. Monitoring should look for unusual access patterns, spikes in usage, repeated attempts to elicit restricted outputs, or unexpected changes in model behavior. The beginner takeaway is that monitoring is not just an operational convenience; it is a control that supports detection, response, and continuous improvement. In a well designed architecture, monitoring is built in rather than added as an afterthought.

One reason Domain 3 is important is that it helps prevent a common organizational failure: building shadow systems. Shadow systems happen when teams adopt A I tools or services outside the normal architecture and governance, often because they want speed or flexibility. The risk is that these systems bypass identity controls, data standards, monitoring practices, and vendor oversight. Domain 3 prepares you to recognize why shadow systems are dangerous, because they create hidden trust boundaries and unmanaged attack surface. A secure A I program encourages innovation, but it channels innovation through architectures and controls that maintain safety. This is not about slowing everything down; it is about preventing surprises that could harm users and create regulatory or reputational damage.

As you move deeper into Domain 3, you will learn specific ways to design trust boundaries, document data flows, reduce attack surface, and apply controls across identities, secrets, and isolation. You will also learn how to integrate A I architecture into enterprise architecture, which means aligning with existing identity, network, and data standards rather than creating a separate world. The big picture is that A I security management is not magic and not guesswork. It is a set of disciplined choices that start with architecture and are reinforced by controls. When those choices are made well, systems become easier to operate, easier to audit, and safer for the people who rely on them.

To wrap up this overview, remember that Domain 3 is where your risk knowledge turns into design knowledge. Architecture helps you see the system clearly, including what crosses trust boundaries and where the most sensitive assets live. Controls help you reduce risk in those key locations, including identity controls, isolation, data protections, and monitoring. Reducing attack surface and preventing shadow systems are practical outcomes of making those choices intentionally. As you continue, you will build a vocabulary for talking about secure A I technologies in a way that is understandable, defensible, and connected to real risk. That is the core purpose of Task 10, and it sets the foundation for everything else that follows in this domain.

Episode 64 — Domain 3 overview: secure AI technologies using architecture and controls (Task 10)
Broadcast by