Deploy Containerised Hosted Agents with Microsoft Foundry Safely

In this blog post Deploy Containerised Hosted Agents with Microsoft Foundry Safely we will explain how containerised hosted agents work, when they make business sense, and how to deploy them without turning your AI initiative into another hard-to-support IT platform.

Many leadership teams are now past the “AI demo” stage. Someone has built a useful prototype. It answers customer questions, drafts internal reports, checks policy documents, or routes service desk requests. Then the uncomfortable question arrives: where does this thing actually run, who secures it, and who supports it when it becomes business-critical?

That is the gap Microsoft Foundry Agent Service is trying to close. At a high level, it gives organisations a managed place to run AI agents — software that can reason over a request, call tools, use approved data, and perform a task. A hosted agent is where your own agent code runs on Microsoft-managed infrastructure rather than on a developer’s laptop, a random virtual machine, or a pile of custom plumbing.

The “containerised” part simply means your agent is packaged into a container image. Think of a container as a sealed, repeatable software package that includes the application and what it needs to run. This makes deployment more consistent across development, testing, and production.

Why this matters to CIOs and CTOs

The business problem is not usually whether AI can do something clever. The problem is whether it can do it safely, repeatedly, and at a cost the business understands.

We regularly see mid-sized organisations with promising AI pilots that are stuck because nobody wants to own the operational risk. The developer says it works. Security asks how access is controlled. Finance asks what the monthly bill will be. The CIO asks whether it meets internal governance and Australian compliance expectations.

Containerised hosted agents help because they give your AI applications a clearer operating model. You can package code properly, deploy a versioned agent, assign it an identity, monitor it, and connect it to approved systems in a more controlled way.

If you have already read our guide on Azure Foundry Prompt Agents Vs Hosted Agents, think of this post as the next step. Prompt agents are excellent for simpler use cases. Hosted agents are better when you need custom logic, custom integrations, or stronger control over how the agent behaves.

What Microsoft Foundry Agent Service does in plain English

Microsoft Foundry Agent Service is a managed platform for building, deploying, and running AI agents. Instead of stitching together separate services for model access, orchestration, identity, logging, scaling, and endpoints, Foundry gives teams a more standardised way to move from prototype to production.

With hosted agents, your team writes the agent code using a supported framework such as Microsoft Agent Framework, Semantic Kernel, LangGraph, or custom Python or .NET code. That code is packaged into a container image and deployed to Foundry Agent Service.

Once deployed, the platform provides an endpoint that other applications can call. The agent can then use a model from the Foundry model catalogue, call approved tools, and connect to business systems using its assigned Microsoft Entra identity. Microsoft Entra identity is the modern Microsoft sign-in and access control system formerly known as Azure Active Directory.

In business terms, this means your AI agent is no longer “a script running somewhere”. It becomes a managed application with defined access, versioning, and operational boundaries.

Where containerised hosted agents fit

Not every AI use case needs a containerised hosted agent. If your requirement is a simple internal assistant that answers questions from approved documents, a prompt agent may be enough.

Hosted agents become useful when the agent needs to do more than answer questions. For example:

• Check a CRM record before responding to a customer request.
• Create a service desk ticket and update its status.
• Run custom business rules before giving an answer.
• Handle webhooks from another system.
• Use a specific AI agent framework your development team already supports.
• Maintain files or state across a multi-step task.

This is also where our earlier post on connecting Microsoft Foundry agents to business systems becomes important. The real value of an agent usually appears when it can safely interact with the tools your staff already use every day.

A practical architecture

A typical containerised hosted agent pattern looks like this:

1. Your development team writes the agent code.
2. The code is packaged into a container image.
3. The image is stored in Azure Container Registry, which is Microsoft’s private container image store.
4. Microsoft Foundry Agent Service deploys a hosted agent version from that image.
5. The platform creates a dedicated Microsoft Entra identity for the agent.
6. Approved users or applications call the agent endpoint.
7. The agent uses approved models, tools, and business systems to complete the task.

The important point for decision-makers is separation of responsibility. Your team controls the business logic. Microsoft manages much of the hosting layer. Your security team controls identity, permissions, monitoring, and policy.

What deployment can look like

The exact commands will change depending on your language, framework, and deployment method. But the flow is generally simple enough to understand.

# 1. Build the agent container image
az acr build \
 --registry mycompanyregistry \
 --image claims-agent:v1 \
 .

# 2. Deploy or register the hosted agent version
# This is commonly handled through Azure Developer CLI, SDK, REST API,
# or deployment automation in your DevOps pipeline.

# 3. Test the agent endpoint with a controlled request
curl -X POST "https://your-agent-endpoint/responses" \
 -H "Authorization: Bearer <token>" \
 -H "Content-Type: application/json" \
 -d '{"input":"Summarise the status of claim 10492"}'

