Protecting Your IP

Your agent is more than a model call. Its intellectual property (IP) is the hard-won system around the model: the orchestration logic, prompts, tools, data connections, tests, and operating judgment that make it useful. Hosting that agent as your own container gives you real protection because your logic lives in an artifact you build and control. But it is not magic confidentiality. Microsoft still operates the hosted infrastructure, third-party services may receive data, and secrets still need a vault. The practical goal is not blind trust; it is a trust boundary you can draw and defend.

Your agent’s value is the system around the model

It is tempting to treat the model as the valuable part of an artificial intelligence (AI) agent. In practice, the model is often the most replaceable component. The distinctive value usually sits in how you use it.

That value includes your orchestration logic, meaning the way the agent breaks work into steps, chooses tools, retries failures, and decides when to ask for help. It includes tuned prompts, proprietary tools, internal data connections, evaluation sets, safety rules, and the lessons your team learned by getting all of that to work together.

If those pieces leaked, a competitor might not get your source code repository exactly, but they could learn enough to copy the agent’s behavior. That is why the question is simple and important: where does the agent logic live, and who can reach it?

• Orchestration logic: the agent’s plan for doing work.
• Tuned prompts: instructions refined through testing and production use.
• Proprietary tools: internal functions, connectors, and workflows competitors do not have.
• Data access patterns: the specific systems, records, and context the agent knows how to use.
• Operational know-how: guardrails, fallbacks, and evaluations built from experience.

A container turns your logic into an artifact you own

In a hosted-agent model where you bring your own code as a container image, your agent’s logic is packaged into something you build, version, scan, approve, and store. The important shift is that your best prompts and control logic are not merely typed into a shared product interface. They are part of an artifact under your software supply-chain controls.

That does not mean everyone should put every prompt directly inside the image. Some teams load prompt templates or policy files from controlled storage at runtime. The security point is the same: the deciding logic belongs to your application boundary, not to an opaque vendor configuration screen.

A container image is not automatically secret. People and systems with permission to pull or inspect it may be able to read what is inside. Its protection depends on the registry, permissions, network exposure, build process, and runtime identity around it.

The registry is the warehouse for your packaged IP

Once the image exists, it needs a place to rest. That place is a container registry. In a secure design, the registry is private, access-controlled, logged, and reachable only by identities that have an explicit reason to push or pull images.

For Microsoft Foundry hosted agents, a private Azure Container Registry can be used so the platform pulls the image from a registry you control. In locked-down deployments, registry access can be limited through private networking so the image is not fetched over a public internet path.

This matters because protecting IP is not only about runtime execution. It is also about storage and distribution. If every developer, automation account, and environment can pull the image, the registry is not a vault; it is a loading dock. Tight permissions, image signing, vulnerability scanning, and audit logs are part of the protection story.

Isolation and identity protect the agent while it runs

Storage controls protect the image at rest. Runtime controls protect the code while it is executing. Hosted agents use per-session isolation so one customer session cannot peer into another customer session. In the Microsoft-hosted model described in the platform documentation, the session runs in a hardware-isolated sandbox under the agent’s own identity.

Isolation and identity solve different problems. Isolation limits who can observe or interfere with the running process. Identity limits what the process can do. A dedicated identity also makes actions attributable: when the agent reads a database, calls an internal service, or writes a file, that action can be tied to the agent rather than hidden behind a broad shared credential.

The design goal is least privilege. The agent should get only the permissions it needs for its job, no more. If it needs to read a customer record, it may not need permission to export a table. If it needs to call one internal application programming interface (API), it may not need access to the whole network.

Private networking keeps sensitive traffic on private roads

Code location is only one part of the boundary. Traffic path is another. If an agent must call internal databases, line-of-business systems, or private APIs, you usually do not want those exchanges crossing the open internet.

Network-isolated hosted agents can route traffic through your private network so the agent reaches private resources through controlled paths. This does not make the agent’s logic safer by itself, but it reduces exposure around the data and systems the agent touches.

Private networking is especially important in regulated environments because the route can matter as much as the destination. It helps enforce where traffic may go, which systems are reachable, and which inspection, logging, and policy controls apply along the way.

