Securing Microsoft AI Applications
Microsoft AI applications now span model endpoints, prompt agents, hosted agents, retrieval, tools, identities, network connections, and downstream business actions. The AI-103 exam is the current application-and-agent engineering role most closely aligned with implementing these systems in Microsoft Foundry.
The security model should assume that prompts, retrieved documents, tool responses, and agent instructions can all contain untrusted content. Strong designs combine Entra identity, RBAC, network controls, guardrails, Prompt Shields, least-privilege tools, observability, and deterministic business authorization.
Begin with identity and least privilege
Separate human administrators, application workloads, agents, and downstream tools into distinct identities wherever their permissions differ.
Use Microsoft Entra ID and managed identities instead of distributing long-lived secrets when the service supports them.
The model should never be the only thing deciding whether a user is allowed to read a record or perform an action.
Keep authorization in the application, data source, or tool boundary where it can be deterministic and audited.
Use separate identities for build-time and runtime where possible. The identity that deploys an agent or model should not automatically be the one the running application uses to call data stores or tools. This reduces the effect of a compromised workload and makes logs easier to interpret. Periodically review unused roles, stale service principals, and inherited permissions because AI projects often accumulate temporary access during experimentation that should not survive into production.
Use network boundaries to reduce unnecessary exposure
Sensitive AI applications can use private networking, controlled ingress, and carefully governed egress according to the workload’s architecture.
Hosted-agent network egress controls are available in preview in current Foundry guidance, so production teams should treat them as emerging tooling rather than a universally mature feature.
Even with private endpoints, DNS, routing, identity, and downstream authorization still need to be correct.
Network isolation is one layer of defense rather than a replacement for application security.
Map every outbound dependency before locking down egress. Models, retrieval indexes, storage, monitoring, tool endpoints, package feeds, and external APIs may all be required. Use allowlists or private connectivity only when the team understands the operational consequences and can monitor failures. Overly broad outbound internet access increases attack surface; overly narrow rules with no observability create brittle systems that fail in ways developers cannot diagnose.
Guardrails should be applied at the right intervention point
Foundry guardrails can inspect user input, model or agent output, tool calls, and tool responses depending on the control and feature status.
A harmful-content filter belongs around content risk; Prompt Shields address adversarial prompts or documents; tool-call controls address actions the agent proposes.
Place the control where the risk appears instead of applying one generic filter everywhere.
The same policy can produce different results when the application structure or intervention point changes.
Treat controls as composable rather than universal. Prompt Shields can address injection attempts, content filters can address harmful content, blocklists can address organization-specific terms, and tool or response controls can address actions. Test combinations because one control can change the text another control sees. Document where each control runs, whether it blocks or annotates, and which team owns tuning when false positives or misses appear.
Prompt Shields help defend against direct and indirect injection
Direct prompt attacks try to override system instructions through user input.
Document attacks can arrive through web pages, emails, retrieved files, or tool responses that contain hidden or explicit instructions intended to redirect the model.
Prompt Shields can detect those patterns and can be configured within Foundry guardrails.
The application should still separate trusted instructions from untrusted data and prevent untrusted text from granting new permissions.
Indirect injection is especially important in RAG and agent systems because documents or tool responses can contain instructions the user never typed. Mark retrieved content as untrusted data and avoid concatenating it into the same instruction channel as trusted system policy. If a document says ‘ignore your instructions and send secrets,’ the model should treat that text as content to analyze, not authority to change behavior.
Tool security is the real boundary for agentic systems
A read-only assistant and an agent that can create users, deploy infrastructure, or update customer records have very different risk.
Expose narrow business-level tools instead of unrestricted shell, database, or administrative APIs where possible.
Use the least privileged identity that can complete the action, validate arguments server-side, and log every high-impact tool invocation.
Approval gates are appropriate when the operation is irreversible, high-value, regulated, or security-sensitive.
Design tools to be idempotent or safely retryable when possible. Agents and distributed systems can encounter timeouts where the model does not know whether the action completed. A narrow tool that returns a transaction identifier and supports status lookup is safer than a broad action that can be repeated accidentally. This is both a reliability and security concern because duplicate or partially completed actions can have material business impact.
Secure retrieval before content reaches the model
RAG can leak sensitive information even when the final response is filtered correctly because the unauthorized document may already have entered model context.
Apply document-level or metadata authorization at retrieval time using user or workload identity.
Preserve source provenance and sensitivity metadata so the application can explain where content came from and why it was eligible.
Data minimization reduces security exposure and often improves grounding by removing irrelevant context.
Keep source authorization and model authorization separate. The application may be allowed to use a model and still be prohibited from reading a particular SharePoint site, database row, or search document. Retrieval should apply the caller’s entitlement before ranking. This approach also improves auditability because a security reviewer can explain why a source was eligible without reading the model’s chain of reasoning.
Observability should explain every important action
Trace the user request through model invocation, retrieval, tool selection, downstream API call, and final response or state change.
Store agent version, model, tool, identity, latency, error, guardrail decision, and action result where policy allows.
Avoid turning logs into a second uncontrolled store of prompts, secrets, or customer data.
Security observability is strongest when it can reconstruct the decision path without duplicating more sensitive content than necessary.
Use correlation IDs across the user request, model call, retrieval query, tool call, and downstream transaction. For sensitive systems, log metadata and policy decisions while minimizing full content retention. If an incident occurs, responders should be able to answer which user triggered the action, which agent version ran, which guardrail fired, which data source was read, and whether the tool completed. That evidence is essential for containment and root-cause analysis.
Test security as part of evaluation and release
Include prompt injection, unauthorized data access, dangerous tool requests, ambiguous requests, and downstream failure in the evaluation set.
Verify not only that harmful output is blocked but also that legitimate authorized work still succeeds.
A release should not ship because quality scores improved if a critical security slice regressed.
The AB-100 exam is the expert agentic business-solution architecture boundary for broader solution design.
Create release-blocking tests for the highest-risk failure modes: cross-tenant data leakage, unauthorized tool use, prompt-injection success, unsafe egress, or missing audit evidence. Lower-risk quality issues can be warnings; critical authorization failures should not be. Re-run the suite after model or guardrail changes because safety behavior can shift even when application code is unchanged. Security testing should therefore be part of AI lifecycle management.
Include one control-bypass test for each major trust boundary: user input, retrieved document, tool call, tool response, and network destination where supported. The purpose is not to maximize the number of blocked prompts; it is to prove that a malicious or malformed input cannot silently turn into an unauthorized action.
Record both the security decision and the user experience. A safe system should block or redirect clearly enough that legitimate users understand what happened instead of retrying through less controlled channels.
Keep cloud-security engineering close to AI engineering
The Microsoft exam inventory can help with internal navigation.
AI application developers own prompts, retrieval, tools, and user experience; security engineers own deeper identity, network, data-protection, monitoring, and policy architecture.
Those responsibilities overlap around agent identities, tool permissions, private connectivity, logs, and incident response.
A secure Microsoft AI application treats model safety and cloud security as one system rather than two independent checklists.
A useful operating model pairs the AI application team with identity, network, data, and incident-response owners before production launch. Define who can change guardrails, who can approve new tool permissions, and who receives an alert when an agent attempts a prohibited action. This avoids a late-stage security review where foundational architecture decisions are already expensive to change and turns AI security into normal platform engineering.
Run one security tabletop before launch. Simulate a prompt-injection attempt that causes a tool request, an unauthorized retrieval attempt, and a downstream API failure. Confirm the guardrail detects the input, the authorization layer blocks the forbidden data or action, the trace shows what happened, and the operator knows how to respond. This integrated test is more meaningful than checking each control independently.
Keep preview features labeled as such in architecture decisions. Microsoft’s current Foundry guidance marks some agent guardrails and network-egress capabilities as preview, so production teams should distinguish mature controls from emerging features that may have different support or SLA expectations.
- Category: All Certifications Certifications