You do not need your executive team to understand every command. But they should understand the control points: the code is packaged, the deployment is repeatable, access is authenticated, and the agent is invoked through a defined endpoint.

For production, we usually recommend deployment through a proper pipeline rather than manual commands. That gives you approval gates, version history, rollback options, and evidence for audit.

The security controls that matter

AI agents can be risky because they sit between users, data, models, and business systems. A poorly designed agent can expose sensitive information, make changes it should not make, or create unexpected costs through repeated model calls.

For Australian organisations working toward Essential 8 — the Australian Government’s cybersecurity framework designed to reduce common cyber risks — hosted agents should be treated like any other production workload. They need patching, access control, logging, backup considerations, and clear administrative boundaries.

At CloudProInc, we usually focus on five practical controls:

• Least privilege access: give the agent only the permissions it needs, not broad access to every system.
• Separate environments: keep development, testing, and production agents separate.
• Approved data paths: define which systems the agent may read from or write to.
• Monitoring and alerting: track usage, errors, unusual requests, and cost spikes.
• Version control: know exactly which version of the agent is live and who approved it.

This is where tools such as Microsoft Defender, Microsoft Purview, and Wiz can help. Defender helps detect and respond to threats across Microsoft environments. Purview helps with data governance and compliance. Wiz helps security teams see cloud risk across workloads, identities, containers, and cloud services.

As a Microsoft Partner and Wiz Security Integrator, CloudProInc often looks at agent deployment through both lenses: can it deliver the business outcome, and can it be defended when something goes wrong?

A real-world scenario

Consider a 180-person professional services firm with offices in Melbourne and Sydney. The operations team wants an AI assistant that can review incoming client requests, check project status, draft a response, and create a task in the project management system.

The first prototype works well, but it runs from a developer’s machine and uses a shared service account. That might be fine for a demo, but it is not acceptable for production. Nobody can clearly answer who accessed what, which data was sent to the model, or what happens if the developer leaves.

A containerised hosted agent changes the operating model. The agent is packaged properly, deployed through a controlled process, and given its own identity. It can read project status, but not payroll data. It can draft a task, but high-risk actions still require a human to approve them.

The business outcome is not “we deployed containers”. The outcome is faster client response times, fewer manual admin steps, and lower operational risk because the agent runs in a managed and auditable way.

Cost control is not optional

AI costs can creep up quietly. Every agent interaction may involve model calls, tool calls, storage, networking, and supporting cloud services.

Before deploying a hosted agent, define the expected usage pattern. How many users will call it each day? How many steps does a typical task require? Which model does it use? What happens if an upstream system fails and the agent keeps retrying?

A practical cost model should include:

• Model usage by task type.
• Container hosting and supporting Azure services.
• Logging and monitoring retention.
• Development, testing, and production environments.
• Security review and ongoing maintenance.

This does not need to slow the project down. It simply prevents the awkward conversation where a successful pilot becomes an unexpectedly expensive production service.

When not to use hosted agents

Hosted agents are powerful, but they are not always the right first move.

You may not need them if your use case is simple, low-risk, and does not require custom code. You may also want to wait if your organisation has no clear AI governance, no data classification, and no owner for the business process the agent will support.

In those cases, start with the basics. Define the business problem, the data involved, the risk level, and the success measure. Then choose the technology.

How to start safely

For most mid-sized organisations, the best approach is a controlled pilot with production discipline.

1. Pick one workflow with measurable value.
2. Classify the data the agent will use.
3. Decide whether a prompt agent or hosted agent is the right fit.
4. Build the agent with least privilege access from the beginning.
5. Deploy through a repeatable pipeline.
6. Monitor performance, security events, and cost.
7. Review the outcome before scaling to more workflows.

If your roadmap includes agent-to-agent workflows, it is also worth reading our post on connecting Microsoft Foundry agents to external A2A endpoints. Once agents start talking to other agents or external services, governance becomes even more important.

Final thoughts

Containerised hosted agents with Microsoft Foundry Agent Service are not just a developer convenience. They are a way to make AI agents more secure, supportable, and ready for real business use.

For CIOs and CTOs, the value is practical: fewer fragile prototypes, clearer ownership, stronger access control, and a better path from AI idea to production workflow.

CloudProInc is based in Melbourne and works with organisations across Australia and internationally. With 20+ years of enterprise IT experience across Azure, Microsoft 365, Intune, Windows 365, OpenAI, Claude, Defender, and Wiz, we help businesses build AI systems that are useful, secure, and realistic to operate.

If you are not sure whether your current AI prototype is ready for production, or whether Microsoft Foundry hosted agents are the right fit, we are happy to take a look — no strings attached.