Certified: The ISACA AAIA Audio Course

In this episode, we focus on a security foundation that shows up everywhere, but becomes even more important when A I is involved: Identity and Access Management (I A M). When you are new to cybersecurity, it can feel like I A M is just usernames and passwords, and the rules about who can log in where. That is part of it, but the deeper idea is about making sure only the right people and systems can reach the right resources, at the right times, for the right reasons, and with the smallest amount of power necessary. A I environments add new resources that must be protected, such as models, training data, retrieval data sources, and the keys or tokens that allow access to those things. If an attacker gets access to one of these resources, they might not need malware or exploits, because access alone can let them steal data, modify behavior, or trigger expensive actions. Your goal here is to learn how to evaluate whether an organization’s I A M program truly covers A I models, A I data flows, and A I secrets, rather than only covering the servers around them.

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 good place to start is to define what the protected resources are, because access management only makes sense when you can name what you are controlling access to. In A I systems, there are model artifacts, which are the actual trained model files or hosted model endpoints that generate outputs. There are data resources, which include training data, fine-tuning data, evaluation data, and retrieval sources like internal documents or databases. There are also keys and tokens, which are secrets that let applications talk to model services, data stores, and tool integrations. Each of these resources has different consequences if it is accessed by the wrong party. If someone accesses the model endpoint, they can probe it, try to extract behavior, or cause it to output sensitive content. If someone accesses training or retrieval data, they can steal it, poison it, or learn what the organization knows. If someone accesses keys, they can often impersonate systems and bypass user-level safeguards. Evaluating I A M starts with confirming that the organization has an inventory of these resources and has defined who is allowed to use each one.

Once you know the resources, you need to know the identities that access them, because A I systems often involve more identities than a beginner expects. There are human users, such as developers, data scientists, analysts, and business users interacting with an A I assistant. There are also non-human identities, often called service accounts, that allow applications and pipelines to run automatically. For example, a data pipeline might read data from storage, preprocess it, and write it to a training environment, all without a human clicking anything. A retrieval system might fetch documents from an internal repository and pass them to a model, using its own credentials. These non-human identities are essential, but they can also be dangerous because they tend to have broad access and they run continuously. When you evaluate I A M for A I, you should expect the program to treat non-human identities as first-class citizens, with strict controls, strong authentication methods, careful permission design, and clear ownership. A system that has strong rules for humans but weak rules for service accounts is not truly secure.

Authentication is the first gate in access control, and the evaluation question is whether the organization uses strong, consistent authentication for both humans and systems. For humans, you look for multi-factor authentication, which is the idea that logging in should require more than one type of proof, such as something you know plus something you have. For systems, you look for secure methods of proving identity, such as short-lived credentials, certificate-based authentication, or managed identity mechanisms that avoid static secrets. In A I environments, static keys are especially risky because they can leak through logs, code repositories, or accidental sharing, and once leaked they can often be used from anywhere. A mature program reduces reliance on long-lived keys, rotates secrets regularly, and monitors for unusual use of credentials. Evaluating authentication also includes checking whether privileged access, like the ability to modify model settings or access training data, has stronger requirements than basic usage. Strong I A M is about graded controls, where higher risk actions require stronger proof and tighter oversight.

Authorization is the next layer, and this is where you evaluate what someone can do after they are authenticated. In simple terms, authorization answers the question: what are you allowed to access and what actions are you allowed to perform. For A I, authorization needs to be detailed enough to separate roles like using a model, viewing prompts, editing prompts, connecting new data sources, changing safety settings, deploying new model versions, and accessing training datasets. In many organizations, it is tempting to give broad access to move fast, especially when A I projects are new. Broad access feels convenient but creates a situation where one compromised account can lead to large-scale harm. A strong program uses role-based access control, where permissions are grouped into roles aligned with job functions, and the roles are designed to be minimal rather than maximal. When evaluating, you want to see clear separation between read access and write access, and separation between low-impact actions and high-impact actions. The easiest way to spot weak authorization is to look for many people who can change critical settings without review.

Least privilege is a core I A M principle, and it becomes a practical evaluation tool when you apply it to models, data, and keys. Least privilege means identities should have only the access they need to do their job, and no more. In A I systems, the places where least privilege breaks down are often the pipelines and integrations, because people give them wide access to avoid troubleshooting. A training pipeline might be allowed to read every dataset, even those unrelated to the model. A retrieval component might be allowed to read entire repositories, even though the assistant should only see a limited subset. An application might store a master key that grants full access to a model service, even though it only needs access to one endpoint. Evaluating least privilege involves checking whether permissions are scoped narrowly, whether access is limited by environment such as development versus production, and whether there are constraints like network boundaries that reduce where credentials can be used. A mature program expects attackers to try to pivot, so it designs access so that one identity cannot easily expand its reach.

