Microsoft Foundry Agent Service: Building Secure, Scalable Enterprise AI Agents

Microsoft Foundry Agent Service is a managed runtime for building and operating agents. It can host prompt-based agents and custom agent code, and provides a common entry point to supported models and tools. The service supplies runtime capabilities; the application team remains responsible for workflow design, authorization, evaluation, and operational controls. Microsoft Foundry documentation

What is an AI agent?

An agent uses a model to interpret a task and select from available actions, such as calling a search service or an application API. For example, a support agent might classify a request, retrieve approved knowledge, check account status through a read-only API, draft an answer with source links, and send uncertain or high-impact cases to a person.

The model does not grant itself access. The application, agent identity, tool, and downstream service each need explicit authorization. Treat generated tool arguments as untrusted input and validate them before execution.

Agent architecture

A production agent commonly includes:

• Model: Interprets input and generates responses or tool-call proposals.
• Instructions: Define the agent's role, constraints, escalation behavior, and permitted tasks.
• Tools: Narrow APIs or functions that expose specific operations.
• Knowledge: Search or retrieval services that provide relevant source material.
• Conversation state: Thread or application state needed to complete the current task. Persistent memory is optional and should have a defined purpose and retention policy.
• Orchestration: Application or runtime logic that controls tool calls, retries, handoffs, and termination.

Foundry supports prompt agents and hosted agents, with different build and runtime choices. Select the model, agent type, and tool approach based on the workflow and deployment requirements rather than assuming one configuration fits every use case. Microsoft Foundry Agent Service overview

Secure enterprise integration

Start with identity and data boundaries. Foundry agent identities are Microsoft Entra identities used by agents to authenticate to supported downstream resources. Assign only the roles and scopes required by the workflow, and verify permissions using the identity that runs the deployed agent. User authentication and agent authentication are separate concerns; where a task must use the caller's permissions, configure an appropriate delegated access pattern rather than relying on the agent's broader service identity. Agent identity concepts

Networking is a separate control. Foundry has public and private networking configurations with different inbound and outbound behavior. A private endpoint for one resource does not make the whole workflow private. Review connectivity for the agent, model, search index, tools, storage, and telemetry together, and validate the deployed network path. Networking options for Foundry Agent Service

Other controls belong in the surrounding application and services:

• Enforce authorization again at each tool and data source.
• Keep secrets in managed identity or a secret-management service, not prompts.
• Treat retrieved documents and user input as untrusted content.
• Require approval for high-impact or irreversible actions.
• Limit tool scope, retries, execution time, and spend.
• Log only the information needed for operations, with access and retention controls.

From prototype to production

1. Define a workflow, its users, allowed actions, exceptions, and measurable outcomes.
2. Select a supported agent type and model for the required runtime and deployment.
3. Implement narrow tools with server-side authorization and input validation.
4. Connect knowledge through retrieval with permissions enforced before model context is assembled.
5. Build evaluations for routine cases, denied access, ambiguous requests, prompt injection, and tool failures.
6. Add tracing and alerts, review sensitive trace data, and define an incident and rollback process.
7. Release to a limited audience, inspect failures, and expand only when quality and controls meet agreed thresholds.

Foundry evaluation can use datasets, generated outputs, and production traces to measure quality and safety during development and operation. Tracing can capture prompts, inputs and outputs, tool calls, and execution metadata, so review what is collected and who can access it before enabling production traces. Evaluation in Microsoft Foundry, Tracing and data handling

Conclusion

Foundry provides a managed agent runtime, not a complete security or reliability design. Production readiness depends on clear workflow boundaries, scoped identities, authorized tools, permission-aware retrieval, evaluation, and operations that account for sensitive trace data.

References

1. Microsoft Learn. Agents in Microsoft Foundry
2. Microsoft Learn. Agent identity concepts in Microsoft Foundry
3. Microsoft Learn. Networking options for Foundry Agent Service
4. Microsoft Learn. Evaluation in Microsoft Foundry
5. Microsoft Learn. Tracing and data handling in Microsoft Foundry