Securing an AI system is mostly ordinary security applied carefully, and a smaller part of it is specific to there being a model in the path. The ordinary part comes from cloud security practice as it has stood for fifteen years, with identity, encryption and a published division of responsibility between provider and customer. The specific part comes from the attack research of the last few years, catalogued in the MITRE ATLAS knowledge base since 2021 and in the NIST taxonomy of adversarial machine learning published in 2024. The AWS syllabus tests both parts, and the Practitioner course cares because the specific part is where teams are least practised.
The sections below take the shared responsibility model, identity and access, encryption, the services for finding and protecting sensitive data, the secure data engineering practices, the attack surfaces a model adds and the ordinary practices that still apply, and end with a fifteen minute drawing exercise.
Where the shared responsibility line falls
Every major cloud publishes a version of the same idea. The provider secures the cloud itself and the customer secures what is put in it, with the line between them moving depending on which service is used.
With a fully managed model service, whether Amazon Bedrock, Azure OpenAI or Vertex AI on Google Cloud, the provider runs the model and the infrastructure, and the customer owns identity, access policy, encryption keys, what is sent and what the application does with what comes back. With a model the team hosts itself, patching and network configuration become the team's as well.
What matters is being able to place a given responsibility on the correct side, because the failures happen in the gap where each party assumed the other had it.
Identity and access as the primary control
Of the responsibilities on the customer's side, identity comes first. IAM roles, policies and permissions are the primary control. A model endpoint is a resource like any other, and least privilege applies to who can call it, who can change it and who can read the data it was trained on.
The training data usually carries more risk than the model. It is the largest collection of sensitive material in the project, and it is frequently the least protected, sitting in a bucket somebody opened during development and nobody closed.
Encryption at rest and in transit
Access control decides who may reach the data, and encryption decides what a person who reaches it anyway can read.
At rest covers training data, model artefacts, logs and any store of embeddings. Embeddings deserve particular attention, because they are derived from source documents and are often treated as harmless numbers when research since 2023 has shown they can be partially inverted back into the text they came from.
In transit covers every call. Where a review requires that traffic never touch the public internet, every platform has a private connectivity product for it, AWS PrivateLink, Azure Private Link and Google Private Service Connect. Encryption protects the content of a request and does not change the path it takes, which is the distinction that requirement turns on.
Finding sensitive data and protecting it
Encryption assumes the team knows where the sensitive data is, and a class of service exists because it usually does not.
Sensitive data discovery scans storage and classifies what it finds, which is how a team learns that personal information reached a training set. Amazon Macie is the AWS service, Google Cloud has Sensitive Data Protection, formerly Cloud DLP, and Azure has Purview.
The distinction worth holding is between locating sensitive data and protecting it. Discovery answers the first question, and encryption and access policy answer the second.
Data lineage and cataloguing record where data came from and how it moved. This is a security control as well as a governance one, since nobody can honour a deletion request or answer a breach question without knowing what a dataset contains and what was trained on it.
Secure data engineering practices
Lineage is one of four practices the syllabus names for the data itself. Assessing data quality, since bad data produces bad decisions at scale. Privacy enhancing technologies, such as anonymisation, tokenisation and masking before data reaches training. Access control, applied to the data as tightly as to the model. Data integrity, so nobody can alter a training set or an index without it being noticed, which is the defence against poisoning.
The attack surfaces that exist because a model is in the path
Everything above would apply to a data warehouse. Four surfaces exist only because a model is present.
Prompt injection is untrusted text that overrides the developer's instructions. It matters most when the model can act, since an agent with tools turns a text attack into a real one. The controls are filtering input and output, giving tools the narrowest permission that works, and treating model output as untrusted input to whatever consumes it.
Data poisoning corrupts training data or a retrieval index so the system learns or repeats something planted.
Model extraction rebuilds a model by querying it enough times, which is what rate limiting on an endpoint is partly for.
Sensitive disclosure is the model repeating something from training data or from context. Anything placed in a prompt can come back out, and the 2023 case of engineers at a large electronics firm pasting proprietary source code into a public chat service is the reminder that the disclosure often begins on the customer's own side.
Managed filtering is the control that helps, applying content filters, denied topics and word filters to both directions of the exchange. Guardrails for Amazon Bedrock, Azure AI Content Safety and Model Armor on Google Cloud all do this, and none of them removes the need to treat model output as untrusted input downstream.
The ordinary practices that still apply
The specific surfaces sit on top of the ordinary ones, which do not go away. Application security, vulnerability management, infrastructure protection and threat detection. The tooling is whatever the team already uses for any other workload, GuardDuty, Inspector and CloudTrail on AWS, Defender for Cloud on Azure, Security Command Center on Google Cloud.
Practise this
The exercise needs one sheet of paper and fifteen minutes. Use no diagramming tool, because what can be produced without one is the whole point of the exercise.
Draw the feature from memory before opening any code. Mark two things separately, every arrow carrying content the team did not write, and every box that can change something outside the team's own process. Then open the repository and correct the drawing against what is actually wired up.
Draw it from memory first, then correct it.
[ user ] --> [ the app ] --> [ model ]
| |
[ retrieval ] [ tools ]
| |
[ documents ] [ effects ]
Mark every place untrusted content enters:
user message, uploaded file, retrieved chunk, tool result,
fetched web page, email or ticket body, another agent's output
Mark every place the system can act:
writes a record, sends a message, calls a paid API, moves money,
changes a permission, deletes something
For each action, answer: whose credential, and can it be undone?
Look for the arrows missing from the first drawing, which are almost always the tool result coming back into context and the retrieved chunk, since both feel like the team's own data and neither one is. The distance between the drawing from memory and the corrected one is a fair measure of how well the boundary is understood by the people maintaining it.
Nobody defends a boundary they cannot draw, and most teams find out here that they cannot draw theirs.