Portability is a form of IP protection

There is also a strategic side to IP protection. If your agent’s value is trapped inside one vendor’s proprietary prompt builder or model-specific configuration, your switching cost becomes part of the vendor’s leverage. You may technically own the idea, but practically struggle to move it.

A hosted container changes that balance. Your application can call the model and framework you choose, and you can revise that choice as model quality, cost, latency, safety, or contract terms change. The agent’s durable value stays in your orchestration, tools, prompts, and evaluations.

This does not mean every model swap is easy. Prompts may need retuning, tool-calling formats may differ, and evaluation results may change. But the center of gravity remains with your code and operating process, not with a single model provider’s configuration store.

The boundary still has limits

A trustworthy IP story must name what the platform does not solve. Hosted containers provide strong structural protection for your logic, but they do not eliminate dependency, data-flow, secret-management, or governance risk.

First, Microsoft operates the infrastructure in the Microsoft hosted-agent model. You are relying on the platform operator’s isolation, controls, monitoring, and contractual commitments. That can be a reasonable enterprise dependency, but it is still a dependency. Your container is not the same thing as your hardware in your building.

Second, every third-party tool, server, or model call is a deliberate opening in your boundary. Data sent to a non-Microsoft service may be handled under that service’s terms, retention policy, and security practices. If the agent can send customer data or proprietary context to an outside model, the container did not leak it; your architecture allowed it.

Third, secrets belong in a managed secret store, not in the image and not in plain environment settings. The image should be treated as inspectable by sufficiently privileged people and systems. Runtime identity should retrieve secrets or tokens from a vault only when needed.

Fourth, responsible artificial intelligence decisions remain yours. The platform can provide controls, but it cannot decide whether a given data type may leave a geographic boundary, whether a tool call is appropriate, or what human review is required for a high-impact decision.

• You trust the platform operator for infrastructure isolation and operational controls.
• You own every external data flow your agent initiates.
• You must keep credentials and keys in a vault, not in the image.
• You must define responsible artificial intelligence, compliance, and geographic data-boundary rules for your use case.

The leadership test: draw the boundary this week

A chief information security officer (CISO), platform owner, or engineering lead should be able to draw the agent’s trust boundary on a whiteboard. If the drawing is vague, the design is not ready for sensitive IP.

Start with the crown jewels: where do orchestration logic, tuned prompts, and proprietary tools live? Then trace the image from build to registry to runtime. Then trace every outbound path from the running agent to models, tools, databases, logging systems, and monitoring services.

The decision is not simply whether hosted agents are safe. The decision is whether your implementation uses the platform’s protections without opening side doors through broad permissions, public routes, hardcoded secrets, or unreviewed third-party calls.

1. Where does the agent’s logic physically live: your repository and registry, or a vendor-side configuration store?
2. Who can push, pull, inspect, or deploy the container image?
3. Which identity does the agent run as, and what exactly can that identity access?
4. Which third-party models or tools receive data, and what are their retention and training-use policies?
5. Are any secrets present in the image, settings, logs, or prompts instead of a managed secret store?
6. Can data leave a compliance, tenant, or geographic boundary, and has leadership explicitly approved that?
7. Who owns the responsible artificial intelligence controls, and where are they tested?

Glossary

Intellectual property

The proprietary agent logic, prompts, tools, data connections, and know-how that create business value and would harm you if copied.

Orchestration logic

The code and rules that decide how an agent breaks down work, chooses tools, handles errors, and sequences actions.

Container image

A packaged software artifact containing application code and dependencies that can be stored, versioned, scanned, and run consistently.

Private registry

An access-controlled storage service for container images, often limited to approved identities and private network paths.

Per-session sandbox

An isolated runtime environment created for one agent session so other sessions cannot observe or interfere with it.

Managed identity

A platform-provided identity an application uses to access approved resources without embedding long-lived credentials in code.

Private networking

A network design that routes traffic over controlled private paths rather than exposing services or traffic to the public internet.

Managed secret store

A vault service that stores keys, tokens, and passwords so applications can retrieve them securely at runtime.

Shared responsibility

The division of duties where the platform provides security controls and the customer remains responsible for architecture, permissions, data flows, and governance.