A I-specific access evaluation also includes understanding the difference between access to model usage and access to model management. Using a model means sending it requests and receiving responses, and that can still be sensitive, especially if the model can access internal data. Managing a model includes actions like changing system instructions, altering safety parameters, swapping model versions, enabling tools, and connecting new retrieval sources. Management access should be far more restricted than usage access because it changes what the system can do for everyone. If an attacker gains management access, they can silently weaken controls or redirect the model to pull from sensitive sources. That kind of compromise can persist and affect many users without obvious signs. Evaluating this means checking that management actions require privileged roles, stronger authentication, and change approval processes, and that the system logs all management events with clear attribution. A program that treats management access like ordinary usage access is leaving a large door unlocked.

Keys and secrets deserve special attention because they often become the real control point in A I services. A key might grant access to a hosted model endpoint, to a vector store, to an internal document repository, or to a tool integration that performs actions. If a key leaks, the attacker may not need a user account at all, because the key is the identity. Evaluating how keys are handled means asking where secrets are stored, how they are distributed to applications, whether they are rotated, and whether the organization can revoke them quickly. You also want to know whether secrets are segmented, meaning one key should not grant access to everything. A mature program uses separate keys for separate purposes, limits each key’s permissions, and uses short-lived tokens where possible so stolen credentials expire quickly. Monitoring also matters here, because even a well-managed key can be abused if it is used from unexpected locations or at unusual volumes.

Another important concept is access governance, which is the ongoing process of reviewing who has access and removing what is no longer needed. Access tends to expand over time, especially during projects, because people request permissions to solve a problem and then keep them indefinitely. In A I programs, this can lead to large groups of people retaining access to training data, model management consoles, or prompt repositories long after their role changes. A strong evaluation looks for periodic access reviews, approval workflows for granting privileged access, and automated mechanisms to remove access when people leave a team. It also looks for clear ownership, meaning there is someone accountable for deciding who should have access to each A I resource. If no one owns the access decisions, then access will naturally drift toward maximum openness. Governance is not just paperwork; it is what keeps least privilege alive over time.

Segregation of duties is another classic security concept that becomes very relevant in A I. Segregation of duties means no single person should have enough power to make a high-risk change without someone else being able to review or stop it. In A I systems, high-risk changes include modifying system instructions, enabling new tool actions, connecting new data sources, changing safety settings, or deploying a new model into production. If one person can do all of that alone, then an attacker who compromises that person’s account gains enormous power. Evaluating segregation of duties includes checking whether critical changes require peer review, whether production deployments require separate approvals, and whether the environment enforces these rules technically rather than relying only on policy. This is especially important for beginners to understand because it shows that security is not just about stopping outsiders; it is also about preventing accidents and limiting the damage from insider threats and compromised accounts.

Logging and auditing are the final pieces that tie I A M to real-world security outcomes, because without logs you cannot prove who did what. For A I, you want logs of authentication events, authorization decisions, and privileged actions, as well as logs that show which identities accessed which datasets, which model endpoints, and which management controls. You also want to ensure that logs capture changes to prompts and system instructions, because those changes can effectively redefine the system’s behavior. Evaluating logging means checking that it is comprehensive, that it is retained long enough to investigate incidents, and that access to logs is restricted so attackers cannot alter them. It also means checking that someone actually reviews the logs or alerts on suspicious activity, such as unusual access to training datasets or unexpected changes to model configurations. Good I A M is visible, because it leaves a clear trail when something changes. Invisible I A M, where access is granted informally and changes are not tracked, is hard to defend and hard to audit.

As you bring everything together, the simplest way to evaluate I A M for A I models, data, and keys is to ask whether access is intentional, minimal, and observable. Intentional means the organization can clearly explain who should access each resource and why. Minimal means permissions are narrowly scoped, management access is tightly restricted, secrets are segmented, and service accounts are not granted broad blanket permissions. Observable means actions are logged, privileged changes are traceable, and monitoring can detect unusual use of accounts and keys. A I systems make these principles more important because the assets are powerful and the consequences of misuse can be subtle at first, like quiet data exposure or gradual control weakening. When you can evaluate whether the organization applies strong I A M not only to servers but also to models, data pipelines, and secrets, you are checking one of the most important foundations for secure A I operations.