What Microsoft Agent 365 actually is
Agent 365 is the layer Microsoft added once it became clear that enterprises were going to run hundreds of agents and had no idea how many they already had. Microsoft describes it as a control plane, and the description is accurate: it observes agents across the enterprise, governs how they access systems, data and tools, and secures them with Microsoft identity and security capabilities. Microsoft groups the product into five capabilities. Registry is a single inventory of every agent in the tenant, including agents Microsoft did not build. Access Control handles permissions and policy. Visualization is the dashboard and analytics layer. Interoperability is agents reaching Word, Excel, SharePoint and Dynamics 365 through what Microsoft calls Work IQ. Security is Defender and Purview applied to agents rather than to people. If you have been treating agents as a shadow IT problem, this is the product that turns them into a managed asset, and it genuinely does that job.
Agent 365 pricing: what 15 dollars and 99 dollars actually buy
The list prices are straightforward and the licensing model is the part people get wrong. Agent 365 standalone lists at 15 dollars per user per month, generally available since 1 May 2026. It is also bundled into Microsoft 365 E7 at 99 dollars per user per month, which packages E5, Copilot, the Entra Suite and Agent 365 together. Buying those pieces separately as E5 plus Copilot plus Agent 365 comes to roughly 105 dollars, so E7 is the cheaper route for an organization that wants all of it. The detail worth underlining: the license is per user, not per agent. One Agent 365 license covers every agent that person owns, sponsors, manages or interacts with, so deploying your eleventh agent does not add a line to the invoice. That is unusually generous, and it is also why the cost conversation moves somewhere else, which is the next section.
The bill Agent 365 does not put a ceiling on
Licensing covers governance. It does not cover building or running agents, and those costs are metered on a different invoice entirely. Copilot Studio consumption and Azure compute land on the Azure bill as variable spend, while Agent 365 lands on the Microsoft 365 bill as a fixed per seat rate. Several licensing consultancies have already made this point well and they are right to: a budget owner who signed off on a predictable per user rate can be surprised by a consumption line nobody modelled, because an agent that retrieves ten files per prompt costs more than one that retrieves three, and an agent that runs 500 times a day costs more than one that runs fifty. We want to be clear that this is a real gap and it is not the one this page is about. It is a compute cost problem, and FinOps tooling addresses it. The gap nobody is writing about is one layer further out.
The second money gap: what happens when the agent buys something
There are two ways an agent costs you money and only one of them shows up on a Microsoft invoice. The first is compute, covered above. The second is purchasing: the agent that renews a SaaS subscription, tops up an ad account, books travel, pays a supplier invoice, buys API credits or approves a purchase order. That money leaves through your bank, your card program or your payables system, and Agent 365 has no visibility into it and no control surface for it. This is not a criticism of the product. An identity and access control plane is the wrong place to encode a finance policy, exactly as we concluded about payment MCP servers and accounting MCP servers when we probed those. It is still a gap at the program level, and the reason it deserves stating plainly is that Agent 365 is so thorough everywhere else that it is easy to assume it is thorough here too. It is not, and we checked properly rather than assuming.
How we checked, and why the control matters
Rather than reading marketing pages, we went to the machine readable definition. On 8 September 2026 we fetched https://graph.microsoft.com/beta/$metadata, the Common Schema Definition Language document that defines every entity, property and enumeration in the Microsoft Graph beta surface. It returned HTTP 200 and 3,951,869 bytes, containing 2,508 EntityTypes, 3,371 ComplexTypes and 1,885 EnumTypes. We then enumerated every type whose name contains the word agent, discarded the ones that are unrelated to agent governance (Cloud PC agent pools, on premises sync agents, and HTTP user agent strings), and read the property list of each remaining type. The critical part is the control. Running a regular expression that finds nothing proves nothing on its own, because the regex may simply be broken. So we ran the identical pattern across the whole document to confirm it fires where money genuinely exists. It does, on 37 other types. Anyone can re-run both halves and get the same answer, which is the point.
What the probe found: 623 properties, zero of them money
Across the 48 agent governance types in the Graph beta schema we counted 623 properties. Not one matches amount, currency, budget, spend, price, cost, payment, invoice, monetary, creditLimit, dollar, purchase or even the generic word limit. The type vocabulary is rich and it is entirely about identity, capability and risk: agentIdentity, agentRegistration, agentRegistry, agentIdentityBlueprint, agentCapabilities, agentSkill, agentSignIn, riskyAgent, agentCardManifest, targetAgentIdentitySponsorsOrOwners. That last one is a nice illustration of how carefully Microsoft has thought about accountability: there is a first class concept for who sponsors and owns an agent. There is simply no first class concept for what an agent may spend.
Conditional Access knows about agents and still has no amount
This is the finding we found most telling. Conditional Access is the policy engine every Microsoft shop already uses to decide who gets into what, and Microsoft has plainly extended it to agents. In the Graph beta schema there are 29 conditionalAccess types carrying 99 distinct properties, and the condition vocabulary now includes agents, agentFilter, agentContext, agentIdRiskLevels and agentIdServicePrincipalFilter. So the policy engine is fully agent aware. It can express this agent, from this location, at this risk level, using this authentication strength, may or may not reach this application. What it cannot express, because none of those 99 properties is monetary, is this agent may spend up to 500 dollars this week, with any single transaction over 100 dollars pausing for its owner. Conditional Access is a binary gate on access. Purchasing needs a graduated gate on amount, and those are different shapes of control that no amount of policy tuning turns into each other.
The control result, stated plainly
The same regular expression that returned zero across 623 agent properties returned matches on 37 other Microsoft Graph types. bookingAppointment carries invoiceAmount, invoiceDate, invoiceId and invoiceStatus. bookingService carries defaultPrice and defaultPriceType. agedAccountsPayable and agedAccountsReceivable both carry currencyCode and currentAmount. company carries paymentMethods, paymentTerms, customerPayments and customerPaymentJournals. employeeOrgData carries costCenter. Microsoft Graph models money in detail when the domain calls for it. The absence around agents is therefore a design decision rather than an oversight in our method, and that is precisely what makes it quotable: Microsoft built a thorough agent control plane and deliberately scoped money out of it.
Entra Agent ID vs Agent 365: which one does what
These two get conflated constantly and the split is actually clean. Microsoft Entra provides the identity foundation through Agent ID: it manages agent identities, blueprints and permissions, applies Conditional Access, identity governance and network security controls, and monitors identity related security signals. Agent 365 is the unified registry and control plane on top: it is where you discover and manage every agent in the organization, including agents that have no Entra agent identity at all, and where you monitor operational activity. Microsoft converged the registry experiences under Agent 365 in 2026 after customers complained about agent visibility being scattered across the Entra admin center and the Microsoft 365 admin center. Practically: use Agent 365 to find and manage agents, use Entra to manage their identities and access policies. Roles matter here too. Viewing the inventory needs the AI Reader role and no specific license, while changing agent identities needs Agent ID Administrator, and applying Conditional Access or identity governance to agents needs the appropriate Entra Agent ID licensing.
What to do before your first agent buys something
If you are rolling out Agent 365, the governance work it does is genuinely most of the job and you should do it. Register every agent, assign a real owner and sponsor rather than a shared mailbox, apply Conditional Access, and use the AI Reader role as the default so most people can see the inventory without being able to change it. Then treat purchasing as a separate control that you have to add. The design that holds up separates capability from authority. A credential or a Conditional Access policy decides what an agent can reach. A spend policy decides whether this specific action, right now, for this amount, to this counterparty, is allowed. Keep them in different systems and you get both. Concretely, before an agent transacts: give it its own funded wallet rather than a shared corporate card, so a bad day is contained to one balance and the charges are attributable. Check every intended payment against policy before a credential exists, covering the per transaction ceiling, the running total over a window, the vendor allowlist and the velocity rule that catches a retry loop. Pause anything above your threshold for human approval. Issue a merchant locked virtual card scoped to a single purchase rather than a reusable key. And write every decision to an immutable audit trail naming the agent, its owner, the intent and the policy that allowed it.
How Agentspay fits alongside Agent 365
Agentspay does not replace Agent 365 and there is no overlap to argue about. Microsoft owns identity, registry, access and security for your agents, and it does that better than any startup will. Agentspay occupies the layer the Graph schema shows is empty: the policy decision in front of the money. You keep Entra Agent ID as the identity, keep Agent 365 as the registry and control plane, and put a spend policy between your agents and your bank. Because the control plane is rail neutral, it does not care whether the agent pays by card, by ACP checkout, by AP2 mandate or over x402. The same measurement one cloud over found that Gemini Enterprise does ship an enforced spend cap, and that it is scoped to a billing project rather than to an agent. For the wider category, AI agent governance covers the control frameworks in general, AI agent payment platforms compares the vendors in this space, and procurement agents covers the buying workflow itself. If your agents are also reaching your books, our probes of accounting MCP servers and payment MCP servers used the same method and reached the same conclusion one layer down, as did our measurement of Salesforce Agentforce spend controls in the Salesforce object model.