Microsoft AI-901: AI Security and Governance

AI-901 treats security and governance as foundational parts of an AI solution, not as specialist topics reserved for advanced certifications. The April 2026 blueprint explicitly includes privacy and security within responsible AI, expects familiarity with Azure resources, and assumes candidates understand that applications built in Microsoft Foundry still operate inside normal cloud security boundaries. The result is a fundamentals topic that combines identity, data protection, model behavior, and operational accountability.

The easiest way to reason about this area is to separate four questions: who is allowed to use the system, what data the system can access, what the model or agent is allowed to do, and how the organization proves that these controls are working. Security answers the first three; governance makes the answers explicit, reviewable, and owned.

AI security starts with identity and least privilege

Every user, service, and automated component should have only the permissions it needs. This principle matters even more when an AI application can retrieve enterprise data or invoke tools. A model may be capable of drafting a database query, but capability is not authorization. The application must still determine whether the caller is allowed to read that data or execute that action.

The ExamTopics role-based access control provides useful background for this permission model. Roles reduce the temptation to grant broad permissions directly to individuals and make access easier to review. In an AI solution, role design should cover both human users and machine identities.

Authentication and authorization solve different problems

Authentication establishes who or what is making a request. Authorization determines what that identity is permitted to do. Confusing the two leads to weak designs. A user may authenticate successfully yet still be prohibited from accessing a particular dataset, model deployment, tool, or administrative function.

AI scenarios often introduce an additional layer: the model itself may generate a request to use a tool. The application must authorize that action using the user’s or workload’s permissions. Trusting model output as if it were an authenticated instruction can turn a prompt into a privilege-escalation path.

Data security follows the data through the entire AI workflow

AI data can appear in prompts, retrieved documents, conversation history, uploaded files, vector indexes, logs, and generated output. Protecting only the original database is not enough. A secure design maps where sensitive information enters the system, where it is copied, how long it persists, and which components can read it.

Encryption, access control, data minimization, retention rules, and monitoring all contribute. The familiar confidentiality, integrity, and availability model remains relevant because AI does not change the underlying need to keep data secret from unauthorized users, correct and trustworthy, and available when legitimate users need it.

Prompt injection is an application-security problem

Generative AI systems process natural-language instructions, including instructions that may come from untrusted users or retrieved content. A malicious prompt may try to override system rules, expose hidden context, or persuade an agent to misuse a tool. The model can be manipulated because it is designed to follow language.

Defenses therefore cannot rely on a single “do not reveal secrets” instruction. A safer design treats untrusted content as data, constrains available tools, validates important actions, separates sensitive context, and requires authorization outside the model. The core principle is familiar from traditional security: never let untrusted input directly control privileged operations.

Governance defines what the system is allowed to become

Governance converts organizational expectations into decision rights and controls. It should identify owners, approved use cases, data classifications, model-selection rules, change processes, review requirements, and incident paths. Without governance, teams may build technically functional AI solutions that use inconsistent data, unmanaged models, or unclear risk assumptions.

At a fundamentals level, governance can be understood as the system around the system. It answers who approves a new model, who reviews sensitive data use, who owns production behavior, and what evidence is required before the solution can be deployed or changed.

Model and deployment choices can have governance consequences

Choosing a model is not purely about quality. Different deployments can have different cost, latency, regional availability, data-handling constraints, and operational characteristics. A governance process should ensure that teams do not select a model solely because it performs well in a demo while ignoring residency, privacy, or support requirements.

This is why AI-901 combines model capability with deployment options and configuration. The correct solution is the model and deployment that meet the business requirement within the organization’s technical and governance boundaries.

Logging makes AI activity reviewable

Security controls are stronger when consequential events can be reconstructed. Logs may record authentication, model requests, tool calls, policy decisions, errors, and administrative changes. The design should avoid logging secrets or unnecessary personal data, but it should retain enough evidence to support troubleshooting and incident review.

For agentic systems, action logs become especially important. If an agent can send a message, update a record, or call an external service, the organization should be able to determine who initiated the workflow, what the agent attempted, what was authorized, and what actually happened.

Risk treatment should be proportional to impact

Not every AI application needs the same control depth. A low-impact internal writing assistant can tolerate more uncertainty than a system that changes customer accounts or advises on safety-critical operations. Governance should therefore classify use cases by risk and apply stronger testing, approval, monitoring, and human oversight as consequences increase.

A structured risk register is useful general context because it turns vague concerns into named risks with owners and treatment decisions. That same discipline applies to AI-specific risks such as hallucination, data leakage, unsafe autonomy, or biased outcomes.

Security and governance should not destroy usability.

Controls that are too weak create risk, but controls that are unusable encourage workarounds. Good architecture makes the secure path the practical path. Clear access roles, approved data sources, reusable model deployments, standard logging, and predefined review patterns help teams build safely without inventing governance from scratch for every project.

The broader Microsoft certifications includes much deeper security credentials, but AI-901 candidates need the foundation: identity, least privilege, protected data, controlled actions, governance ownership, and reviewable operations.

Use a four-layer checklist for AI-901 scenarios

When a security or governance scenario appears, classify it by layer. Identity: who is calling? Data: what information can be seen? Action: what can the model or agent do? Governance: who owns the rule and how is it reviewed? This prevents common mistakes such as using authentication to solve an authorization problem or relying on a prompt to solve a privilege problem.

AI security is not a separate product feature. It is the combination of familiar cloud controls with AI-specific failure modes. If you can connect those controls to real scenarios, you will be better prepared for the current fundamentals exam and for the more advanced Microsoft AI roles that build on it.

Threat modeling can make AI security more concrete. Identify the assets that matter, the trust boundaries between users and services, the untrusted inputs the system accepts, and the privileged actions it can perform. Then ask how an attacker could misuse each boundary. This exercise often reveals that the highest risk is not the model itself but the connection between model output and a powerful tool or sensitive data source.

Data residency and regulatory requirements can also constrain deployment. An organization may need to keep particular data in approved regions, restrict which teams can use a dataset, or prove that retention rules are being followed. Those requirements should be known before teams choose models and integrations, because moving a solution after launch can be more expensive than designing within the boundary from the start.

High-impact agent actions benefit from explicit approval patterns. An agent can prepare a proposed change, but a separate authorization step can require a human or policy engine to approve it before execution. This separation preserves the productivity benefit of AI while preventing the model from becoming the final authority for sensitive actions.

Governance should also cover model and prompt changes. A small prompt edit can materially change behavior, and switching to a different model can alter quality, latency, safety characteristics, and cost. Versioning important configuration and testing changes before release creates a traceable path from intent to production behavior.

Third-party dependencies belong in governance as well. An application may rely on external data sources, plugins, APIs, or models. Each dependency can change behavior, become unavailable, or introduce a new data path. Governance should therefore record critical dependencies and define how changes are reviewed before they reach production.

Security testing should include misuse, not only normal functional tests. Try unauthorized users, manipulated prompts, malicious retrieved content, unexpected tool parameters, and attempts to expose restricted context. The goal is to verify that the application’s authorization boundaries hold even when the model produces an unsafe suggestion.

A practical governance review can therefore be short but disciplined: identify the use case, data classification, identities, available tools, model deployment, retention policy, evaluation evidence, monitoring plan, and accountable owner. If one of those elements is undefined, the solution may still function technically, but it is not yet ready to be trusted as an enterprise AI system.