AI security in a Microsoft environment is not a new control category that sits beside identity, data, applications, and infrastructure. It cuts across all of them. A generative AI app can read enterprise data, run under a workload identity, call tools, trigger business processes, expose an API, and generate content that users treat as authoritative. The security problem is therefore architectural: every layer that gives the AI system context or agency creates a boundary that must be understood and governed.
The current SC-100 scope reflects that change. Microsoft now expects cybersecurity architects to design security for AI as part of Zero Trust, cloud security, data protection, application security, identity, security operations, and governance. The goal is not to “secure the model” in isolation. It is to build an operating model in which AI systems have constrained access, protected data, measurable behavior, and accountable owners.
Start with the business process and the assets the AI system can affect
Document the failure modes in business language as well as technical language. A hallucinated answer can become a legal, financial, safety, or customer-service problem depending on the process. An overprivileged tool can create records, send messages, change access, or trigger automation. A poisoned knowledge source can turn a trusted assistant into a delivery mechanism for bad instructions. When those consequences are explicit, security teams can prioritize controls according to impact instead of debating AI risks as abstract possibilities.
Security design should begin before choosing a model or enabling an agent. Identify what the system is supposed to do, whose data it can read, which tools it can invoke, what decisions it can influence, and what happens if it produces a wrong or manipulated result. A chatbot that summarizes public documentation has a very different risk profile from an agent that reads customer records and updates a case-management system.
Map the AI system as a chain of assets: user, application, workload identity, model endpoint, grounding data, search index, tool or API, secrets, logs, and downstream systems. Then mark the trust boundaries between them. This turns vague concerns such as “prompt injection” into concrete questions: Can untrusted content reach a privileged tool? Can one user retrieve another user’s data? Can model output be executed without validation? Can an attacker influence the retrieval source?
Use business criticality to decide where controls are mandatory. A proof-of-concept with synthetic data can accept more uncertainty than an AI workflow that changes financial records. Governance becomes stronger when control depth follows business impact instead of applying the same checklist to every experiment.
Separate human identity, workload identity, and agent identity
Identity architecture should also preserve attribution. Logs need to show which user initiated a workflow, which application or agent executed an action, and which downstream resource authorized it. If every action appears under one powerful service principal, investigation becomes difficult and least privilege becomes hard to prove. Prefer designs in which delegated context, workload identity, and application permissions remain distinguishable enough to support access reviews, incident response, and audit evidence.
Modern AI systems often involve more identities than the end user. The application may use a managed identity to reach Azure resources. An agent may have its own service identity and tool permissions. A background component may call an API without an interactive user present. Security architects need to know which identity is acting at each step and whether permissions are delegated from a user or granted directly to the workload.
Microsoft Entra should be used to centralize authentication and authorization decisions where possible. Strong user authentication, Conditional Access, privileged access controls, workload identities, and lifecycle governance remain foundational. The skills associated with SC-300 become especially relevant when AI adoption creates many new service principals, agents, external integrations, and nonhuman identities.
Do not give an agent broad access simply because it needs to “work across the business.” Define the smallest tool set and data scope that supports the task. Separate read and write operations, use application roles or narrowly scoped permissions, and avoid long-lived secrets when managed identity or federated credentials are available. An AI system should not become a shortcut around the identity architecture.
Govern data before you govern prompts
AI systems frequently inherit the organization’s existing data-access problems. If a user can read overshared documents, an AI assistant may surface that information more efficiently. If a service account has broad database access, an agent running under that identity can expand the impact. Prompt controls do not fix excessive permissions or unclassified data.
Data discovery, classification, sensitivity labels, DLP, retention, audit, and insider-risk controls need to be part of the AI architecture. Microsoft Purview can provide that data-security layer, while SC-401 is an adjacent credential for people who operate information protection and compliance controls in depth. A broader secure data lifecycle is also useful because AI systems can touch information from creation through sharing, retrieval, transformation, and deletion.
Grounding data deserves special scrutiny. Retrieval-augmented generation can improve factual relevance, but it also creates a path from enterprise repositories into model context. Security teams should review which sources are indexed, how access control is enforced at retrieval time, whether sensitive labels or permissions are preserved, and how stale or malicious content is removed.
Threat-model the AI application, not just the model endpoint
Include control bypasses in the threat model. An application may have good content filters while still allowing an attacker to reach an unsafe tool through an indirect prompt, retrieve a document that should have been inaccessible, or exploit a conventional API flaw. Test the complete chain with adversarial inputs and failure scenarios. Security reviews should cover the model, orchestration code, connectors, data stores, identity, network paths, secrets, and the human approval steps that are supposed to stop harmful actions.
AI-specific threats include direct and indirect prompt injection, unsafe tool use, sensitive-data disclosure, malicious retrieval content, model abuse, insecure plugins, output manipulation, and excessive autonomy. Those risks sit beside familiar application-security problems such as broken authorization, insecure APIs, exposed secrets, vulnerable dependencies, and weak input validation.
A useful threat model asks what an attacker can control and what the AI system trusts. User prompts are untrusted. Retrieved documents can be untrusted. Tool results can be manipulated. Model output should be treated as untrusted until the application validates how it is used. The article on AI security risks can deepen that threat perspective, but the control design should stay tied to the actual application architecture.
Build defenses in layers. Constrain tool schemas, validate parameters, restrict network destinations, protect secrets, filter content where appropriate, require human approval for high-impact actions, and log what the agent attempted to do. Do not assume one safety filter can compensate for an overprivileged identity or a tool that accepts arbitrary commands.
Use posture management to find the cloud weaknesses around AI
Prioritize posture findings that intersect the AI system’s actual trust path. An exposed storage account that feeds retrieval, an overprivileged managed identity used by an agent, or an unmonitored compute resource serving a model can matter more than dozens of unrelated low-impact recommendations. Connect posture data to application ownership so remediation reaches the team that can change the architecture rather than remaining in a central backlog.
Many AI incidents will come from ordinary cloud weaknesses: public endpoints, excessive permissions, stale credentials, vulnerable containers, unpatched servers, or exposed storage. Microsoft Defender for Cloud helps architects assess posture across Azure and connected hybrid or multicloud resources and prioritize recommendations based on the environment.
AI security therefore belongs inside the cloud-security program rather than in a separate innovation silo. The cloud security engineering discipline still applies: harden compute, segment networks, protect secrets, govern identities, scan workloads, and monitor posture. The AI layer increases the number of data flows and automation paths, but it does not replace the underlying controls.
Use the Microsoft Cloud Security Benchmark and organizational security standards to create a baseline, then add AI-specific requirements where the workload warrants them. Examples include restrictions on model endpoints, approved model families, private networking, logging requirements, evaluation evidence, data-residency rules, and limits on autonomous actions.
Design governance around ownership, approval, and change
Governance becomes operational when every production AI system has a named owner, an approved purpose, a data boundary, a risk tier, a deployment record, and a change path. Teams should know who can alter prompts, models, tools, retrieval sources, or permissions and which changes require testing or approval. This is particularly important for agents because a seemingly small configuration change can expand what the system can see or do without changing the surrounding application code.
AI governance becomes weak when responsibility is spread across security, legal, data, engineering, and business teams without a named owner. Every production AI system should have a business owner, a technical owner, an identity and data boundary, a risk classification, and a documented approval path for material changes.
For agentic systems, governance should include tool registration, allowed actions, human-approval thresholds, testing requirements, escalation paths, and retirement. Enterprise agent programs often intersect with the business-solution architecture represented by AB-100, where process design and human oversight matter as much as the underlying model.
Change control should cover more than source code. Model versions, prompts, system instructions, retrieval indexes, safety settings, tool schemas, identity permissions, and external connectors can all change behavior. If those components can be modified outside the normal release process, the organization has an ungoverned production surface even when the application repository is tightly controlled.
Make security operations capable of seeing AI-driven activity
Plan telemetry before production. Capture authentication and authorization decisions, tool calls, retrieval activity, configuration changes, safety events, model or agent failures, and the surrounding cloud signals needed to investigate them. Avoid logging sensitive prompt or output content indiscriminately; define what must be retained, protected, or redacted. Responders need enough context to explain an action without creating a second data-exposure problem in the logs.
Security architecture must define what telemetry the SOC will have when something goes wrong. Logs should identify the user or workload identity, the model or agent involved, data sources accessed, tools called, high-risk actions attempted, policy decisions, and relevant application events. Without that context, an investigation may show an API request without explaining the AI workflow that initiated it.
Microsoft Defender XDR and Microsoft Sentinel can correlate security signals across identity, endpoints, cloud apps, infrastructure, and other sources. The operational skills behind SC-200 matter because AI governance is incomplete if the organization cannot detect abuse, investigate incidents, and contain compromised identities or devices.
Detection engineering should focus on behavior rather than assuming every AI attack has a unique signature. Look for unusual privilege use, impossible data access patterns, new service principals, unexpected tool invocation, high-volume extraction, suspicious endpoint activity, and policy bypass. AI can change the path of an attack without changing the underlying security signals.
Measure AI security with evidence, not policy statements
Useful evidence includes identity and authorization logs, model and application telemetry, data-access records, evaluation results, safety-test outcomes, vulnerability findings, incident timelines, change approvals, and exceptions with expiration dates. Metrics should reveal exposure and control health rather than simply count policies. For example, the proportion of production agents with scoped tool permissions or the number of high-risk AI data paths without monitored access tells leaders more than the number of governance documents published.
A governance document that says “use responsible AI” is not evidence that the system is controlled. Architects need measurable artifacts: threat models, access reviews, test cases, model and prompt evaluations, safety results, data-flow diagrams, approved tool lists, incident exercises, and remediation records. Evidence should be refreshed when the system changes materially.
Define operational metrics that connect to risk. Track privileged agent identities, unresolved high-severity posture findings, unreviewed tools, stale secrets, sensitive-data exposures, failed safety tests, exceptions past their expiry date, and incidents linked to AI workloads. Avoid vanity metrics such as the number of models registered unless they tell you something about control effectiveness.
Red-team and failure testing should be part of the lifecycle. Try to make the system retrieve data it should not see, follow instructions embedded in untrusted content, call a tool with unsafe parameters, or continue when a dependency fails. The purpose is not to prove that the model can never fail. It is to learn whether the surrounding architecture limits the blast radius when it does.
Treat secure AI adoption as an architecture discipline
Architecture review should be repeatable enough that product teams know what evidence to bring: data sources, identity design, tool permissions, network exposure, model choice, evaluation results, logging, human approvals, and rollback plans. That consistency lets security teams move faster as AI adoption grows. The objective is not to slow every experiment; it is to make the transition from experiment to trusted production system deliberate and observable.
The strongest Microsoft AI security program connects Zero Trust, data security, application security, cloud posture, security operations, and governance. It does not create a separate “AI security team” that owns every decision after the application has already been built. Security requirements should shape the design from identity through deployment and operations.
That is why the modern Microsoft security path spans both implementation and architecture. Engineers can specialize in the hands-on controls of the new cloud and AI security role, while architects use SC-100-level thinking to decide how those controls fit together. The architecture is successful when the organization can adopt AI quickly without giving models, agents, or developers a privileged path around existing security principles.