Production ready architectures for AI apps and agents on Marketplace
Why “production‑ready” architecture matters for Marketplace AI apps and agents A working AI prototype is not the same as a production‑ready AI app in Microsoft Marketplace. Marketplace solutions are expected to operate reliably in real customer environments, alongside mission‑critical workloads and under enterprise constraints. As a result, AI apps published through Marketplace must meet a higher bar than “it works in a demo.” You can always get a curated step-by-step guidance through building, publishing and selling apps for Marketplace through App Advisor. Production‑ready Marketplace AI apps must assume: Alignment with enterprise expectations and Azure well‑architected AI principles, including cost optimization, security, reliability, operational excellence, and performance efficiency Architectural decisions made early are difficult to reverse, especially once customers, tenants, and billing relationships are in place A higher trust bar from customers, who expect Marketplace solutions to be Microsoft‑vetted, certified, and safe to run in production Customers come to Marketplace expecting solutions that are ready to run, ready to scale, and ready to be supported—not experiments. This post focuses on the architectural principles and patterns required to meet those expectations. Specific services and implementation details are covered later in the series. This post is part of a series on building and publishing well-architected AI apps and agents in Microsoft Marketplace. The series focuses on AI apps and agents that are architected, hosted, and operated on Azure, with guidance aligned to building and selling solutions through Microsoft Marketplace. Aligning offer type and architecture early sets you up for success A strong indicator of a smooth Marketplace journey is early alignment between offer type and solution architecture. Offer type defines more than how an AI app is listed—it establishes clear roles and responsibilities between publishers and customers, which in turn shape architectural boundaries. Across all other offer types, architecture must clearly answer three questions: Who owns the runtime? Where does the AI execute? Who controls updates and ongoing operations? These decisions will vary depending on whether the solution resides in the customer’s or publisher’s tenant based on the attributes associated with the following transactable marketplace offer types: SaaS offers, where the AI runtime lives in the publisher’s environment and architecture must support multitenant AI app design, strong isolation, and centralized operations Container offers, where workloads run in the customer’s Kubernetes environment and architecture emphasizes portability and clear operational assumptions Virtual Machine offers, where preconfigured environments run in the customer’s subscription and architecture is more tightly coupled to the OS and infrastructure footprint Azure Managed Applications, where the solution is deployed into the customer's subscription and architecture must balance customer control with defined lifecycle boundaries. What makes this model distinctive is its flexibility: an Azure Managed Application can package containers, virtual machines, or a combination of both — making it a natural fit for solutions that require customer-controlled infrastructure without sacrificing publisher-managed operations. The packaging choice shapes the underlying architecture, but the managed application wrapper is what defines how the solution is deployed, updated, and governed within the customer's environment. Architecture decisions naturally reinforce Marketplace requirements and reduce certification and operational friction later. Key factors that benefit from early alignment include: Roles and responsibilities, such as who operates the AI runtime and who is responsible for uptime, patching, scaling, and ongoing operations Proximity to data, particularly for AI solutions that rely on customer‑specific or proprietary data, where placement affects performance, data movement, and compliance Core architectural building blocks of AI apps Designing a production‑ready AI app starts with treating the solution as a system, not a single service. AI apps—especially agent‑based solutions—are composed of multiple cooperating layers that together enable reasoning, action, and safe operation at scale. At a high level, most production‑ready AI apps include the following building blocks: Interaction layer, which serves as the entry point for users or systems and is responsible for authentication, request shaping, and consistent responses Orchestration layer, which coordinates reasoning, tool selection, workflow execution, and retrieval‑augmented generation (RAG) flows across multi‑step interactions Model endpoints, which provide inference and generation capabilities and introduce distinct latency, cost, and dependency characteristics Data sources, including vector stores, operational data, documents, and logs that the AI system reasons over Control planes, such as identity, configuration, policy enforcement, feature flags, and secrets management, which govern behavior without redeploying core logic Observability, which enables tracing, monitoring, and diagnosis of agent decisions, actions, and outcomes Networking, which connects components using a zero‑trust posture where every call is authenticated and outbound access is explicitly controlled Together, these components form the foundation of most Marketplace‑ready AI architectures. How they are composed—and where boundaries are drawn—varies by offer type, tenancy model, and customer requirements. Specific services, patterns, and implementation guidance for each layer are explored later in the series. Tenancy design choices as an early architectural decision One of the earliest and most consequential architectural decisions is where the AI solution is hosted. Does it run in the publisher’s tenant, or is it deployed into the customer’s tenant? This choice establishes foundational boundaries and is difficult to change later without significant redesign. If the solution runs in the publisher’s tenant, it is inherently multi‑tenant and must be designed with strong logical isolation across customers. If it runs in the customer’s tenant, deployments are typically single‑tenant by default, with isolation provided through infrastructure boundaries. Many Marketplace AI apps fall between these extremes, making it essential to define the AI tenancy model early. Common tenancy approaches include: Publisher‑hosted, multi‑tenant solutions, where a shared AI runtime serves multiple customers and requires strict isolation of customer data, inference requests, identity, and cost attribution Customer‑hosted, single‑tenant deployments, where each customer operates an isolated instance within their own Azure subscription, often preferred for regulated or tightly controlled environments Hybrid models, which combine centralized AI services with customer‑hosted data or execution layers and require carefully defined trust and access boundaries Tenancy decisions influence several core architectural dimensions, including: Identity and access boundaries, which define how users and agents authenticate and act across tenants Data isolation, including how customer data is stored, processed, and protected Model usage patterns, such as shared models versus tenant‑specific models Cost allocation and scale, including how usage is tracked and attributed per customer These considerations are not implementation details—they shape how the AI system behaves, scales, and is governed in production. Reference architecture guidance for multi‑tenant AI and machine learning solutions in the Azure Architecture Center explores these tradeoffs in more detail. Understanding your customer’s needs Designing a production‑ready AI architecture starts with understanding the environment your customers expect your solution to operate in. Marketplace customers vary widely in their security posture, compliance obligations, operational practices, and tolerance for change. Architectures that reflect those realities reduce friction during onboarding, certification, and long‑term operation. Key customer considerations that shape architecture include: Security and compliance expectations, such as industry regulations, internal governance policies, or regional data requirements Target environments, including whether customers expect solutions to run in their own Azure subscription or are comfortable consuming centrally hosted services Change and outage windows, where operational constraints or seasonal restrictions require predictable and controlled updates Architectural alignment with customer needs is not about designing for every edge case. It is about making intentional tradeoffs that reflect how customers will deploy, operate, and depend on your AI solution in production. Specific security controls, compliance enforcement mechanisms, and operational policies are explored later in the series. This section establishes the architectural mindset required to support them. Separating environments for safe iteration Production AI systems must evolve continuously while remaining stable for customers. Separating environments is how publishers enable safe iteration without destabilizing live usage—and how customers maintain confidence when adopting and operating AI solutions in their own environments. From the publisher’s perspective, environment separation enables: Iteration on prompts, models, and orchestration logic without impacting production customers Validation of behavior changes before rollout, especially for AI‑driven systems where small changes can produce materially different outcomes Controlled release strategies that reduce operational risk From the customer’s perspective, environment separation shapes how the solution fits into their own development and operational practices: Where the solution is deployed across development, staging, and production environments How deployments are repeated or promoted, particularly when the solution runs in the customer’s tenant Whether environments can be recreated predictably, or whether customers are forced to manually reconfigure deployments with each iteration When AI solutions are deployed into the customer’s tenant, environment design becomes especially important. Customers should not be required to reverse‑engineer deployment logic, recreate environments from scratch, or re‑establish trust boundaries every time the solution evolves. These concerns should be addressed architecturally, not deferred to operational workarounds. Environment separation is therefore not just a DevOps choice—it is an architectural decision. It influences identity boundaries, deployment topology, validation strategies, and the shared operational contract between publisher and customer. Designing for AI‑specific scalability patterns AI workloads do not scale like traditional web or CRUD‑based applications. While front‑end and API layers may follow familiar scaling patterns, AI systems introduce behaviors that require different architectural assumptions. Production‑ready AI architectures must account for: Bursty inference demand, where usage can spike unpredictably based on user behavior or downstream automation Long‑running or multi‑step agent workflows, which may span tools, data sources, and time Model‑driven latency and cost characteristics, which influence throughput and responsiveness independently of application logic As a result, scalability decisions often vary by layer. Horizontal scaling is typically most effective in interaction, orchestration, and retrieval components, while model endpoints may require separate capacity planning, isolation, or throttling strategies. Treating identity as an architectural boundary Identity is foundational to Marketplace AI apps, but architecture must plan for it explicitly. Identity decisions define trust boundaries across users, agents, and services, and shape how the solution scales, secures access, and meets compliance requirements. Key architectural considerations include: Microsoft Entra ID as a foundation, where identity is treated as a core control plane rather than a late‑stage integration How users sign in, including: Their own corporate Microsoft Entra ID tenant B2B scenarios where one Entra ID tenant trusts another B2C identity providers for customer‑facing experiences How tenants authenticate, particularly in multi‑tenant or cross‑organization scenarios How AI agents act on behalf of users, including delegated access, authorization scope, and auditability How services communicate securely, using a zero‑trust posture where every call is authenticated and authorized Treating identity as an architectural boundary helps ensure that trust relationships remain explicit, enforceable, and consistent across tenants and environments. This foundation is critical for supporting secure operation, compliance enforcement, and future tenant‑linking scenarios. Designing for observability and auditability Production‑ready AI apps must be observable and auditable by design. Marketplace customers expect visibility into how systems behave in production, and publishers need clear insight to diagnose issues, operate reliably, and meet enterprise trust and compliance expectations. Key architectural considerations include: End‑to‑end observability, covering user interactions, agent reasoning steps, tool invocations, and downstream service calls Clear audit trails, capturing who initiated an action, what the AI system did, and how decisions were executed—especially when agents act on behalf of users Tenant‑aware visibility, ensuring logs, metrics, and traces are correctly attributed without exposing data across tenants Operational transparency, enabling effective troubleshooting, incident response, and continuous improvement without ad‑hoc instrumentation AI app observability design goes beyond infrastructure health. It must also account for AI‑specific behavior, such as prompt execution, model selection, retrieval outcomes, and tool usage. Without this visibility, diagnosing failures, validating changes, or explaining outcomes becomes difficult in real customer environments. Auditability is equally critical. Identity, access, and action histories must be traceable to support security reviews, regulatory obligations, and customer trust—particularly in regulated or enterprise settings. Common architectural pitfalls in Marketplace AI apps Even experienced teams run into similar challenges when moving from an AI prototype to a production‑ready Marketplace solution. The following pitfalls often surface when architectural decisions are deferred or made implicitly. Common pitfalls include: Treating AI as a single service instead of a system, where model inference is implemented without considering orchestration, data access, identity, observability, and operational boundaries Hard‑coding tenant assumptions, such as assuming a single tenant, identity model, or deployment topology, which becomes difficult to unwind as customer requirements diversify Not planning for a resilient model strategy, leaving the architecture fragile when model versions change, capabilities evolve, or providers introduce breaking behavior Assuming data lives within the same boundary as the solution, when in practice it may reside in a different tenant, subscription, or control plane Tightly coupling prompt logic to application code, making it harder to iterate on AI behavior, validate changes, or manage risk without full redeployments Assuming issues can be fixed after go‑live, which underestimates the cost and complexity of changing architecture once customers, subscriptions, and trust relationships are in place While these pitfalls may be caused by a lack of technical skill on the customer’s side, they could typically emerge when architectural decisions are postponed in favor of speed, or when AI behavior is treated as an isolated concern rather than part of a production system. What’s next in the journey The architectural decisions made early—around offer type, tenancy, identity, environments, and observability—establish the foundation on which everything else is built. When these choices are intentional, they reduce friction as the solution evolves, scales, and adapts to real customer needs. The next set of posts builds on this foundation, exploring different dimensions of operating, securing, and evolving Marketplace AI apps in production. See the next post in the series: Securing AI apps and agents on Microsoft Marketplace | Microsoft Community Hub. Key resources See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor Quick-Start Development Toolkit can connect you with code templates for AI solution patterns Microsoft AI Envisioning Day Events How to build and publish AI apps and agents for Microsoft Marketplace Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV SuccessSecuring AI apps and agents on Microsoft Marketplace
Why security must be designed in—not validated later AI apps and agents expand the security surface beyond that of traditional applications. Prompt inputs, agent reasoning, tool execution, and downstream integrations introduce opportunities for misuse or unintended behavior when security assumptions are implicit. These risks surface quickly in production environments where AI systems interact with real users and data. Deferring security decisions until late in the lifecycle often exposes architectural limitations that restrict where controls can be enforced. Retrofitting security after deployment is costly and can force tradeoffs that affect reliability, performance, or customer trust. Designing security early establishes clear boundaries, enables consistent enforcement, and reduces friction during Marketplace review, onboarding, and long‑term operation. In the Marketplace context, security is a foundational requirement for trust and scale. You can always get a curated step-by-step guidance through building, publishing and selling apps for Marketplace through App Advisor. This post is part of a series on building and publishing well-architected AI apps and agents in Microsoft Marketplace. The series focuses on AI apps and agents that are architected, hosted, and operated on Azure, with guidance aligned to building and selling solutions through Microsoft Marketplace. How AI apps and agents expand the attack surface Without a clear view of where trust boundaries exist and how behavior propagates across systems, security controls risk being applied too narrowly or too late. AI apps and agents introduce security risks that extend beyond those of traditional applications. AI systems accept open‑ended prompts, reason dynamically, and often act autonomously across systems and data sources. These interaction patterns expand the attack surface in several important ways: New trust boundaries introduced by prompts and inputs, where unstructured user input can influence reasoning and downstream actions Autonomous behavior, which increases the blast radius when authentication or authorization gaps exist Tool and integration execution, where agents interact with external APIs, plugins, and services across security domains Dynamic model responses, which can unintentionally expose sensitive data or amplify errors if guardrails are incomplete Each API, plugin, or external dependency becomes a security choke point where identity validation, audit logging, and data handling must be enforced consistently as part of securing AI integrations—especially when AI systems span tenants, subscriptions, or ownership boundaries. Using OWASP GenAI Top 10 as a threat lens The OWASP GenAI Top 10 provides a practical, industry‑recognized lens for identifying and categorizing AI‑specific security threats that extend beyond traditional application risks. Rather than serving as a checklist, the OWASP GenAI Top 10 helps teams ask the right questions early in the design process. It highlights where assumptions about trust, input handling, autonomy, and data access can break down in AI‑driven systems—often in ways that are difficult to detect after deployment. Common risk categories highlighted by OWASP include: Prompt injection and manipulation, where malicious input influences agent behavior or downstream actions Sensitive data exposure, including leakage through prompts, responses, logs, or tool outputs Excessive agency, where agents are granted broader permissions or action scope than intended Insecure integrations, where tools, plugins, or external systems become unintended attack paths Highly regulated industries, sensitive data domains, or mission‑critical workloads may require additional risk assessment and security considerations that extend beyond the OWASP categories. The OWASP GenAI Top 10 allows teams to connect high‑level risks to architectural decisions by creating a shared vocabulary that sets the foundation for designing guardrails that are enforceable both at design time and at runtime. Designing security guardrails into the architecture Security guardrails must be designed into the architecture, shaping where and how policies are enforced, evaluated, and monitored throughout the solution lifecycle. Guardrails operate at two complementary layers: Design time, where architectural decisions determine what is possible, permitted, or blocked by default Runtime, where controls actively govern behavior as the AI app or agent interacts with users, data, and systems When architectural boundaries are not defined early, teams often discover that critical controls—such as input validation, authorization checks, or action constraints—cannot be applied consistently without redesign: Tenancy boundaries, defining how isolation is enforced between customers, environments, or subscriptions Identity boundaries, governing how users, agents, and services authenticate and what actions they can perform Environment separation, limiting the blast radius of experimentation, updates, or failures Control planes, where configuration, policy, and behavior can be adjusted without redeploying core logic Data planes, controlling how data is accessed, processed, and moved across trust boundaries Designing security guardrails into the architecture transforms security from reactive to preventative, while also reducing friction later in the Marketplace journey. Clear enforcement boundaries simplify review, clarify risk ownership, and enable AI apps and agents to evolve safely as capabilities and integrations expand. Identity as a security boundary for AI apps and agents Identity defines who can access the system, what actions can be taken, and which resources an AI app or agent is permitted to interact with across tenants, subscriptions, and environments. Agents often act on behalf of users, invoke tools, and access downstream systems autonomously. Without clear identity boundaries, these actions can unintentionally bypass least‑privilege controls or expand access beyond what users or customers expect. Strong identity design shapes security in several key ways: Authentication and authorization, determines how users, agents, and services establish trust and what operations they are allowed to perform Delegated access, constraints agents to act with permissions tied to user intent and context Service‑to‑service trust, ensures that all interactions between components are explicitly authenticated and authorized Auditability, traces actions taken by agents back to identities, roles, and decisions A zero‑trust AI agent architecture is essential in this context. is essential in this context. Every request—whether initiated by a user, an agent, or a backend service—should be treated as untrusted until proven otherwise. Identity becomes the primary control plane for enforcing least privilege, limiting blast radius, and reducing downstream integration risk. This foundation not only improves security posture, but also supports compliance, simplifies Marketplace review, and enables AI apps and agents to scale safely as integrations and capabilities evolve. Protecting data across boundaries Data may reside in customer‑owned tenants, subscriptions, or external systems, while the AI app or agent runs in a publisher‑managed environment or a separate customer environment. Protecting data across boundaries requires teams to reason about more than storage location. Several factors shape the security posture: Data ownership, including whether data is owned and controlled by the customer, the publisher, or a third party Boundary crossings, such as cross‑tenant, cross‑subscription, or cross‑environment access patterns Data sensitivity, particularly for regulated, proprietary, or personally identifiable information Access duration and scope, ensuring data access is limited to the minimum required context and time When these factors are implicit, AI systems can unintentionally broaden access through prompts, retrieval‑augmented generation, or agent‑initiated actions. This risk increases when agents autonomously select data sources or chain actions across multiple systems. To mitigate these risks, access patterns must be explicit, auditable, and revocable. Data access should be treated as a continuous security decision, evaluated on every interaction rather than trusted by default once a connection exists. This approach aligns with zero-trust principles, where no data access is implicitly trusted and every request is validated based on identity, context, and intent. Runtime protections and monitoring For AI apps and agents, security does not end at deployment. In customer environments, these systems interact continuously with users, data, and external services, making runtime visibility and control essential to a strong security posture. AI behavior is also dynamic: the same prompt, context, or integration can produce different outcomes over time as models, data sources, and agent logic evolve, so monitoring must extend beyond infrastructure health to include behavioral signals that indicate misuse, drift, or unintended actions. Effective runtime protections focus on five core capabilities: Vulnerability management, including regular scanning of the full solution to identify missing patches, insecure interfaces, and exposure points Observability, so agent decisions, actions, and outcomes can be traced and understood in production Behavioral monitoring, to detect abnormal patterns such as unexpected tool usage, unusual access paths, or excessive action frequency Containment and response, enabling rapid intervention when risky or unauthorized behavior is detected Forensics readiness, ensuring system-state replicability and chain-of-custody are retained to investigate what happened, why it happened, and what was impacted Monitoring that only tracks availability or performance is insufficient. Runtime signals must provide enough context to explain not just what happened, but why an AI app or agent behaved the way it did, and which identities, data sources, or integrations were involved. Equally important is integration with broader security event and incident management workflows. Runtime insights should flow into existing security operations so AI-related incidents can be triaged, investigated, and resolved alongside other enterprise security events—otherwise AI solutions risk becoming blind spots in a customer’s operating environment. Preparing for incidents and abuse scenarios No AI app or agent operates in a perfectly controlled environment. Once deployed, these systems are exposed to real users, unpredictable inputs, evolving data, and changing integrations. Preparing for incidents and abuse scenarios—including AI agent incident response—is therefore a core security requirement, not a contingency plan. AI apps and agents introduce unique incident patterns compared to traditional software. In addition to infrastructure failures, teams must be prepared for prompt abuse, unintended agent actions, data exposure, and misuse of delegated access. Because agents may act autonomously or continuously, incidents can propagate quickly if safeguards and response paths are unclear. Effective incident readiness starts with acknowledging that: Abuse is not always malicious, misuse can stem from ambiguous prompts, unexpected context, or misunderstood capabilities Agent autonomy may increase impact, especially when actions span multiple systems or data sources Security incidents may be behavioral, not just technical, requiring interpretation of intent and outcomes Preparing for these scenarios requires clearly defined response strategies that account for how AI systems behave in production. AI solutions should be designed to support pause, constrain, or revoke agent capabilities when risk is detected, and to do so without destabilizing the broader system or customer environment. Incident response must also align with customer expectations and regulatory obligations. Customers need confidence that AI‑related issues will be handled transparently, proportionately, and in accordance with applicable security and privacy standards. Clear boundaries around responsibility, communication, and remediation help preserve trust when issues arise. How security decisions shape Marketplace readiness From initial review to customer adoption and long‑term operation, security posture is a visible and consequential signal of readiness. AI apps and agents with clear boundaries—around identity, data access, autonomy, and runtime behavior—are easier to evaluate, onboard, and trust. When security assumptions are explicit, Marketplace review becomes more predictable, customer expectations are clearer, and operational risk is reduced. Ambiguous trust boundaries, implicit data access, or uncontrolled agent actions can introduce friction during review, delay onboarding, or undermine customer confidence after deployment. Marketplace‑ready security is therefore not about meeting a minimum bar. It is about enabling scale. Well-designed security allows AI apps and agents to integrate into enterprise environments, align with customer governance models, and evolve safely as capabilities expand. When security is treated as a first‑class architectural concern, it becomes an enabler rather than a blocker—supporting faster time to market, stronger customer trust, and sustainable growth through Microsoft Marketplace. What’s next in the journey Security for AI apps and agents is not a one‑time decision, but an ongoing design discipline that evolves as systems, data, and customer expectations change. By establishing clear boundaries, embedding guardrails into the architecture, and preparing for real‑world operation, publishers create a foundation that supports safe iteration, predictable behavior, and long‑term trust. This mindset enables AI apps and agents to scale confidently within enterprise environments while meeting the expectations of customers adopting solutions through Microsoft Marketplace. See the next post in the series: Designing AI guardrails for apps and agents in Marketplace | Microsoft Community Hub. Key resources See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor, Quick-Start Development Toolkit Microsoft AI Envisioning Day Events How to build and publish AI apps and agents for Microsoft Marketplace Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV SuccessAccelerate your AI or agent build to sell on Marketplace with Quick-Start Development Toolkit
Want to skip right to coding in minutes? Start with the interactive wizard in App Advisor Building AI products quickly is becoming table stakes. Building them in a way that supports scalability, repeatability, and a path to commercialization is where software companies create advantage. The challenge now is reducing the time between identifying an opportunity and getting developers working inside a proven structure that supports real deployment outcomes. That’s where the AI, agentic, and Copilot branch of the Quick-Start Development Toolkit helps. Embedded directly within App Advisor, Quick-Start Development Toolkit helps software companies move from concept to implementation faster using guided development patterns, trusted architectures, deployable reference code, and practical resources designed to reduce friction across the development process. Build AI & agentic products faster without starting from scratch Development teams often know the customer scenario they want to solve. What slows momentum is deciding where to begin, selecting architecture patterns, and aligning implementation decisions across teams. The Quick-Start Development Toolkit helps remove that uncertainty. By answering a few focused questions about what you want to build, who it serves, and the products you’re building with, you’re matched with a development pattern designed to accelerate execution. Each development pattern includes: Self-serve, click-to-deploy reference code aligned to your scenario, Sample solution architecture to help visualize products and reduce guesswork, and Practical how-to resources and implementation guidance to overcome friction points, Everything is structured to support faster decision making and help teams move confidently into development. Accelerate development with purpose-built AI accelerators The AI and agent branch of Quick-Start Development Toolkit includes development accelerators designed around high-value scenarios, so your team can spend less time assembling foundations and more time building differentiated experiences. Each of these accelerators is built and fully maintained by Microsoft experts, so you can be confident your code template isn’t stale. Our most popular accelerators include: Multi-Agent Custom Automation Engine Accelerator: Delegate complex, repetitive tasks to AI agents that act on your behalf—executing work efficiently, reducing manual effort, and ensuring results align with your organization's standards. Conversation Knowledge Mining Accelerator: Improve contact center performance with AI-powered conversation intelligence—analyzing audio and text data on a large scale to show insights, improve service, and drive smarter decisions. Accelerate agentic applications for Unified Data Foundations (with Microsoft Fabric): Accelerate decision making at scale with secure, agentic AI built on a unified data foundation with two use cases for sales performance and customer insights. Each pattern includes common use cases, related resources, and pathways to adjacent scenarios so teams can continue progressing without losing momentum. The goal is to help your team move from experimentation to a product that can be packaged, deployed, and prepared for customers. You can see more of our accelerators here Coming this week: The Microsoft IQ solution accelerator leverages a shared intelligence layer to unify data, knowledge, and workflows, enabling AI-powered insights and coordinated actions for measurable business outcomes. Build with Microsoft Marketplace outcomes in mind Development choices shape commercial outcomes. Starting with trusted architecture and structured implementation guidance can help reduce redesign cycles later when preparing to package, publish, and scale. Quick-Start Development Toolkit helps software companies: Shorten time from idea to deployable AI product, Improve alignment across implementation decisions, Reduce development overhead through reusable foundations, and Create repeatable pathways toward publishing and selling. When development starts with clarity, commercialization becomes easier. Keep moving forward with App Advisor Quick-Start Development Toolkit is embedded within App Advisor because building is only one stage of the journey. App Advisor helps connect decisions across design, development, publishing, and growth so teams can continue moving forward with less context switching and more confidence. As your solution evolves, App Advisor provides curated, step-by-step guidance to help you prepare for Marketplace readiness and make the next decision faster. Ready to start? Explore Quick-Start Development Toolkit Start where you need help with App AdvisorGoverning AI apps and agents for Marketplace
Governing AI apps and agents Governance is what turns powerful AI functionality into a solution that enterprises can confidently adopt, operate, and scale. It establishes clear responsibility for actions taken by the system, defines explicit boundaries for acceptable behavior, and creates mechanisms to review, explain, and correct outcomes over time. Without this structure, AI systems can become difficult to manage as they grow more connected and autonomous. For publishers, governance is how trust is earned — and sustained — in enterprise environments. It signals that AI behavior is intentional, accountable, and aligned with customer expectations, not left to inference or assumption. As AI apps and agents operate across users, data, and systems, risk shifts away from what a model can generate and toward how its behavior is governed in real‑world conditions. Marketplace readiness reflects this shift. It is defined less by raw capability and more by control, accountability, and trust. You can always get a curated step-by-step guidance through building, publishing and selling apps for Marketplace through App Advisor. This post is part of a series on building and publishing well-architected AI apps and agents in Microsoft Marketplace. The series focuses on AI apps and agents that are architected, hosted, and operated on Azure, with guidance aligned to building and selling solutions through Microsoft Marketplace. What governance means for AI apps and agents Governance in AI systems is operational and continuous. It is not limited to documentation, checklists, or periodic reviews — it shapes how an AI app or agent behaves while it is running in real customer environments. For AI apps and agents, governance spans three closely connected dimensions: Policy What the system is allowed to do, what data it is allowed to access, what is restricted, and what is explicitly prohibited. Enforcement How those policies are applied consistently in production, even as context, inputs, and conditions change. Evidence How decisions and actions are traced, reviewed, and audited over time. Governance works when intent, behavior, and proof move together — turning expectations into outcomes that can be trusted and examined. These dimensions are interdependent. Policy without enforcement is aspiration. Enforcement without evidence is unverifiable. Governance in action Governance becomes real when responsibility is explicit. For AI apps and agents, this starts with clarity around who is responsible for what: Who the agent acts for — and how its use protects business value Ensuring the agent is used for its intended purpose, produces measurable value, and is not misused, over‑extended, or operating outside approved business contexts. Who owns data access and data quality decisions Governing how the agent consumes and produces data, whether access is appropriate, and whether the data used or generated is reliable, accurate, and aligned with business and integrity expectations. Who is accountable for outcomes when behavior deviates Defining responsibility when the agent’s behavior creates risk, degrades value, or produces unexpected outcomes — so corrective action is timely, intentional, and owned. When governance is left vague or undefined, accountability gaps surface and agent actions become difficult to justify and explain across the publisher, the customer, and the solution itself. In this model, responsibility is shared but distinct. The publisher is responsible for designing and implementing the governance capabilities within the solution — defining boundaries, enforcement points, and evidence mechanisms that protect business value by default. Marketplace customers expect to understand who is accountable before they adopt an AI solution, not after an incident forces the question. The customer is responsible for configuring, operating, and applying those capabilities within their own environment, aligning them to internal policies, risk tolerance, and day‑to‑day use. Governance works when both roles are clear: the publisher provides the structure, and the customer brings it to life in practice. Data governance for AI: beyond storage and access For Marketplace‑ready AI apps and agents, data governance must account for where data moves, not just where it resides. Understanding how data flows across systems, tools, and tenants is essential to maintaining trust as solutions scale. Data governance for AI apps and agents extends beyond where data is stored. These systems introduce new artifacts that influence behavior and outcomes, including prompts and responses, retrieval context and embeddings, and agent‑initiated actions and tool outputs. Each of these elements can carry sensitive information and shape downstream decisions. Effective data governance for AI apps and agents requires clear structure: Explicit data ownership — defining who owns the data and under what conditions it can be accessed or used Access boundaries and context‑aware authorization — ensuring access decisions reflect identity, intent, and environment, not just static permissions Retention, auditability, and deletion strategies — so data use remains traceable and aligned with customer expectations over time Relying on prompts or inferred intent to determine access is a governance gap, not a shortcut. Without explicit controls, data exposure becomes difficult to predict or explain. Runtime policy enforcement in production Policies are stress tested when the agent is responding to real prompts, touching real data, and taking actions that carry real consequences. For software companies building AI apps and agents for Microsoft Marketplace, runtime enforcement is also how you keep the system fit for purpose: aligned to its intended use, supported by evidence, and constrained when conditions change. At runtime, governance becomes enforceable through three clear lanes of behavior: Decisions that require human approval Use approval gates for higher‑impact steps (for example: executing a write operation, sending an external request, or performing an irreversible workflow). This protects the business value of the agent by preventing “helpful” behavior from turning into misuse. Actions that can proceed automatically — within defined limits Automation is earned through clarity: define the agent’s intended uses and keep tool access, data access, and action scope anchored to those uses. Fit‑for‑purpose isn’t a feeling — it’s something you support with defined performance metrics, known error types, and release criteria that you measure and re‑measure as the system runs. Behaviors that are never permitted — regardless of context or intent Block classes of behavior that violate policy (including jailbreak attempts that try to override instructions, expand tool scope, or access disallowed data). When an intended use is not supported by evidence — or new evidence shows it no longer holds — treat that as a governance trigger: remove or revise the intended use in customer‑facing materials, notify customers as appropriate, and close the gap or discontinue the capability. To keep runtime enforcement meaningful over time, pair it with ongoing evaluation: document how you’ll measure performance and error patterns, run those evaluations pre‑release and continuously, and decide how often re‑evaluation is needed as models, prompts, tools, and data shift. This is what keeps autonomy intentional. It allows AI apps and agents to operate usefully and confidently, while ensuring behavior remains aligned with defined expectations — and backed by evidence — as systems evolve and scale. Auditability, explainability, and evidence Guardrails are the points in the system where governance becomes observable: where decisions are evaluated, actions are constrained, and outcomes are recorded. As described in Designing AI guardrails for apps and agents in Marketplace, guardrails shape how AI systems reason, access data, and take action — consistently and by default. Guardrails may be embedded within the agent itself or implemented as a separate supervisory layer — another agent or policy service — that evaluates actions before they proceed. Guardrail responses exist on a spectrum. Some enforce in the moment — blocking an action or requiring approval before it proceeds — while others generate evidence for post‑hoc review. Marketplace‑ready AI apps and agents could implement both, with the response mode matched to the severity, reversibility, and business impact of the action in question. These expectations align with the governance and evidence requirements outlined in the Microsoft Responsible AI Standard v2 General Requirements. In practice, guardrails support auditability and explainability by: Constraining behavior at design time Establishing clear defaults around what the system can and cannot do, so intended use is enforced before the system ever reaches production. Evaluating actions at runtime Making decisions visible as they happen — which tools were invoked, which data was accessed, and why an action was allowed to proceed or blocked. When governance is unclear, even strong guardrails lose their effectiveness. Controls may exist, but without clear intent they become difficult to justify, unevenly applied across environments, or disconnected from customer expectations. Over time, teams lose confidence not because the system failed, but because they can’t clearly explain why it behaved the way it did. When governance and guardrails are aligned, the result is different. Behavior is intentional. Decisions are traceable. Outcomes can be explained without guesswork. Auditability stops being a reporting exercise and becomes a natural byproduct of how the system operates day to day. Aligning governance with Marketplace expectations Governance for AI apps and agents must operate continuously, across all in‑scope environments — in both the publisher’s and the customer’s tenants. Marketplace solutions don’t live in a single boundary, and governance cannot stop at deployment or certification. Runtime enforcement is what keeps governance active as systems run and evolve. In practice, this means: Blocking or constraining actions that violate policy — such as stopping jailbreak attempts that try to override system instructions, escalate tool access, or bypass safety constraints through crafted prompts Adapting controls based on identity, environment, and risk — applying stricter limits when an agent acts across tenants, accesses sensitive data, or operates with elevated permissions Aligning agent behavior with enterprise expectations in real time — ensuring actions taken on behalf of users remain within approved roles, scopes, and approval paths These controls matter because AI behavior is dynamic. The same agent may behave differently depending on context, inputs, and downstream integrations. Governance must be able to respond to those shifts as they happen. Runtime enforcement is distinct from monitoring. Enforcement determines what is allowed to continue. Monitoring explains what happened once it’s already done. Marketplace‑ready AI solutions need both, but governance depends on enforcement to keep behavior aligned while it matters most. Operational health through auditability and traceability Operational health is the combination of traceability (what happened) and intelligibility (how to use it responsibly). When both are present, governance becomes a quality signal customers can feel day to day — not because you promised it, but because the system consistently behaves in ways they can understand and trust. Healthy AI apps and agents are not only traceable — they are intelligible in the moments that matter. For Marketplace customers, operational trust comes from being able to understand what the system is intended to do, interpret its behavior well enough to make decisions, and avoid over‑relying on outputs simply because they are produced confidently. A practical way to ground this is to be explicit about who needs to understand the system: Decision makers — the people using agent outputs to choose an action or approve a step Impacted users — the people or teams affected by decisions informed by the system’s outputs Once those stakeholders are clear, governance shows up as three operational promises you can actually support: Clarity of intended use Customers can see what the agent is designed to do (and what it is not designed to do), so outputs are used in the right contexts. Interpretability of behavior When an agent produces an output or recommendation, stakeholders can interpret it effectively — not perfectly, but reasonably well — with the context they need to make informed decisions. Protection against automation bias Your UX, guidance, and operational cues help customers stay aware of the natural tendency to over‑trust AI output, especially in high‑tempo workflows. This is where auditability and traceability become more than logs. Well governed AI systems should still answer: Who initiated an action — a user, an agent acting on their behalf, or an automated workflow What data was accessed — under which identity, scope, and context What decision was made, and why — especially when downstream systems or people are affected The logs should show evidence that stakeholders can interpret those outputs in realistic conditions — and there is a method to evaluate this, with clear criteria for release and ongoing evaluation as the solution evolves. Explainability still needs balance. Customers deserve transparency into intended use, behavior boundaries, and how to interpret outcomes — without requiring you to expose proprietary prompts, internal logic, or implementation details. For more information on securing your AI apps and agents, visit Securing AI apps and agents on Microsoft Marketplace | Microsoft Community Hub. What's next in the journey Governance creates the conditions for AI apps and agents to operate with confidence over time. With clear policies, enforcement, and evidence in place, publishers are better prepared to focus on operational maturity — how solutions are observed, maintained, and evolved safely in production. The next post explores what it takes to keep AI apps and agents healthy as they run, change, and scale in real customer environments. See the next post in the series: Quality and evaluation framework for successful AI apps and agents in Microsoft Marketplace | Microsoft Community Hub. Key resources See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor Quick-Start Development Toolkit can connect you with code templates for AI solution patterns Microsoft AI Envisioning Day Events How to build and publish AI apps and agents for Microsoft Marketplace Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV SuccessAI apps and agents: choosing your Marketplace offer type
Choosing your Marketplace offer type is one of the earliest—and most consequential—decisions you’ll make when preparing an AI app for Microsoft Marketplace. It’s also one of the hardest to change later. This post is the second in our Marketplace‑ready AI app series. Its goal is not to push you toward a specific option, but to help you understand how Marketplace offer types map to different AI delivery models—so you can make an informed decision before architecture, security, and publishing work begins. You can always get a curated step-by-step guidance through building, publishing and selling apps for Marketplace through App Advisor. This post is part of a series on building and publishing well-architected AI apps and agents in Microsoft Marketplace. The series focuses on AI apps and agents that are architected, hosted, and operated on Azure, with guidance aligned to building and selling solutions through Microsoft Marketplace. Why offer type is an important Marketplace decision Offer type is more than a packaging choice. It defines the operating model of your AI app on Marketplace: How customers acquire your solution Where the AI runtime executes Determining the right security and business boundaries for the AI solution and associated contextual data Who operates and updates the system How transactions and billing are handled Once an offer type is selected, it cannot be changed without creating a new offer. Teams that choose too quickly often discover later that the decision creates friction across architecture, security boundaries, or publishing requirements. Microsoft’s Publishing guide by offer type explains the structural differences between offer types and why this decision must be made up front. How Marketplace offer types map to AI delivery models AI apps differ from traditional software in a few critical ways: Contextual data may need to remain in a specific tenant or geography Agents may operate autonomously and continuously Control over infrastructure often determines trust and compliance How the solution is charged and monetized, including whether pricing is usage‑based, metered, or subscription‑driven (for example, billing per inference, per workflow execution, or as a flat monthly fee) The buyer’s technical capability, including the level of engineering expertise required to deploy and operate the solution (for example, SaaS is generally easier to consume, while container‑based and managed application offers often require stronger cloud engineering and DevOps skills) Marketplace offer types don’t describe features. They define responsibility boundaries—who controls the AI runtime, who owns the infrastructure, and where customer data is processed. At a high level, Marketplace supports four primary delivery models for AI solutions: SaaS Azure Managed Application Azure Container Virtual Machine Each represents a different balance between publisher control and customer control. The sections below explain what each model means in practice. Check out the interactive offer selection wizard in App Advisor for decision support. Below, we unpack each of the offer types. SaaS offers for AI apps SaaS is the most common model for AI apps and agents on Marketplace—and often the default starting point. With a SaaS offer, the AI service runs in the publisher’s Azure environment and is accessed by customers through a centralized endpoint. This model works well for: Multi‑tenant AI platforms and agents Continuous model and prompt updates Rapid experimentation and iteration Usage‑based or subscription billing Because the service is centrally hosted, publishers retain full control over deployment, updates, and operational behavior. For multi-tenant AI apps, this also means making early decisions about Microsoft Entra ID configuration—such as how customers are onboarded, whether access is granted through tenant-level consent or external identities, and how user identities, roles, and data are isolated across tenants to prevent cross-tenant access or data leakage. For official guidance, see the SaaS section of the Marketplace publishing guide and the AI agent overview, which describes SaaS‑based agent deployments. Plan a SaaS offer for Microsoft Marketplace. Azure Managed Applications for AI solutions In this model, the solution is deployed into the customer’s Azure subscription, not the publisher’s. There are two variants: Managed applications, where the publisher retains permissions to operate and update the deployed resources Solution templates, where the customer fully manages the deployment after installation This model is a strong fit when AI workloads must run inside customer‑controlled environments, such as: Regulated or sensitive data scenarios Customer‑owned networking and identity boundaries Infrastructure‑heavy AI solutions that can’t be centralized Willingness or need on part of the customer or IT team to tailor the app to the needs of the end customer specific environment Managed Applications sit between SaaS and fully customer‑run deployments. They offer more customer control than SaaS, while still allowing publishers to manage lifecycle aspects when appropriate. Marketplace guidance for Azure Applications is covered in the publishing guide. For more information, see the following links: Plan an Azure managed application for an Azure application offer. Azure Container offers for AI workloads Container offer AI workloads—typically on AKS—using container images supplied by the publisher. This model is best suited for scenarios that require: Strict data residency Air‑gapped or tightly controlled environments Customer‑managed Kubernetes infrastructure The publisher delivers the container artifacts, but deployment, scaling, and runtime operations occur in the customer’s environment. This shifts operational responsibility, risk and compute costs away from the publisher and toward the customer. Container offer requirements are covered in the Marketplace publishing guide. Plan a Microsoft Marketplace Container offer. Virtual Machine offers for AI solutions Virtual Machine offers still play a role, particularly for specialized or legacy AI solutions. VM offers package a pre‑configured AI environment that customers deploy into their Azure subscription. Compared to other models, they offer: Updates and scaling are more tightly scoped Iteration cycles tend to be longer The solution is more closely aligned with specific OS or hardware requirements They are most commonly used for: Legacy AI stacks Fixed‑function AI appliances Solutions with specialized hardware or driver dependencies VM publishing requirements are also documented in the Marketplace publishing guide. Plan a virtual machine offer for Microsoft Marketplace. Comparing offer types across AI‑specific decision dimensions Rather than asking “which offer type is best,” it’s more useful to ask what trade‑offs you’re making in an AI app delivery model comparison. Key lenses to consider include: Who operates the AI runtime day‑to‑day Where customer data and AI prompts inputs and outputs are processed and stored Example: When evaluating Saas vs managed apps for AI, check industry specific compliance requirements to evaluate whether the data has to remain in the customer’s tenant or it can be sent to the publisher’s tenant. How quickly models, prompts, and logic can evolve The balance between publisher control and customer control How Marketplace transactions and billing align with runtime behavior SaaS Container (AKS / ACI) Virtual Machine (VM) Azure Managed Application What it is Fully managed, externally hosted app integrated with Marketplace for billing and entitlement Containerized app deployed into customer-managed Azure container environments VM image deployed directly into the customer’s Azure subscription Azure native solution deployed into the customer’s subscription, managed by the publisher Control plane Publisher‑owned Customer owned Customer owned Customer owned (with publisher access) Operational model Centralized operations, updates, and scaling Customer operates infra; publisher provides containers Customer operates infra; publisher provides VM image Per customer deployment and lifecycle Good fit scenarios • Multi‑tenant AI apps serving many customers • Fast onboarding and trials • Frequent model or feature updates • Publisher has full runtime control • AI apps or agents built as microservices • Legacy or lift-and-shift AI workloads • Enterprise AI solutions requiring customer owned infrastructure Avoid when • Customers require deployment into their own subscription • Strict data residency mandates customer control • Offline or air‑gapped environments are required • Customers standardize on Kubernetes • Custom OS or driver dependencies • Tight integration with customer Azure resources Typical AI usage pattern Centralized inference and orchestration across tenants • Portability across environments is important • Specialized runtime requirements • Strong compliance and governance needs Different AI solutions land in different places across these dimensions. The right choice is the one that matches your operational reality—not just your product vision. Note: If your solution primarily delivers virtual machines or containerized workloads, use a Virtual Machine or Container offer instead of an Azure Managed Application. Supported sales models and pricing options by Marketplace offer type Marketplace offer types don’t just define how an AI app and agent is deployed — they also determine how it can be sold, transacted, and expanded through Microsoft Marketplace. Understanding the supported sales models early helps avoid misalignment between architecture, pricing, and go‑to‑market strategy. Supported sales models Offer type Transactable listing Public listing Private offers Resale enabled Multiparty private offers Azure IP Co‑sell eligible SaaS Yes Yes Yes Yes Yes Yes Container Yes Yes Yes No Yes Yes Virtual Machine Yes Yes Yes Yes Yes Yes Azure Managed Application Yes Yes Yes No Yes Yes What these sales models mean Transactable listing A Marketplace listing that allows customers to purchase the solution directly through Microsoft Marketplace, with billing handled through Microsoft. Public listing A listing that is discoverable by any customer browsing Microsoft Marketplace and available for self‑service acquisition. Private offers Customer‑specific offers created by the publisher with negotiated pricing, terms, or configurations, purchased through Marketplace. Resale enabled Using resale enabled offers, software companies can authorize their channel partners to sell their existing Marketplace offers on their behalf. After authorization, channel partners can independently create and sell private offers without direct involvement from the software company. Multiparty private offers Private offers that involve one or more Microsoft partners (such as resellers or system integrators) as part of the transaction. Azure IP Co‑sell eligible When all requirements are met this allows your offers to contribute toward customers' Microsoft Azure Consumption Commitments (MACC). Pricing section Marketplace offer types determine the AI pricing models available. Make sure you build towards a marketplace offer type that aligns with how you want to deploy and price your solution. SaaS – Subscription or flat‑rate pricing, per‑user pricing, and usage‑based (metered) pricing. Container – Kubernetes‑based offers support multiple Marketplace‑transactable pricing models aligned to how the workload runs in the customer’s environment, including per core, per core in cluster, per node, per node in cluster, per pod, or per cluster pricing, all billed on a usage basis. Container offers can also support custom metered dimensions for application‑specific usage. Alternatively, publishers may offer Bring Your Own License (BYOL) plans, where customers deploy through Marketplace but bring an existing software license. Virtual Machine – Usage-based hourly pricing (flat rate, per vCPU, or per vCPU size), with optional 1-year or 3-year reservation discounts. Publishers may also offer Bring Your Own License (BYOL) plans, where customers bring an existing software license and are billed only for Azure infrastructure. Azure Managed Application – A monthly management or service fee charged by the publisher; Azure infrastructure consumption is billed separately to the customer. Note: Azure Managed Applications are designed to charge for management and operational services, not for SaaS‑style application usage or underlying infrastructure consumption. Buyer‑side assumptions to be aware of For customers to purchase AI apps and agents through these sales models: The customer must be able to purchase through Microsoft Marketplace using their existing Microsoft procurement setup Marketplace purchases align with enterprise buying and governance controls, rather than ad‑hoc vendor contracts For private and multiparty private offers, the customer must be willing to engage in a negotiated Marketplace transaction, rather than pure self‑service checkout Important clarification Supported sales models are consistent across Marketplace offer types. What varies by offer type is how the solution is provisioned, billed, operated, and updated. Sales flexibility alone should not drive offer‑type selection — it must align with the architecture and operating model of the AI app and agent. How this decision impacts everything that follows Offer type selection for AI apps and agents ripples through the rest of the Marketplace journey. They directly shape: Architecture design choices Security and compliance boundaries Fulfillment APIs and billing integration Publishing and certification requirements Cost, scalability, and operational responsibility Follow the series for updates on new posts. What’s next in the journey With the offer type decision in place, the focus shifts to turning that choice into a production‑ready solution. This includes designing an architecture that aligns with your delivery model, establishing clear security and compliance boundaries, and preparing the operational foundations required to run, update, and scale your AI app or agent confidently in customer environments. Getting these elements right early reduces rework and sets the stage for a smoother Marketplace journey. See the next post in the series: Designing Production‑Ready AI App and Agent Architectures for Microsoft Marketplace. Key resources See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor Quick-Start Development Toolkit can connect you with code templates for AI solution patterns Microsoft AI Envisioning Day Events How to build and publish AI apps and agents for Microsoft Marketplace Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV SuccessDesign predictable usage-based billing for AI apps and agents selling in Microsoft Marketplace
Design predictable usage‑based billing for AI apps and agents selling on Microsoft Marketplace Compared to traditional software, pricing and billing feel harder because of the range of AI functionality. They reason, they infer, call tools, process data, all, to complete tasks on the customer’s behalf. If you’re building an AI app or agent to sell in Microsoft Marketplace, usage‑based billing needs to be designed with care, instrumented with intention, and explained in a way customers can trust. This post, along with App Advisor’s curated step-by-step guidance through building, publishing and selling apps for Marketplace, walks through how to do exactly that—without over‑engineering or surprising your customers later. This post is part of a series on building and publishing well-architected AI apps and agents in Microsoft Marketplace. The series focuses on AI apps and agents that are architected, hosted, and operated on Azure, with guidance aligned to building and selling solutions through Microsoft Marketplace. Why billing for AI systems is different Traditional software pricing is usually tied to static entitlements, such as licenses, seats, fixed feature sets and/or a predictable runtime footprint. AI apps and agents don’t work that way. Their cost and value are driven by runtime behavior, such as: How often a model is invoked How many tokens are processed per request How deep reasoning chains go How frequently tools or APIs are called How much data is accessed, transformed, or embedded AI behaviors are subject to change based on the interpretation of prompts and subsequent outputs processed by agents and models. That variability is why pricing AI like traditional software often creates friction—margins erode and customers may lose trust. Pricing decisions should start with business value in mind, not the meter level. Start with plan design before you define meters Plans explain pricing. Meters enforce pricing. Your Marketplace plan is where customers learn what they are buying and how it works. Before you design a single metered dimension, your plan should clearly answer: What AI behaviors are allowed What usage is included What usage becomes billable What limits apply How customers upgrade as they grow An effective plan design typically considers several key factors, such as the distinction between public and private plans, the allocation of included usage versus charges for overages, the balance of base fees against variable consumption, and the provision of clear upgrade paths across different tiers. For instance, if you’re creating an AI support agent, a well-structured plan might offer up to 1,000 resolved conversations each month for a set monthly fee, with additional charges for any conversations beyond that limit and a higher tier that grants access to increased usage allowances. When customers can easily understand what is included, what triggers extra costs, and how they can upgrade as their needs grow, metering feels straightforward and fair. Conversely, when plan details are ambiguous, even accurately measured charges can seem arbitrary, leading to uncomfortable billing discussions. Choose a billing model that matches how your AI behaves When structuring your AI solution’s pricing, begin by evaluating the expected usage patterns and the business value your AI delivers. Actively consider the nature of your agent’s workloads, the variability of customer interactions, and the predictability of operating costs. Flat Fee: Weigh the benefits of flat rate or subscription pricing. Opt for fixed monthly or annual fees when your AI solution operates within defined limits and usage remains consistent. This approach simplifies billing for customers and provides them with clear expectations. Subscription pricing works best for AI agents whose engagement is steady and whose costs don’t fluctuate dramatically. Usage-based (metered): If your AI’s usage varies widely or scales rapidly, usage-based (metered) pricing is often preferable. This model aligns charges with actual consumption, ensuring customers pay only for what they use. To implement it, leverage Marketplace metering APIs to track and bill usage accurately. Consider usage-based pricing when customer demand is unpredictable or your AI’s operational costs increase with higher workloads. Hybrid: For AI solutions that deliver ongoing baseline value but occasionally handle intensive tasks, hybrid models combine the strengths of both approaches. Offer a base subscription for predictable service, then layer in usage charges for overages. This structure is common for agents serving regular needs with intermittent spikes, enabling you to manage cost recovery while giving customers cost certainty. Metering looks different depending on your offer type As you move forward with your plan design and billing model, it’s important to recognize that metering varies significantly based on how your solution is delivered. SaaS offers: Usage tracking is accomplished through Marketplace Metering APIs, allowing you to capture AI-driven activities such as agent task executions, workflow runs, document analysis, or token processing. Your metering should align closely with the customer’s subscription lifecycle, plan tiers, and the included usage, ensuring transparency and consistency as customers progress through different service levels. Container-based offers: You might meter resources like nodes, cores, pods, or clusters—or even application-specific AI dimensions. Accurate attribution across tenants and deployments is crucial, so customers are billed reliably according to their actual consumption. Virtual machine offers: Metering is generally linked to VM runtime or license usage. Although the granularity is often lower than SaaS solutions, billing remains contractually enforced, and publishers must ensure that measurements are dependable and align with customer agreements. Azure Managed Applications: Metering should reflect solution management exclusively, while the underlying infrastructure costs are handled separately through Azure’s billing system. For more about offer types, visit Marketplace Offer Types for AI Apps and agents: SaaS vs Managed App vs Containers. Design metered dimensions customers can actually explain As you refine your billing model for Marketplace offers, it’s vital to consider how your metered dimensions will be perceived and understood by your customers. The most effective dimensions reflect clear, customer-visible value rather than abstract internal system mechanics. For AI-driven solutions, this often means tracking tangible outcomes such as agent tasks executed, successful workflows completed, data objects processed, or AI-assisted actions performed. Choosing these straightforward metrics not only makes invoices easier for customers to interpret but also strengthens your position during billing reviews by tying charges directly to business outcomes. For example, “documents analyzed” is a much clearer and more defensible metric than “token batches processed,” and “resolved workflows” resonates more with customers than “model invocations.” Ultimately, a strong metered dimension is one that a customer can easily explain to their finance or procurement teams. If the charge isn’t readily understandable, it’s a signal to revisit and refine your measurement approach. Track and plan metrics using the Microsoft Marketplace metering service APIs Under‑reporting impacts revenue. Marketplace enforces billing based on what you report. Once you've determined how your solution will be delivered and understood how metering varies by offer type, the next step is to ensure your billing model is both transparent and robust. This is accomplished by tracking your plan and meter metrics through the Microsoft Marketplace Metering Service APIs —a process that not only supports accurate billing but also builds customer trust. Instrumenting usage at runtime is essential: you must reliably capture and report consumption, making sure each event is precisely recorded and associated with the correct subscription and plan. Aggregating this usage and sending it to the marketplace—whether hourly or daily, covering the previous 24 hours—ensures billing remains consistent and defensible. Add metering guardrails to avoid cost surprises As you implement usage-based metering for your Marketplace offers, it’s essential to build guardrails that protect both your business and your customers from unexpected costs. Metering is a critical component of your service reliability, directly influencing customer trust and the overall transparency of your billing model. Ensuring your metering remains both dependable and customer-focused is crucial for maintaining trust and transparency. As you instrument your solution, take care to attribute usage precisely across multiple tenants, so every charge is accurately mapped to the correct customer and subscription. Additionally, aggregating usage on a consistent schedule—such as hourly or daily—not only supports predictable reporting but also helps customers better understand their consumption patterns. These practices lay a solid foundation for metering that supports both your business objectives and your customers’ needs, creating a seamless experience that aligns with the overall goals of your Marketplace offering. Marketplace-ready offerings typically feature: Usage caps that set clear maximums, limiting exposure to unforeseen charges. Soft limits with proactive alerts as customers approach their thresholds. Hard limits to enforce plan boundaries and prevent overages beyond agreed levels. Transparent usage dashboards, giving customers real-time visibility into their consumption. For example, when a customer reaches 80% of their allotted usage, they receive an alert and can decide whether to upgrade their plan, pause usage, or proceed into overage with full awareness—eliminating surprise invoices at month’s end. What’s Next in the Journey After establishing robust billing and metering, the next step is to enhance your AI solution’s performance, optimize API workloads, and improve production observability—laying the groundwork for scalable, efficient, and reliable operations. These capabilities help keep AI systems cost‑effective and reliable as usage grows. Key Resources See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor Quick-Start Development Toolkit can connect you with code templates for AI solution patterns Microsoft AI Envisioning Day Events How to build and publish AI apps and agents for Microsoft Marketplace Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV SuccessIntegrate Marketplace commerce signals to enforce entitlements in AI apps
How fulfillment and entitlement models differ by Microsoft Marketplace offer type AI apps and agents increasingly operate with runtime autonomy, dynamic capability exposure, and on‑demand access to tools and resources. That flexibility creates a new challenge for software companies: enforcing commercial entitlements (what a customer is allowed to access or use at runtime) correctly after a customer purchase through Microsoft Marketplace. Marketplace is the system of record for commercial truth, but enforcement always lives in your application, agent, or deployed resources. This post explains how Marketplace fulfillment and entitlement models differ by offer type—and what that means when you’re designing AI apps and agents that must respond correctly to subscription state, plan changes, and cancellations. You can always get a curated step-by-step guidance through building, publishing and selling apps for Marketplace through App Advisor. This post is part of a series on building and publishing well-architected AI apps and agents in Microsoft Marketplace. The series focuses on AI apps and agents that are architected, hosted, and operated on Azure, with guidance aligned to building and selling solutions through Microsoft Marketplace. Why AI apps and agents must integrate with Marketplace commerce signals Microsoft Marketplace is the commercial system of record for: Tracking purchase and subscription state Managing plan selection and plan changes Signaling cancellation and suspension AI apps and agents, by contrast, operate in environments where decisions are made continuously at runtime. They expose capabilities dynamically, invoke tools conditionally, and often operate without a human in the loop. That mismatch makes static enforcement insufficient, including: UI‑only checks Configuration‑time gating Prompt‑based constraints Marketplace communicates commercial truth, but it does not enforce value. That responsibility always belongs to the publisher’s application, agent, or deployed resources. Correct integration starts with understanding what Marketplace provides—and what your software must implement. What Marketplace provides—and what publishers must implement Before diving into APIs or offer types, it’s important to separate responsibilities clearly. Marketplace provides authoritative commercial signals, including: Subscription existence and current state Plan and entitlement context Licensing or usage boundaries associated with the offer Marketplace does not: Enforce your business logic Control runtime behavior Automatically limit feature or resource access Publishers are responsible for translating Marketplace signals into: Application behavior Agent capabilities Resource access boundaries That enforcement must be deterministic, auditable, and aligned with what the customer actually purchased. How those signals surface—through APIs, deployment constructs, licensing context, or metering—depends entirely on the fulfillment and entitlement model of the offer. How fulfillment and entitlement models differ by offer type Microsoft Marketplace supports multiple offer and fulfillment models, including: SaaS subscriptions Azure Managed Applications Container offers Virtual machine offers Other specialized Marketplace offer types Each model determines: How a customer receives value Where commercial signals appear Which integration mechanisms apply Where entitlement enforcement must occur Some offers rely on Marketplace APIs. Others rely on deployment‑time enforcement, resource scoping, or usage constraints. There is no single integration pattern that applies to every offer. Understanding this distinction is essential before designing entitlement enforcement for AI apps and agents. Marketplace integration responsibilities by offer type This section is the technical anchor of the post. Marketplace APIs are not universal; they apply differently depending on the offer model. SaaS offers SaaS offers integrate directly with Microsoft Marketplace through the SaaS Fulfillment APIs. These APIs are used to: Activate subscriptions Track plan changes Enforce suspension and cancellation In this model, Marketplace communicates subscription lifecycle events, but it does not enforce access. The publisher must: Map Marketplace subscriptions to internal tenants Maintain a durable subscription record Enforce entitlements at runtime For AI apps and agents, that enforcement typically happens in orchestration logic or tool‑invocation boundaries—not in the UI or prompts. SaaS Fulfillment APIs are the primary mechanism for receiving commercial truth, but the application remains responsible for acting on it. Container offers Container offers deliver value as container images and associated artifacts, such as Helm charts. In this model, the publisher is shipping a deployable artifact—not an application endpoint or API managed by Marketplace. Marketplace provides: Entitlement to deploy the container image Optional usage‑based billing and metering Ability to deploy to an existing AKS cluster or to a publisher configure one Enforcement occurs at: Deployment time, by controlling access to images Runtime usage, through configuration and limits Metered dimensions, when usage‑based billing applies For AI workloads packaged as containers, entitlement enforcement is typically embedded in the runtime configuration, resource limits, or metering logic—not in Marketplace APIs. Virtual machine offers Virtual machine offers are fulfilled through VM image deployment. In this model: Fulfillment is based on VM deployment Licensing and usage are enforced through the VM lifecycle Subscription state is less event‑driven but still contractually binding While there is no SaaS‑style fulfillment callback, publishers must still ensure that deployed workloads align with the purchased offer. For AI solutions delivered via VM images, enforcement is tied to licensing, configuration, and operational controls inside the VM. Azure Managed Applications For Azure Managed Applications, fulfillment is enforced through the Azure Resource Manager (ARM) deployment lifecycle. In this model: A Marketplace purchase establishes deployment rights Resources are deployed into a managed resource group Operational boundaries are defined by ARM and Azure role assignments Publishers enforce value through: Deployment behavior Resource configuration Lifecycle management and updates For AI solutions delivered as managed applications, entitlement enforcement is tied to what is deployed and how it is operated—not to an external subscription API. Marketplace establishes the contract, and Azure enforces access through infrastructure boundaries. Other offer types Other Marketplace offer types follow similar patterns, with varying degrees of API involvement and deployment‑time enforcement. The key principle holds: Marketplace establishes commercial rights, but enforcement is always implemented by the publisher, using the mechanisms appropriate to the offer model. Designing entitlement enforcement into AI apps and agents Entitlements must be enforced outside the model. Large language models should never be responsible for deciding what a customer is allowed to do. Effective enforcement belongs in: The interaction layer The orchestration layer Tool invocation boundaries Avoid: UI‑only enforcement Prompt‑based entitlement logic Soft limits without auditability AI agents should request capabilities from deterministic services that already understand subscription state and plan entitlements. This ensures enforcement is consistent, testable, and resilient. Handling plan changes, upgrades, and feature tiers Plan changes are common in Microsoft Marketplace. AI capability must align continuously with: The active subscription tier Purchased dimensions or limits Common examples include: Agent autonomy limits Tool or connector access Rate limits Data scope Feature gating must be deterministic and testable. When a plan changes, your application or agent should respond predictably—without manual intervention or redeployment. Failure, retry, and reconciliation patterns Marketplace events are not guaranteed to be: Ordered Delivered once Immediately available AI apps must handle: Duplicate events Missed callbacks Temporary Marketplace or network failures Reconciliation processes protect customers, publishers, and Marketplace trust. Periodic verification of subscription state ensures that runtime enforcement remains aligned with commercial reality. How Marketplace API integration affects readiness and review Marketplace reviewers look for: Clear enforcement of subscription state Clean suspension and revocation paths Strong integration leads to: Faster certification Fewer conditional approvals Lower support burden after launch Correct enforcement is not just a technical requirement—it’s a Marketplace readiness signal. What’s next in the journey Once entitlement enforcement is solid, the next layer of operational maturity includes: Usage‑based billing and metering architecture Performance, caching, and cost optimization Observability and operational health for AI apps and agents Key resources See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor Quick-Start Development Toolkit can connect you with code templates for AI solution patterns Microsoft AI Envisioning Day Events How to build and publish AI apps and agents for Microsoft Marketplace Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV SuccessDesign tenant linking to scale selling on Microsoft Marketplace
Designing tenant linking and Open Authorization (OAuth) directly shapes how customers onboard, grant trust, and operate your AI app or agent through Microsoft Marketplace. This post explains how to design scalable, review‑ready identity patterns that support secure activation, clear authorization boundaries, and enterprise trust from day one. Guidance for multi‑tenant AI apps Identity decisions are rarely visible in architecture diagrams, but they are immediately visible to customers. In Microsoft Marketplace, tenant linking and OAuth consent are not background implementation details. They shape activation, onboarding, certification, and long‑term trust with enterprise buyers. When identity decisions are made late, the impact is predictable. Onboarding breaks. Permissions feel misaligned. Reviews stall. Customers hesitate. When identity is designed intentionally from the start, Marketplace experiences feel coherent, secure, and enterprise‑ready. This post focuses on how software development companies (like ISVs) can design tenant linking and consent patterns that scale across customers, offer types, and Marketplace review—without rework later. You can always get curated step-by-step guidance through building, publishing and selling apps for Marketplace through App Advisor. This post is part of a series that focuses on AI apps and agents that are architected, hosted, and operated on Azure, with guidance aligned to building and selling solutions through Microsoft Marketplace. Why identity across tenants is a first‑class design decision Designing identity is not just about authentication. It is about how trust is established between your solution and a customer tenant, and how that trust evolves over time. When identity decisions are deferred, failure modes surface quickly: Activation flows that cannot complete cleanly Consent requests that do not match declared functionality Over‑privileged apps that fail security review Customers who cannot confidently revoke access These are not edge cases. They are some of the most common reasons Marketplace onboarding slows or certifications are delayed. A good identity and access management design ensures that trust, consent, provisioning, and operation follow a predictable and reviewable path—one that customers understand and administrators can approve. Marketplace tenant linking requirements A key mental model simplifies everything that follows: separate trust establishment from authorization. Tenant linking and OAuth consent solve different problems. Tenant linking establishes trust between tenants OAuth consent grants permission within that trust Tenant linking answers: Which customer tenant does this solution trust? OAuth consent answers: What is this solution allowed to do once trusted? AI solutions published in Microsoft Marketplace should enforce this separation intentionally. Trust must be established before meaningful permissions are granted, and permission scope must align to declared functionality. Making this distinction explicit early prevents architectural shortcuts that later block certification. Throughout the rest of this post, tenant linking refers to trust establishment, not permission scope. Microsoft Entra ID as the identity foundation Microsoft Entra ID provides the primitives for identity-based access control, but the concepts only become useful when translated into publisher decisions. Each core concept maps to a choice you make early: Home tenant vs resource tenant Determines where operational control lives and how cross‑tenant trust is anchored. App registrations Define the maximum permission boundary your solution can ever request. Service principals Determine how your app appears, is governed, and is managed inside customer tenants. Managed identities Reduce long‑term credential risk and operational overhead. Understanding these decisions early prevents redesigning consent flows, re‑certifying offers, or re‑provisioning customers later. Marketplace policies reinforce this by allowing only limited consent during activation, with broader permissions granted incrementally after onboarding. Importantly, activation consent is not operational consent. Activation establishes the commercial and identity relationship. Operational permissions come later, when customers understand what your solution will actually do. OAuth consent patterns for multi‑tenant AI apps OAuth consent is not an implementation detail in Marketplace. It directly determines whether your AI app can be certified, deployed smoothly, and governed by enterprise customers. Common consent patterns map closely to AI behavior: User consent Supports read‑only or user‑initiated interactions with no autonomous actions. Admin consent Enables agents, background jobs, cross‑user access, and cross‑resource operations. Pre‑authorized consent Enables predictable, enterprise‑grade onboarding with known and approved scopes. While some AI experiences begin with user‑driven interactions, most AI solutions in Marketplace ultimately require admin consent. They operate asynchronously, act across resources, or persist beyond a single user session. Aligning expectations early avoids friction during review and deployment. Designing consent flows customers trust Consent dialogs are part of your product experience. They are not just Microsoft‑provided UI. Marketplace reviewers evaluate whether requested permissions are proportional to declared functionality. Over‑scoped consent remains one of the most common causes of delayed or failed certification. Strong consent design: Requests only what is necessary for declared behavior Explains why permissions are needed in plain language Aligns timing with customer understanding Poor explanations increase admin rejection rates, even when permissions are technically valid. Clear consent copy builds trust and accelerates approvals. Tenant linking across offer types Identity design must align with offer type; a helpful framing is ownership: SaaS offers The publisher owns identity orchestration and tenant linking. Microsoft Marketplace reviewers expect this alignment, and mismatches surface quickly during certification. Containers and virtual machines The customer owns runtime identity; the publisher integrates with it. Managed applications Responsibility is shared, but the publisher defines the trust boundary. Each model carries different expectations for control, consent, and revocation. Designing tenant linking that matches the offer type reduces customer confusion. When consent actually happens in Marketplace lifecycle Many identity issues stem from unclear timing. A simple lifecycle helps anchor expectations: Buy – The customer purchases the offer Activate – Tenant trust is established Consent – Limited activation consent is granted Provision – Resources and configurations are created Operate – Incremental operational consent may be requested Revoke – Access and trust can be cleanly removed Making this sequence explicit in your design—and in your documentation—dramatically reduces confusion for customers and reviewers alike. How tenant linking shapes Marketplace readiness Identity tends to leave a lasting impression as it is one of the first architectural design choices encountered by customers. Strong tenant linking and consent design leads to: Faster certification (applies to SaaS offer only) Fewer conditional approvals Lower onboarding drop‑off Easier enterprise security reviews These outcomes are not accidental. They reflect intentional design choices made early. What’s next in the journey Tenant identity sets the foundation, but it is only one part of Marketplace readiness. In upcoming guidance, we’ll connect identity decisions to commerce, SaaS Fulfillment APIs, and operational lifecycle management—so buy, activate, provision, operate, and revoke work together as a single, coherent system. Key Resources See curated, step-by-step guidance to help you build, publish, or sell your app or agent (no matter where you start) in App Advisor Quick-Start Development Toolkit can connect you with code templates for AI solution patterns Microsoft AI Envisioning Day Events How to build and publish AI apps and agents for Microsoft Marketplace Get over $126K USD in benefits and technical consultations to help you replicate and publish your app with ISV Success
