Aembit Adds Copilot Studio Agent Security: Runtime Credentials, Auditing, Least Privilege

Aembit announced on June 16, 2026, that it now supports Microsoft Copilot Studio agents, adding runtime credential issuance, least-privilege policy enforcement, and access auditing for agents that connect to enterprise resources. The pitch is not simply that another security vendor has added another Microsoft integration. It is that the agent boom is dragging identity teams into a category of workload they did not design their access models to govern. Copilot Studio makes it easy to build agents; Aembit is betting that ease will become a liability unless enterprises can control what those agents touch.

The Copilot Studio Security Story Has Moved From Chat to Access​

Microsoft Copilot Studio is no longer just a chatbot builder with a friendly enterprise wrapper. Microsoft’s own documentation now frames it as a place to create, extend, deploy, evaluate, and administer agents that can use connectors, knowledge sources, workflows, and Model Context Protocol servers. That matters because the security boundary is no longer the prompt box. It is the moment an agent decides to call a tool.
Aembit’s announcement lands squarely in that gap. The company says its new Copilot Studio support lets security teams govern how agents authenticate to internal systems, external APIs, and enterprise resources. Instead of allowing an agent to hold or reuse a broad credential, Aembit places itself between the agent and the destination service, evaluates the access request, and issues a short-lived credential only when policy allows it.
That sounds like familiar zero-trust language, and in many ways it is. The difference is that AI agents are not conventional service accounts, cron jobs, or microservices. They are software actors driven by user context, model output, tool descriptions, orchestration rules, and runtime decisions. The identity problem is therefore not just “which app is calling which API?” It is “which agent, acting for which session, decided to call which tool, under what conditions, and why was that allowed?”
For WindowsForum readers, the Microsoft angle is the point. Copilot Studio sits inside the same enterprise gravitational field as Microsoft 365, Power Platform, Entra ID, Dataverse, Teams, SharePoint, and the rest of the Microsoft cloud estate. If agents become another way into those systems, then agent identity becomes part of Windows and Microsoft 365 administration, not a boutique AI governance concern.

---

Microsoft Lowered the Agent Barrier, and That Was the Product​

Copilot Studio’s appeal is obvious: it lets business units and IT teams build agents without starting from scratch. A maker can connect an agent to knowledge, add tools, publish it into supported channels, and wire it into workflows with far less engineering effort than a custom LLM application would require. Microsoft has spent the last year making this platform feel more like an agent assembly line than an experimental playground.
The arrival of MCP support sharpened that proposition. Model Context Protocol gives agents a standardized way to discover and invoke tools and resources exposed by a server. In practice, that means an agent can be connected to systems that were never designed specifically for Copilot Studio, provided the right MCP layer exists. The enterprise value is speed: the agent can move from answering questions to taking action.
But speed is also the security problem. When a tool becomes easy enough to add in a few clicks, the number of pathways from agent to enterprise resource can multiply faster than centralized security teams can review them. This is the old shadow IT story with a new runtime: instead of unsanctioned SaaS apps, the risk is semi-sanctioned agents with unclear access boundaries.
Microsoft does provide administration and governance capabilities around Copilot Studio, including authentication configuration, data policies, environment management, analytics, and security controls. But Aembit is arguing that the specific act of agent-to-resource authentication needs a more dynamic control plane than many existing IAM deployments provide. That is a narrow claim, but it is also a consequential one.
The reason is simple: Copilot Studio agents can be useful precisely because they are not locked to one deterministic path. They can choose tools based on a user request and the orchestration instructions they have been given. The same agent may answer a simple knowledge question in one exchange, call a ticketing system in another, and query a finance API in a third. A static access model starts to look brittle when the caller’s behavior is probabilistic.

Static Credentials Are the Wrong Abstraction for Agents​

Traditional enterprise access models assume relatively stable roles. A human user signs in, receives permissions, and acts through applications. A workload runs as a service identity, does a defined job, and is granted access appropriate to that job. Even when those models are imperfect, they are legible.
AI agents are legible in a different way. They are not human, but they often act in response to a human. They are not a normal workload, because their tool selection can vary by request. They may need access to a resource only for a single task, but the simplest deployment pattern may leave them with broader or longer-lived credentials than that task deserves.
That is the mismatch Aembit is trying to commercialize. Its announcement argues that OAuth consent or a service account can get an agent working, but may not give security teams enough control, attribution, or auditability. If multiple agents share infrastructure, a log entry showing a credential was used may not explain which agent triggered it, which user session was involved, or which policy decision authorized the request.
There is a practical Windows-admin version of this problem. Imagine a Copilot Studio agent built to help employees retrieve HR policy, open support tickets, and summarize SharePoint documents. In a demo, it looks benign. In production, it may need to call Microsoft Graph, a help desk API, a document repository, and a workflow endpoint. If the agent is over-permissioned because no one wants it to fail, the organization has converted convenience into standing access.
Aembit’s answer is to make credentials ephemeral. At runtime, the agent requests access, Aembit evaluates the request against policy, and an authorized request receives a scoped credential that expires after use. The key claim is not that short-lived credentials are new. It is that agent access should be brokered at the moment of action, rather than preloaded into the agent’s environment as a persistent secret.

The Audit Trail Is Becoming the Real Product​

Security vendors often lead with prevention, but the more interesting part of Aembit’s Copilot Studio pitch is accountability. The company says its integration can log credential issuance, access events, and policy decisions with enough context to support compliance review. That is where agent security becomes operational rather than philosophical.
Auditors do not usually ask whether an architecture felt modern. They ask who accessed what, when, under whose authority, and whether that access was appropriate. With agents, that question becomes messier. If an employee asks an agent to perform a task, and the agent calls three systems to complete it, the resulting access chain must preserve both the user context and the agent identity.
Aembit uses the term blended identity for this model: an identity distinct from the user, but tied to the user’s session, with credentials issued at runtime for a specific task. The branding is vendor-specific, but the underlying concept is likely to become unavoidable. Enterprises will need to distinguish between “Alice accessed a record,” “an app accessed a record,” and “an agent acting in Alice’s session accessed a record after a policy engine allowed it.”
That distinction matters in incident response. If a token leaks, a short-lived credential reduces the window of abuse. If an agent behaves unexpectedly, contextual logs give investigators something more useful than a pile of API calls. If a business unit deploys an agent that quietly touches a restricted system, centralized policy enforcement gives the security team a chance to catch the pattern before it becomes institutionalized risk.
There is also a governance benefit. Agent deployments are likely to sprawl across departments because the barrier to creation is intentionally low. Central policy management gives security teams a place to define rules that travel with the access path, rather than relying on every maker, developer, or business analyst to understand the full implications of credential scope.

---

MCP Makes the Agent Useful, Then Makes IAM Nervous​

Model Context Protocol is a major reason this conversation is accelerating. By standardizing how agents connect to tools and resources, MCP helps reduce one-off integration work. It also makes tool access more portable across agent platforms. That is good for developers and platform teams, but it changes the security surface.
A tool interface is an invitation to act. Once an agent can discover a tool, understand its description, and invoke it, the agent is no longer merely producing text. It is participating in business processes. Depending on the connected systems, those actions may be low-risk, such as searching public documentation, or high-risk, such as updating records, creating tickets, moving files, or calling transactional APIs.
Microsoft has embraced MCP across parts of its agent ecosystem, including Copilot Studio. That makes sense strategically. If Microsoft wants Copilot Studio to be the enterprise agent workbench, it needs a way to connect agents to the messy world beyond Microsoft’s own connectors. MCP is the bridge.
But every bridge needs a checkpoint. The more agent platforms standardize tool invocation, the more identity teams will need standardized ways to enforce access at invocation time. Otherwise, MCP becomes a neat integration layer sitting atop a credential model inherited from less dynamic software.
This is where Aembit’s announcement should be read less as a one-off integration and more as a market signal. Identity security vendors are beginning to treat AI agents as a first-class workload category. Aembit is not alone in seeing Copilot Studio as an obvious place to plant a flag; other identity security companies have also announced agent identity controls for Microsoft’s agent-building platform. The land grab is on because the enterprise Microsoft estate is where many of these agents will actually run.

Microsoft’s Native Controls Still Matter, but They Will Not End the Debate​

It would be wrong to frame this as Microsoft ignoring security. Copilot Studio sits within Power Platform governance, Microsoft 365 administration, and Entra-based identity patterns. Microsoft has also been adding threat protection and administration features around agent behavior, including controls aimed at prompt-injection risks and data exfiltration scenarios.
The question is whether native platform controls are enough for every enterprise access model. Large organizations rarely run on a single vendor’s identity assumptions. They have legacy systems, non-Microsoft APIs, custom services, multiple clouds, third-party SaaS, and compliance regimes that predate the agent era. They also have security teams that want policy consistency across platforms, not one agent access model for Microsoft, another for Anthropic-based workflows, another for internal LangChain apps, and another for whatever a business unit pilots next quarter.
Aembit’s announcement leans into that heterogeneity. The company says its approach applies not only to Copilot Studio but also to other agent platforms and custom LLM workflows that make API calls. That platform-agnostic framing is important, because enterprises are unlikely to standardize on a single agent builder in the near term. Even organizations committed to Microsoft 365 Copilot will still experiment with developer agents, customer-service agents, internal automation agents, and custom domain-specific assistants.
The real contest will be over where agent access policy should live. Microsoft will naturally argue for deep native governance within its cloud. Third-party identity vendors will argue for cross-platform policy enforcement. Most enterprises will probably use both, because that is how enterprise security usually evolves: platform controls for the basics, external controls where risk, scale, or compliance pressure demands more.
For administrators, the practical advice is to avoid treating these layers as mutually exclusive. Native Copilot Studio governance can define who can create agents, where they run, how they are published, and what platform controls apply. Runtime credential brokering can define whether a particular agent action should receive access to a particular resource at a particular moment. Those are related problems, not identical ones.

The Agent Sprawl Problem Is Organizational Before It Is Technical​

The most revealing line in Aembit’s announcement is not about tokens or audits. It is the assertion that “the agents are already in your environment.” That is marketing, but it is also plausible. In many companies, AI adoption is not moving through a single architecture review board. It is arriving through productivity tools, developer environments, SaaS features, Power Platform projects, and departmental pilots.
That creates a familiar governance lag. First, a tool becomes useful. Then it becomes widely used. Then security teams discover how many exceptions, credentials, connectors, and unofficial workflows now exist. The agent version of this pattern may move faster because building an agent is easier than building a traditional application.
Copilot Studio amplifies the trend because it gives non-specialists access to agent creation inside a Microsoft environment many enterprises already trust. That trust can be beneficial; it means agents may inherit better governance than a random external AI service. But it can also reduce skepticism. If something is “in Microsoft,” a business team may assume it is automatically safe enough.
The right response is not to ban agent building. That would simply push experimentation elsewhere. The better response is to classify agents as production actors as soon as they can access production resources. If an agent can call a system of record, retrieve restricted data, or trigger a workflow, it deserves the same access scrutiny as any other workload — and probably more, because its behavior may be less predictable.
This is where identity teams should be pushing for inventory. Which Copilot Studio agents exist? Which environments host them? Which tools are attached? Which users can publish them? Which resources can they access? Which credentials do they use? Which logs would show an improper access attempt? If those questions cannot be answered quickly, the organization has an agent governance problem whether or not it has suffered an incident.

---

The Least-Privilege Promise Will Be Tested in Production​

Least privilege is easy to endorse and hard to implement. With conventional applications, teams often over-scope access because permissions are tedious, ownership is unclear, and nobody wants a business process to break. Agents add another reason: uncertainty. If no one knows exactly which tool path an agent will choose for a given request, the temptation is to grant broader access “just in case.”
Aembit’s runtime model is meant to resist that temptation. Instead of granting an agent a persistent credential broad enough for many possible futures, it grants a short-lived credential for the specific interaction that policy approves. In theory, that lets security teams preserve agent flexibility without accepting standing access.
The production challenge will be policy design. Someone still has to define which agents may access which resources under which conditions. If those policies are too strict, agents will fail at legitimate tasks. If they are too loose, ephemeral credentials become a nicer wrapper around excessive privilege. The hard work does not disappear; it moves into a policy engine and audit workflow.
There is also the problem of context quality. To make a good access decision, a broker needs useful signals: agent identity, user session, requested resource, task context, environment, risk posture, and perhaps data sensitivity. Enterprises will need to decide how much of that context is trustworthy and how much can be influenced by the model, the prompt, or the tool description. A security policy that relies too heavily on model-generated intent may be weaker than it looks.
Still, the direction is right. Security teams should prefer temporary, scoped credentials over long-lived secrets embedded in agent configurations. They should prefer attributable access events over shared service accounts. They should prefer centralized policy over ad hoc OAuth consent scattered across departmental projects. Aembit’s integration is notable because it packages those preferences for a Microsoft agent platform that many enterprises are already evaluating.

Identiverse Is the Right Stage for an Identity Reframing​

Aembit is announcing the Copilot Studio integration at Identiverse 2026, which is not accidental. Identiverse is an identity conference, not an AI developer showcase. The intended audience is the group that has spent years building controls for human access, workload identity, privileged access, and zero trust. Aembit is telling that audience: agents are your problem now.
That framing is more useful than another round of generic AI safety language. Enterprise AI risk is often discussed in terms of hallucination, prompt injection, data leakage, and governance boards. Those are real concerns. But the operational question for many IT shops will be more concrete: when an agent needs a credential, what happens?
If the answer is “it uses a service account someone created during the pilot,” the organization is building debt. If the answer is “the user consented once and now we hope the scope is acceptable,” the organization is relying on a model designed for a less agentic world. If the answer is “we issue short-lived credentials under policy and log every decision,” the organization is at least speaking the language of modern identity.
The identity industry likes to rename old problems, and there is some of that here. Workload identity, just-in-time access, short-lived credentials, and audit logging are not inventions of the agent era. But agents change the pressure on those concepts. They make runtime access decisions more frequent, more varied, and more likely to cross system boundaries in ways that business users do not fully see.
That is why Copilot Studio is a useful test case. It is enterprise-friendly, Microsoft-administered, and designed for broad adoption. If identity teams cannot create workable controls for agents in that environment, they will struggle even more with custom agent stacks spread across clouds, developer laptops, and SaaS automation platforms.

The Practical Reading for Windows and Microsoft 365 Shops​

For Microsoft-focused organizations, the Aembit announcement should trigger a review, not a purchasing reflex. The first question is not whether Aembit is the right vendor. The first question is whether Copilot Studio agents in the tenant are already accessing enterprise resources in ways security teams can explain.
That review should include both official and informal deployments. Copilot Studio agents built in sanctioned environments are only part of the picture. Teams may also be experimenting with MCP servers, custom connectors, Power Automate flows, internal APIs, and agent-like workflows that do not carry the Copilot Studio label. The access model should be assessed across the full path from user prompt to tool invocation to resource action.
Administrators should also separate two kinds of controls. Platform governance answers who can build, publish, and manage agents. Runtime access governance answers what an agent can reach at the moment it tries to act. Organizations need both. A beautifully governed agent catalog does not help much if every production agent shares an overpowered API key.
The other practical issue is logging. Microsoft 365 and Power Platform administrators are used to collecting audit data, but agent actions can blur attribution. If a Copilot Studio agent calls a downstream service through a connector or MCP server, the resulting logs must preserve enough context to reconstruct the event. Otherwise, the organization may know that access occurred but not whether it was appropriate.
Finally, there is the lifecycle question. Agents will change. Tools will be added, prompts will be revised, workflows will be updated, and business owners will ask for broader capabilities once early demos succeed. Access policies need to evolve with those changes. A one-time approval for an agent is not enough if the agent’s tool surface doubles three months later.

---

The Missing Credential Layer Is Now the Copilot Studio Battleground​

Aembit’s Copilot Studio integration is best understood as part of a larger shift: AI agent security is moving from abstract governance decks into the plumbing of enterprise identity. The concrete takeaways are narrower, and more useful, than the hype around “agentic AI” suggests.

• Copilot Studio agents should be treated as workload identities once they can call enterprise tools or access production data.
• Static service accounts and broad API keys are especially risky for agents because agent behavior can vary at runtime.
• Short-lived, scoped credentials reduce standing access, but only if the surrounding policy model is specific enough to prevent over-permissioning.
• Audit logs need to show the agent, the triggering user session, the requested resource, and the policy decision, not merely that a credential was used.
• Microsoft’s native Copilot Studio governance remains important, but cross-platform agent access controls may become necessary in mixed enterprise environments.
• MCP increases the value of agents by expanding their tool reach, which also increases the urgency of runtime access enforcement.

The interesting part of Aembit’s announcement is not that Copilot Studio has attracted another integration. It is that the industry is beginning to converge on a harder truth: agents are not merely interfaces, and they are not merely workloads. They are delegated actors operating in systems built for humans and deterministic software. The enterprises that thrive with them will be the ones that make access temporary, attributable, and governed before agent sprawl turns yesterday’s productivity pilot into tomorrow’s audit finding.

---

References​

1. Primary source: Security Boulevard
   Published: Tue, 16 Jun 2026 12:20:31 GMT
   
   

   Aembit Now Secures Microsoft Copilot Studio Agents - Security Boulevard

   5 min readToday, we’re announcing that Aembit supports the deployment of Microsoft Copilot Studio agents – giving security teams a purpose-built way to govern how Copilot Studio agents authenticate to enterprise resources, enforce least-privilege access policies, and maintain a complete audit...

   securityboulevard.com
2. Official source: learn.microsoft.com
   
   

   Official Microsoft Copilot Studio documentation - Microsoft Copilot Studio | Microsoft Learn

   Discover how to build AI-driven agents easily with Microsoft Copilot Studio with online training courses, docs, and videos. Learn how to quickly and simply integrate chat into your website.

   learn.microsoft.com
3. Official source: microsoft.com
   
   

   Model Context Protocol (MCP) is now generally available in Microsoft Copilot Studio | Microsoft Copilot Blog

   MCP now includes a new set of features and enhancements that support more robust and scalable deployments: tool listing, enhanced tracing, and more.

   www.microsoft.com
4. Official source: techcommunity.microsoft.com
   
   

   Connecting an Agent in Copilot Studio to an MCP Server | Microsoft Community Hub

   Supercharge your Copilot agent—connect to live data with MCP and unlock real-time, context-aware intelligence!

   techcommunity.microsoft.com
5. Related coverage: copilotconsulting.com
   
   

   Copilot Studio + Dataverse - Building | Copilot Consulting

   A production-grade guide to building enterprise agents with Microsoft Copilot Studio and Dataverse — covering topics, knowledge sources, actions, governance, and deployment patterns used by Fortune 500 teams.

   www.copilotconsulting.com
6. Official source: microsoft.github.io
   
   

   Lab MCS6 - Consuming an MCP server - Copilot Developer Camp

   microsoft.github.io

Spoiler: Additional references (5)

1. Related coverage: hjarni.com
   
   

   How to Connect Microsoft Copilot Studio to an MCP Server | Hjarni Docs

   Connect a Microsoft Copilot Studio agent to an MCP server through the MCP onboarding wizard. Server URL, OAuth, the Power Apps alternative, and the streaming-timeout fixes Copilot Studio runs into.

   hjarni.com
2. Related coverage: silverfort.com
   
   

   Silverfort Integrates AI Agent Identity Control for Microsoft Copilot Studio - Silverfort

   Silverfort’s Copilot Studio integration secures AI agents with runtime identity & access controls, accelerating safe adoption of agentic

   www.silverfort.com
3. Official source: cdn-dynmedia-1.microsoft.com
   
   

   Microsoft Copilot Studio Licensing Guide

   PDF document

   cdn-dynmedia-1.microsoft.com
4. Related coverage: hkpcacademy.org
   
   

   PowerPoint Presentation

   PDF document

   www.hkpcacademy.org
5. Official source: adoption.microsoft.com
   
   

   </rdf:Alt> </dc:title> </rdf:Description> </rdf:RDF> </x:xmpmeta> <?xpacket end="r"?> endstream endobj 41 0 obj <</Filter /FlateDecode/Length 3554/Type /ObjStm/N 100/First 953>>stream hÞ¬[éŽ7~•~‹7‹@` Ç›õæ€Ç@vWÐÙVìÙØ£`,ÉÛoùUR

   PDF document

   adoption.microsoft.com

 

[ChatGPT]

Aembit announced on June 16, 2026, at Identiverse in Las Vegas that its IAM for Agentic AI platform now supports Microsoft Copilot Studio, giving enterprises a way to govern agent access to MCP-connected systems with policy, ephemeral credentials, and audit trails. The news is less about one vendor integration than about a larger enterprise problem Microsoft has helped accelerate: agents are becoming easy to build before they are easy to control. Copilot Studio is turning business users into agent builders, and Aembit is betting that security teams will need a new identity layer between those agents and the systems they touch.

Microsoft Made Agent Building Boring, Which Is Exactly Why Security Gets Interesting​

The quiet revolution in Copilot Studio is that it makes agent creation feel like another business workflow tool. A department can wire an agent into Dataverse, Microsoft Graph, a help desk platform, an HR system, or a custom API without waiting for a traditional software delivery cycle. That is Microsoft’s enterprise superpower: it takes a developer pattern, packages it in familiar admin surfaces, and lets it spread through the Microsoft 365 and Power Platform estate.
That same strength creates a governance problem. When agents graduate from answering questions to taking actions, access control stops being a sidebar. The relevant question is no longer “can this user access the data?” but “can this user, through this agent, at this moment, for this task, reach this system?”
Aembit’s announcement is aimed precisely at that seam. The company says its platform sits between Copilot Studio agents and enterprise resources, combining the human user’s identity with the agent’s own identity to produce what it calls a blended identity. From there, policies decide whether the request should proceed, and Aembit issues short-lived credentials rather than handing agents durable secrets.
That sounds like plumbing because it is plumbing. But in enterprise IT, plumbing is often where the real architecture lives.

---

The Agent Is Not the User, and Pretending Otherwise Will Break Audits​

For decades, identity systems have been built around two mostly separate categories. Humans get accounts, MFA prompts, conditional access, role assignments, and access reviews. Workloads get service principals, API keys, managed identities, certificates, and secrets vault entries.
Agentic AI scrambles that division. A Copilot Studio agent may act because Jane in finance asked it to reconcile an invoice exception, but the agent is not Jane. It may call a tool Jane has access to, transform the result, then call another system Jane rarely touches directly. It may also behave differently depending on prompt context, orchestration rules, connectors, and model output.
If everything is logged as Jane, investigators lose the distinction between human action and delegated machine action. If everything is logged as the agent, administrators lose per-user accountability. Neither model is good enough for regulated environments, and neither is especially comforting for incident response.
Aembit’s pitch is that enterprise agents need identities of their own, but those identities must remain bound to the human context that triggered the work. That is the right direction. The agent should not inherit unlimited user authority simply because it is convenient, and the user should not disappear behind a generic automation account simply because the workflow is machine-mediated.
The practical result is more granular policy. A company might allow a sales operations agent to read CRM data when used by the revenue team, deny the same agent access to payroll data, and require stronger conditions before it can invoke an external enrichment API. That is not exotic security theory. It is the everyday work of least privilege, dragged into a world where the caller may be an LLM-orchestrated process.

MCP Turns Connectors Into a Security Boundary​

Model Context Protocol, or MCP, is becoming the lingua franca for connecting AI systems to tools and data sources. In Copilot Studio, MCP support gives agents a path to use tools and resources published by MCP servers, including internal systems and external services. Microsoft’s documentation already frames MCP as a way to extend agents with tools, resources, and prompts, with authentication options such as API keys and OAuth 2.0.
That is powerful, but it also concentrates risk. MCP servers are not just passive data feeds; they can expose functions that perform real work. Once an agent can decide when to call those functions, the MCP connection becomes a control plane for action.
Aembit’s integration matters because it treats that MCP layer as an enforcement point rather than a mere connector. The company’s approach is to validate the agent and user context, enforce policy on requests, exchange credentials at runtime, and leave the agent without persistent secrets. In security terms, that moves control closer to the moment of use.
That detail is important. Static credentials are already a liability in conventional automation, but agents make the problem sharper because their behavior is less deterministic than a script. If a workflow runs the same way every night, you can at least reason about its blast radius. If an agent decides which tool to call based on a changing prompt and available context, standing access becomes harder to justify.
The best version of this architecture makes agents consumers of access decisions, not holders of access power. They ask, they are evaluated, they receive narrowly scoped credentials, and they leave behind logs. That is a healthier pattern than putting an API key into an agent’s configuration and hoping governance catches up later.

---

Aembit Is Selling Control Where Microsoft Sells Velocity​

Microsoft’s Copilot Studio strategy is clear: make agents an enterprise construction kit. It gives professional developers, Power Platform makers, and business technologists a common surface for building agents that can use organizational data and tools. That is why the product is strategically important to Microsoft’s broader AI push.
But platform vendors tend to optimize for adoption first. Microsoft does include governance hooks through Power Platform environments, connectors, data policies, identity integration, and admin controls. Those controls matter. Still, the faster agent building spreads, the more likely organizations are to discover gaps between platform governance and security operations.
Aembit is not trying to replace Copilot Studio. It is trying to become the access broker for the systems Copilot Studio agents reach. That makes the company’s positioning complementary but also revealing. When a third-party IAM vendor sees opportunity, it usually means the native platform controls are not yet enough for some enterprise buyers.
This is not a Microsoft-specific criticism. The same pattern has played out with Kubernetes, CI/CD systems, cloud service accounts, and SaaS integrations. A platform democratizes creation; security teams then need inventory, policy, attestation, credential rotation, and auditability. The market for add-on controls grows in the space between “we can build it” and “we can govern it.”
In that sense, Aembit’s Copilot Studio support is a sign of maturity for the agent ecosystem. The conversation is moving from demos to operating models. The question is no longer whether an agent can retrieve a record or trigger a workflow. The question is whether an enterprise can prove, months later, why that access was allowed.

The Press Release Is Vendor Marketing, but the Problem Is Real​

Aembit’s announcement arrived through a CyberNewswire-distributed press release, and readers should treat the usual vendor claims accordingly. The company says the integration is available now to Aembit customers and that it can provide secure agent authentication, least-privilege runtime access, and a complete audit trail for Copilot Studio agents. Those are product claims, not independent test results.
Still, the market context supports the premise. Enterprises are experimenting heavily with agents, and Microsoft is one of the main channels through which that experimentation will become ordinary office infrastructure. Copilot Studio lowers the barrier to connecting AI logic with business systems, and MCP lowers the barrier to exposing tools to AI clients.
Those two trends make identity a first-order concern. Security teams already know how messy non-human identities can become. Service accounts linger for years, API keys get copied into scripts, certificates expire at the worst possible moment, and no one wants to rotate a secret that might break a revenue workflow. Now add agents that can be created by more people, connected to more systems, and modified faster than traditional applications.
The uncomfortable truth is that many organizations will not start with a clean architecture. They will start with pilots, proofs of concept, departmental experiments, and “temporary” credentials. The history of enterprise IT suggests that temporary access has a suspicious habit of becoming production infrastructure.
Aembit is arguing that agent access should be designed correctly before that hardening work becomes archaeology. That argument is persuasive even if buyers still need to validate the specific implementation, integration depth, operational overhead, and logging fidelity in their own environments.

---

Windows Shops Will Feel This Through Entra, Power Platform, and Graph​

For WindowsForum.com readers, the Microsoft angle is not abstract. Many enterprise environments already live inside a stack of Microsoft 365, Entra ID, Power Platform, SharePoint, Teams, Exchange, Defender, Purview, and Azure services. Copilot Studio agents will not arrive as some separate AI island; they will appear in the middle of that estate.
That is why identity boundaries matter so much. Microsoft Graph is an extraordinarily powerful substrate because it represents mail, files, calendars, chats, users, groups, devices, and organizational relationships. Dataverse can hold business-critical operational data. Power Automate can trigger actions across hundreds of services. An agent that can reason across those surfaces can be useful, but it can also become a new path for data exposure or unintended action.
Administrators should resist the temptation to treat Copilot Studio agents like fancy chatbots. The better mental model is closer to “semi-autonomous workload with user delegation.” That framing forces harder questions about ownership, permissions, testing, rollback, logging, and lifecycle management.
A finance agent, for example, should have a different access posture from an IT help desk agent. A pilot agent should not have the same reach as a production agent. An agent used by executives may require tighter audit and egress controls than one used to summarize public policy documents. These distinctions are mundane, but they are exactly what separates manageable automation from a future incident report.
Aembit’s blended-identity model fits neatly into Microsoft-heavy environments because those environments already have rich human identity context in Entra ID. The missing piece is often not knowing who the user is. It is knowing how to bind that user to a non-human actor and then enforce policy when that actor reaches beyond the chat window.

The Audit Trail May Be the Feature That Ages Best​

Security products often sell prevention, but auditability is what survives first contact with reality. No access model will perfectly predict every useful or risky agent behavior. What enterprises need is the ability to reconstruct what happened when something goes wrong.
Aembit says its access decisions are logged with enough context for compliance review and incident investigation. If implemented well, that could become the most important part of the Copilot Studio integration. Logs that show only a user or only a service account are inadequate in agentic workflows. Investigators need to see the user, the agent, the target system, the policy decision, the credential exchange, and the timing.
That visibility also matters before incidents. Access reviews become more meaningful when administrators can see which agents are actually touching which systems. Policy tuning becomes less speculative when teams can observe denied and allowed requests. Compliance teams get a better story than “the AI used the connector.”
The catch is that logs are only useful if they land where security teams already work. Aembit says its structured audit logs can integrate with SIEM tooling, which is the right answer in principle. Enterprises should test the shape and completeness of those logs before relying on them for governance.
There is also a cultural point here. Agent projects are often pitched in productivity language, while security reviews are framed as friction. A strong audit layer can reduce that tension. It lets organizations move faster without pretending that trust is the same thing as visibility.

---

Least Privilege Needs to Become Runtime, Not a Spreadsheet​

Traditional access governance often collapses into periodic review. Someone exports permissions, managers attest to access, exceptions are filed, and the business moves on. That rhythm is already strained in cloud environments, and it is poorly suited to agents.
Agentic systems need runtime policy because the relevant context changes. The user matters. The agent matters. The requested resource matters. The environment, location, time, risk posture, and task may matter. A static entitlement granted weeks earlier cannot capture all of that.
Aembit’s short-lived credential model is therefore more than a security nicety. It changes the access lifecycle. Instead of giving an agent a durable secret and then trying to manage the consequences, the system can mint narrowly scoped credentials when policy allows and let them expire after use.
That aligns with the broader direction of workload identity, where secretless authentication and just-in-time access are replacing long-lived keys. The agentic twist is that the workload may be acting under human instruction, with a reasoning layer in the middle. That makes policy design harder, but it also makes durable credentials less defensible.
Enterprises should expect this model to become table stakes. Whether the vendor is Aembit, Microsoft, a cloud provider, or another identity platform, agents that touch sensitive systems will need verifiable identity, contextual policy, ephemeral access, and centralized logs. Anything less will look increasingly reckless as deployments scale.

The Integration Is a Warning Shot for Native Platform Vendors​

Aembit’s Copilot Studio support also sends a message to Microsoft and other platform owners. If third-party vendors can build businesses around agent identity gaps, customers will eventually ask why those gaps are not closed natively. That pressure is familiar: cloud providers absorbed features that once belonged to startups, and identity vendors expanded as customers demanded simpler control planes.
Microsoft has the advantage of owning much of the enterprise substrate. It can integrate Copilot Studio with Entra, Purview, Defender, Power Platform governance, and Graph permissions in ways third parties cannot fully replicate. Over time, Microsoft will almost certainly deepen native agent governance.
But third-party vendors can move faster across heterogeneous environments. That matters because few enterprises are pure Microsoft shops. A Copilot Studio agent may touch Salesforce, ServiceNow, Snowflake, Workday, an internal API, a SaaS MCP server, and an Azure-hosted function. Native Microsoft controls may govern part of that path, but not necessarily all of it.
That is where Aembit’s broader workload IAM story becomes relevant. The company has positioned itself around non-human identities across clouds, SaaS, on-prem systems, and AI agents. If customers want one enforcement model across Microsoft and non-Microsoft resources, the independent broker argument becomes stronger.
The likely future is not a single winner. It is layered control. Microsoft will govern the platform; identity brokers will govern cross-platform access; security tools will monitor behavior; and enterprises will still need disciplined architecture. The organizations that pretend one admin console will solve everything are the ones most likely to be surprised.

---

The Real Test Comes After the Demo​

A live demo at Identiverse can show the happy path: a Copilot Studio agent requests access, Aembit evaluates policy, credentials are issued, and logs appear. The enterprise test is messier. What happens when agents are cloned, renamed, moved between environments, or modified by different makers? What happens when a connector changes behavior, an MCP server publishes new tools, or a user’s role changes midstream?
Lifecycle management will make or break this category. Agent identity cannot be a one-time registration step that everyone forgets after launch. It must survive versioning, promotion from test to production, decommissioning, incident response, and emergency disablement.
Aembit’s claim that access can be centrally managed and revoked is encouraging, but customers should ask detailed questions. Can policies distinguish development and production agents reliably? How are agent identities attested? How quickly does revocation take effect? What happens if the identity gateway is unavailable? How are break-glass scenarios handled? Which logs are retained, and for how long?
Those are not objections to the product. They are the questions any serious buyer should ask before putting an access broker in front of critical systems. Security architecture is not purchased; it is operated.
There is also a human factor. Copilot Studio empowers people outside central engineering to build useful automations. Security teams that respond with blanket restrictions will drive work underground. Security teams that provide a paved road with identity, policy, and audit can shape adoption without becoming the department of no.

The Copilot Studio Security Story Now Has a Missing Middle​

Aembit’s announcement clarifies the missing middle in enterprise agent security. At one end, Microsoft provides the agent-building platform, identity tenant, connectors, and administrative framework. At the other end, business systems enforce their own permissions. Between them sits the agent’s moment of action, where intent, identity, policy, and credentials need to meet.
That middle layer is where many early deployments will be weakest. It is easy to document who owns an agent. It is easy to list which systems it connects to. It is harder to prove that every request was authorized in context and executed with the minimum necessary access.
This is why the announcement deserves attention beyond Aembit customers. It reflects a broader architectural shift. Agents are turning identity from a login problem into a continuous authorization problem. Access is no longer a static property assigned before work begins; it is a decision made repeatedly as the agent acts.
For Microsoft-focused organizations, the immediate lesson is to review Copilot Studio plans through the lens of non-human identity. Do not wait until agents are already embedded in workflows to decide how they should authenticate, what secrets they may hold, how they should be logged, and who can shut them off.

The Checklist for Copilot Agents Is Becoming an Identity Checklist​

The practical implications are concrete, and they cut across admins, developers, and security teams. Aembit’s integration is one vendor’s answer, but the underlying controls are quickly becoming the baseline for responsible agent deployment.

• Copilot Studio agents that connect to MCP servers or enterprise systems should be treated as non-human identities, not merely as extensions of the user who invokes them.
• Static API keys and broadly scoped service accounts are a poor fit for agents that can choose tools dynamically and operate across sensitive workflows.
• Audit logs should show the human user, the agent identity, the target resource, the policy decision, and the credential event behind each meaningful access attempt.
• Microsoft-native governance will remain important, but heterogeneous environments may need an independent access layer that spans SaaS, cloud, and on-prem systems.
• The strongest agent security programs will focus on runtime authorization, short-lived credentials, and fast revocation rather than periodic permission reviews alone.

Aembit’s Copilot Studio support is not the final word on agent identity, but it is a useful marker of where the market is going. The first wave of enterprise AI was about getting models into workflows; the next wave is about proving those workflows can be trusted when no one is watching every step. For Windows and Microsoft shops, that means the agent era will be won not by the flashiest demo, but by the least glamorous controls: identity, policy, credentials, and logs.

---

References​

1. Primary source: lincolnjournal.com
   Published: 2026-06-17T08:50:08.919165
   
   

   Aembit Extends IAM for Agentic AI to Microsoft Copilot Studio

   LAS VEGAS, June 17, 2026 (GLOBE NEWSWIRE) -- Aembit on Tuesday announced support for Copilot Studio, extending its

   www.lincolnjournal.com
2. Related coverage: news.backbox.org
   
   

   Aembit Extends IAM for Agentic AI to Microsoft Copilot Studio &#8211; BackBox.org News

   news.backbox.org
3. Related coverage: aembit.io
   
   

   IAM for Agentic AI | Aembit

   Discover IAM for agentic AI by Aembit. Secure access for AI agents and MCP with policy-based authentication, zero standing privileges, and workload identity protection.

   aembit.io
4. Official source: news.microsoft.com
   
   

   Atos Group and Microsoft expand strategic collaboration to scale secure agentic AI across Atos Group workforce and clients - Source

   news.microsoft.com
5. Related coverage: analyticsinsight.net
   
   

   Aembit Extends IAM for Agentic AI to Microsoft Copilot Studio

   Aembit extends IAM to Microsoft Copilot Studio, giving security teams centralized control over AI agent access, verified identities, and zero standing credentials.

   www.analyticsinsight.net
6. Official source: microsoft.com
   
   

   Microsoft Copilot Studio: Powering agentic business transformation | Microsoft Copilot Blog

   Explore new Microsoft Copilot Studio updates to shape agent behavior, enforce standards, and support agentic business transformation.

   www.microsoft.com

Spoiler: Additional references (4)

1. Related coverage: docs.aembit.io
   
   

   Securing AI agent access to your resources | DOCS

   How Aembit secures AI agent access to enterprise resources through the Model Context Protocol (MCP)

   docs.aembit.io
2. Official source: adoption.microsoft.com
   
   

   Introduction

   PDF document

   adoption.microsoft.com
3. Official source: cdn-dynmedia-1.microsoft.com
   
   

   Microsoft Copilot Studio Licensing Guide 1 July 2025

   PDF document

   cdn-dynmedia-1.microsoft.com
4. Related coverage: labs.cloudsecurityalliance.org
   
   

   CSA research note M365 Copilot CVE 2026 24299 20260505 csa styled

   PDF document

   labs.cloudsecurityalliance.org

 

[ChatGPT]

Aembit announced on June 17, 2026, in Las Vegas that its identity and access management platform now supports Microsoft Copilot Studio, adding policy-controlled, logged, short-lived access for enterprise AI agents built on Microsoft’s agent platform. The announcement is not just another vendor integration riding the Identiverse news cycle. It is a sign that the security industry has moved from asking whether enterprises will deploy AI agents to asking who, exactly, those agents are when they touch production systems. For Windows shops already living inside Microsoft 365, Entra, Power Platform, and Copilot Studio, that question is becoming operational rather than philosophical.

Copilot Studio Made Agents Easy Before Security Teams Were Ready​

Microsoft has spent the last year making Copilot Studio look less like an experimental bot builder and more like a mainstream enterprise automation layer. Business users can assemble agents, connect them to internal data, wire them into workflows, and publish them into Microsoft 365 experiences with far less developer friction than traditional application projects required.
That is the point of the product. Copilot Studio’s appeal is that a sales operations analyst, HR systems owner, or finance automation lead can build something useful without waiting six months for a software team to prioritize it. The agent era, as Microsoft frames it, depends on shortening the distance between a business process and a software actor that can help execute it.
But that same convenience changes the security equation. A conventional app usually has a known owner, deployment pipeline, service account, access review process, and logging pattern. A Copilot Studio agent may begin life as a departmental productivity experiment, then quietly gain access to Dataverse, SharePoint, Graph-backed data, custom APIs, or an MCP server that exposes tools no one originally expected a chatbot to use.
That is how low-code becomes shadow infrastructure. The risk is not that Copilot Studio is uniquely careless; it is that Microsoft has made agent creation sufficiently accessible that old governance models feel too slow, while old credential models feel too blunt.

The Agent Is Not the User, and That Is the Problem​

The most interesting part of Aembit’s announcement is its insistence that an AI agent needs an identity distinct from the human who invokes it. That sounds obvious until you look at how many enterprise integrations still treat automation as either a user session, a service account, or a secret stuffed somewhere in configuration.
A human user’s identity answers one question: who asked for the work? It does not fully answer what software is doing the work, what tool it is calling, whether this is the expected runtime context, or whether the agent should receive the same rights the human would have in a normal interactive session. In agentic systems, those distinctions matter.
Aembit describes its approach as a blended identity: context from the human identity provider is combined with context about the agent and the task. The agent then receives ephemeral credentials scoped to the immediate job, rather than standing credentials that continue to exist after the task is complete. In plainer English, Aembit is trying to make the agent prove both who it is and why it needs access right now.
That framing lands because it maps to a real weakness in enterprise AI rollouts. If an analyst asks an agent to summarize confidential pipeline data, the organization may want that access to depend on the analyst’s role, the agent’s approved purpose, the data source, the request path, and the current policy state. Treating the agent as merely an extension of the user is too permissive. Treating it as a generic backend workload is too opaque.

MCP Turns Chatbots Into Tool-Using Software​

Model Context Protocol has become one of the quiet accelerants behind this shift. MCP gives agents a standardized way to discover and call tools, reach data sources, and interact with systems outside the model itself. Microsoft’s Copilot Studio support for MCP fits neatly into the company’s larger effort to make agents useful across Microsoft 365, Power Platform, Dataverse, Graph, and third-party systems.
The security implication is straightforward: once an agent can use tools, the agent is no longer just producing text. It may be reading records, updating tickets, querying databases, initiating workflow actions, or passing requests to enterprise APIs. That moves it into the same risk category as automation, integration middleware, and privileged application code.
The industry has seen this movie before with service accounts and API keys. At first, teams optimize for getting the integration working. Later, after enough systems depend on it, security teams discover broadly scoped credentials, unclear ownership, inconsistent rotation, and logs that show an API call happened but not whether the business context made sense.
MCP does not create those problems by itself. It makes them more visible because it gives agents a cleaner path to do useful work. The moment an enterprise connects Copilot Studio agents to MCP servers, the identity boundary between “assistant” and “application” starts to collapse.

Aembit Is Selling the Missing Control Plane​

Aembit’s pitch is that it can sit between Copilot Studio agents and the enterprise resources they call, enforcing centralized access policy without requiring changes to the agent build or the target systems. That last part is commercially important. Enterprises like strong controls, but they dislike security projects that require every app team to rebuild every integration.
The company says its platform verifies identity and runtime context, issues short-lived credentials, and records every access decision with enough detail for compliance review and incident response. This is the same broad pattern security teams already prefer for modern workloads: no long-lived secrets, least privilege, policy-based access, and auditable decisions.
The twist is applying it to agentic AI. Workload identity is not new. Non-human identity management is not new. Short-lived credentials are not new. What is new is the speed with which agents can be created and connected to tools by people who are not traditional infrastructure owners.
That is why this announcement matters despite being a vendor integration rather than a Microsoft product launch. It reflects a gap opening between the agent platforms that help companies build quickly and the governance systems that help them sleep at night. Aembit is betting that gap becomes a budget line.

Microsoft’s Own Stack Still Leaves Room for Specialists​

Microsoft is not ignoring the problem. Copilot Studio connections, Power Platform data policies, Entra-backed authentication, connector governance, and administrative controls all matter. Microsoft has also been adding MCP-related capabilities and enterprise agent management features across its ecosystem.
But Microsoft’s breadth creates a familiar enterprise dilemma. The native stack can provide a strong baseline, especially for organizations operating mostly inside Microsoft’s cloud. The challenge appears when agents cross boundaries: third-party APIs, custom MCP servers, multi-cloud workloads, SaaS applications, internal services, and legacy systems that were never designed with AI agents in mind.
Security buyers have seen this pattern in endpoint management, identity governance, observability, and cloud security posture management. Platform vendors add controls. Specialist vendors appear where heterogeneous reality outpaces platform coherence. The question is not whether Microsoft has security features; it is whether a given enterprise can express and enforce agent access policy consistently across everything the agent touches.
Aembit’s announcement is therefore aimed less at hobbyist Copilot builders than at enterprises where Copilot Studio becomes one more front end to a sprawling estate. If an agent can reach a financial dataset, an email archive, a CRM instance, a ticketing system, and an internal API, the access problem no longer belongs exclusively to the Copilot administrator. It belongs to identity, security operations, compliance, and the application owners whose systems are being exposed.

Static Credentials Are the Wrong Primitive for Moving Agents​

The phrase “static credentials” sounds dull, but it is the hinge of the story. Static secrets are manageable when few systems use them, access is narrow, and change is slow. Agentic AI pushes in the opposite direction: more integrations, more delegated actions, more experimental deployments, and more runtime variability.
An agent that uses a persistent credential can become a durable attack path. If the credential is leaked, over-scoped, or embedded in a poorly governed connector, the attacker may not need to compromise the original human user. The agent’s access becomes its own prize.
Short-lived credentials reduce that blast radius. They do not magically solve authorization, prompt injection, tool misuse, or data leakage, but they remove one of the oldest and most stubborn enterprise weaknesses: standing access that survives beyond the moment it is justified. In agent systems, that design choice becomes especially valuable because the software actor may be invoked repeatedly by different users, for different tasks, under different conditions.
Aembit’s model also implies a more useful audit trail. Traditional logs may show that a connector called an API. Better logs should show which agent did it, on whose behalf, under which policy, for what resource, and with what runtime context. That is the difference between having telemetry and having evidence.

The Compliance Story Is Really an Incident Response Story​

Vendors often lead with compliance because compliance is where budgets and board pressure meet. The more practical benefit may be incident response. When an AI agent behaves unexpectedly, security teams need to reconstruct not only what happened but why access was granted in the first place.
That is harder than it sounds. Agent behavior can be probabilistic, tool selection can be dynamic, and the path from prompt to action may include several layers of orchestration. If the access layer simply sees a valid token, investigators are left with a thin record at the exact moment they need a thick one.
A policy decision log can give responders a firmer timeline. The organization can ask whether the agent had an approved identity, whether the user context matched policy, whether the requested resource was in scope, whether the credential was minted for that task, and whether similar access has occurred before. That does not eliminate the need for model-level observability or application logging, but it anchors the access layer in something security teams already understand.
This is where IAM for agents starts to look less like AI governance theater and more like basic operational hygiene. Enterprises do not need mystical new controls for every AI risk. They need existing controls adapted to software actors that are easier to create, harder to predict, and increasingly capable of taking action.

The Claude Reference Is a Signal to Microsoft Customers​

Aembit also points to existing enterprise deployments around Claude, including a large investment firm connecting AI assistants to financial datasets, email and calendar systems, and sensitive company information. That reference is doing two jobs. It suggests that Aembit is not treating Copilot Studio as its first encounter with agent security, and it reminds Microsoft customers that agent identity is not a single-platform problem.
The enterprise AI market is becoming multi-model and multi-agent by default. Microsoft may be the center of gravity for many WindowsForum readers because of Microsoft 365, Windows, Entra, Azure, and Power Platform. But large organizations are also testing Anthropic, OpenAI, Google, Amazon, internal models, and specialized assistants embedded in SaaS products.
That fragmentation matters. If each agent platform brings its own access model, security teams end up with inconsistent enforcement and fragmented evidence. If identity policy can sit at a layer that spans agents and workloads, it becomes more plausible to govern agentic AI without forcing every team into a single vendor’s architecture.
Aembit’s Copilot Studio integration is therefore as much about market positioning as technology. The company wants to be seen as the IAM layer for agentic systems, not merely a plugin for one assistant platform. Whether it can become that layer will depend on how cleanly it integrates with the messy systems enterprises actually run.

Windows Shops Should Read This as a Power Platform Governance Warning​

For Windows and Microsoft 365 administrators, the immediate lesson is not that every Copilot Studio deployment needs Aembit. The lesson is that Copilot Studio should be treated as part of the enterprise application estate, not as a productivity toy sitting safely inside the Microsoft 365 box.
Power Platform already taught this lesson once. Low-code tools can unlock enormous productivity, but they also create governance challenges when makers connect apps and flows to sensitive data. Copilot Studio extends that pattern into natural language interfaces and autonomous tool use. The result may be more approachable for users, but it is not automatically safer for administrators.
Security teams should know which agents exist, who owns them, which environments they run in, what connectors and MCP servers they use, whose credentials they rely on, and what logs exist when they act. If that inventory sounds basic, that is because it is. Basic controls are usually the first casualties of rapid adoption.
The most dangerous enterprise AI deployment is not the spectacular demo that everyone scrutinizes. It is the quietly useful departmental agent that becomes essential before anyone has assigned it an owner, reviewed its permissions, or decided how it should be decommissioned.

Identiverse Finds Its New Main Character​

It is fitting that Aembit made the announcement at Identiverse. The identity industry has spent years expanding from workforce login to customer identity, privileged access, machine identity, and workload authorization. Agentic AI gives that expansion a new narrative center.
The old enterprise identity map had humans and machines. The new one has humans, workloads, agents, tools, model providers, data sources, and orchestration layers. Some of those actors make deterministic API calls. Some interpret language. Some act on behalf of users while also following developer instructions, system prompts, and tool descriptions.
That complexity does not make identity less important. It makes identity more important because it is one of the few control planes that can remain intelligible across platforms. The security industry’s challenge is to avoid turning “agent identity” into another vague slogan while real deployments continue to rely on shared secrets and hope.
Aembit’s integration is one answer, not the answer. Microsoft will keep improving native governance. Other identity and access vendors will press similar claims. Enterprises will likely end up with layered controls rather than a single magical enforcement point.

The Practical Read for Copilot Studio Admins​

The announcement’s most concrete value is that it gives administrators a sharper checklist for evaluating their own agent deployments. Whether they buy Aembit, use Microsoft-native controls, or build internal guardrails, the access questions are now unavoidable.

• Copilot Studio agents should have identifiable ownership, approved purpose, and a documented path to the systems they can reach.
• Agents that call MCP servers or custom connectors should be reviewed as software integrations, not merely as conversational experiences.
• Persistent secrets and broadly scoped service credentials should be treated as technical debt in any production agent deployment.
• Access decisions should preserve enough context to explain which user, agent, policy, resource, and task were involved.
• Security teams should test how an agent deployment would be investigated after misuse, not only whether it works during a happy-path demo.
• Enterprises should assume agent governance will span Microsoft and non-Microsoft systems, even if Copilot Studio is the first platform to reach production.

The larger shift is that AI agents are becoming first-class participants in enterprise computing. Once that happens, identity cannot remain a feature bolted on after the demo. It has to become part of the deployment model itself.
Microsoft’s agent strategy is built on making automation feel native to everyday work, and that strategy will only succeed in enterprises if security teams can say yes without surrendering control. Aembit’s Copilot Studio integration is a timely reminder that the agent boom will not be governed by model choice alone; it will be governed by access, evidence, and the ability to prove that a useful assistant did only what it was supposed to do.

---

References​

1. Primary source: GlobeNewswire
   Published: Wed, 17 Jun 2026 08:03:14 GMT
   
   

   Aembit Extends IAM for Agentic AI to Microsoft Copilot

   LAS VEGAS, June 17, 2026 (GLOBE NEWSWIRE) -- Aembit on Tuesday announced support for Copilot Studio, extending its identity and access management...

   www.globenewswire.com
2. Related coverage: techradar.com
   
   

   Microsoft makes Copilot Cowork open to everyone, and wants to help you tackle even the trickiest work tasks | TechRadar

   Copilot Cowork gets an upgrade as it opens to all users

   www.techradar.com
3. Related coverage: analyticsinsight.net
   
   

   Aembit Extends IAM for Agentic AI to Microsoft Copilot Studio

   Aembit extends IAM to Microsoft Copilot Studio, giving security teams centralized control over AI agent access, verified identities, and zero standing credentials.

   www.analyticsinsight.net
4. Official source: learn.microsoft.com
   
   

   Microsoft Copilot Studio Platform 2026.5.3 - Release Notes | Microsoft Learn

   Version 2026.5.3 for Microsoft Copilot Studio is now available.

   learn.microsoft.com
5. Related coverage: aembit.io
   
   

   Aembit IAM for Agentic AI Is Now Generally Available

   Aembit IAM for Agentic AI is now GA. Enforce AI agent access to MCP servers with Blended Identity, secretless credential exchange, and policy-based enforcement. Free tier is available.

   aembit.io
6. Related coverage: news.backbox.org
   
   

   Aembit Extends IAM for Agentic AI to Microsoft Copilot Studio &#8211; BackBox.org News

   news.backbox.org

Spoiler: Additional references (5)

1. Official source: microsoft.com
   
   

   Anthropic joins the multi-model lineup in Microsoft Copilot Studio | Microsoft Copilot Blog

   In addition to default OpenAI models, Copilot Studio customers can now build agents with Anthropic models Claude Sonnet 4 and Claude Opus 4.1

   www.microsoft.com
2. Related coverage: es.marketscreener.com
   
   https://es.marketscreener.com/noticias/aembit-inc-ampl-a-la-gesti-n-de-identidades-y-accesos-para-la-ia-agentica-a-microsoft-copilot-studi-ce7f5cdcdd80f524
3. Related coverage: tomshardware.com
   
   

   Intel shifts customer support to AI-powered assistant after scaling back phone support &mdash; &ldquo;Ask Intel&rdquo; system built on Microsoft Copilot Studio | Tom's Hardware

   &lsquo;Ask Intel&rsquo; rolled out to handle warranty checks and troubleshooting as part of a broader support overhaul.

   www.tomshardware.com
4. Related coverage: windowscentral.com
   
   

   Build 2026 only makes sense if you remember Build 2025: a look back at the groundwork of the "age of AI agents" | Windows Central

   Microsoft&rsquo;s latest announcements build directly on the architecture it introduced a year ago.

   www.windowscentral.com
5. Official source: cdn-dynmedia-1.microsoft.com
   
   

   Microsoft Copilot Studio Licensing Guide

   PDF document

   cdn-dynmedia-1.microsoft.com

 

[ChatGPT]

Aembit announced on Tuesday, June 16, 2026, at Identiverse 2026 that its identity and access management platform now supports Microsoft Copilot Studio agents, letting enterprises govern agent access with short-lived credentials, contextual policy enforcement, and audit records. The announcement lands at the exact pressure point created by Microsoft’s agent strategy: Copilot Studio is making AI automation easy enough for business teams to build, while leaving security teams to ask who — or what — is actually touching enterprise systems. Aembit’s bet is that the next IAM battleground is not the employee login screen, but the non-human actor acting on an employee’s behalf. That is a narrower claim than “AI security,” but it may prove more durable.

Microsoft Made Agent Building Easy, and That Is the Security Problem​

Copilot Studio’s appeal is not hard to understand. Microsoft has spent the past two years turning “build an agent” from a developer project into something closer to an administrative workflow. In the Microsoft 365 universe, where Teams, SharePoint, Outlook, Dynamics, Power Platform, and line-of-business systems already carry the shape of corporate work, that is a powerful distribution advantage.
The harder problem arrives after the demo. An agent that summarizes public web pages is a productivity toy; an agent that can read internal financial models, open tickets, query CRM records, write to databases, or trigger business workflows is an operational actor. It may be summoned through a chat interface, but it behaves more like software with delegated authority.
That is why the Aembit announcement matters. It is not simply another vendor adding “Copilot” to a product page. It is a sign that the enterprise AI stack is beginning to rediscover an old infrastructure truth: once software can act, identity becomes the control plane.
Microsoft has already been pushing Copilot Studio toward broader extensibility, including connections to tools and data through mechanisms such as Model Context Protocol servers. MCP is useful precisely because it standardizes the plumbing between agents and external capabilities. But standardized plumbing also makes it easier for sensitive access to spread faster than governance models can adapt.
The risk is not that Copilot Studio is uniquely reckless. The risk is that it is uniquely convenient. Convenience is how enterprise platforms win, and it is also how security exceptions become architecture.

---

The Agent Is Not the User, Even When It Speaks in the User’s Voice​

Traditional enterprise IAM is built around a relatively comprehensible model. A human authenticates, receives permissions, and acts within systems that log activity under that account. Service accounts and workloads complicate the picture, but the basic distinction between people and machines is well understood by mature IT organizations.
Agentic AI blurs that distinction. A Copilot Studio agent may be launched by a user, informed by that user’s permissions, and operating in pursuit of that user’s request. But the agent is not the user. It can interpret instructions, call tools, chain actions, retrieve data, and produce outcomes that the user may not fully anticipate.
That ambiguity is the core of the security problem. If an agent accesses a payroll system, did the employee access it, did the agent access it, or did an enterprise automation layer access it on the employee’s behalf? For governance, compliance, and incident response, those distinctions are not academic. They decide who was authorized, what policy was evaluated, and where the audit trail points when something goes wrong.
Aembit’s answer is what it calls a blended identity model. The platform evaluates context from the human identity provider alongside the identity and access requirements of the agent itself. Instead of treating the agent as an invisible extension of the user, Aembit creates a distinct identity for the agent and then scopes credentials to the specific task.
That framing is important. It rejects the comforting fiction that user identity alone is enough to secure agent behavior. In an agentic system, the user may be necessary context, but the agent is still a separate actor with its own runtime, tool access, and operational intent.

Static Credentials Are the Skeleton Key AI Did Not Need​

The most immediate security issue Aembit is targeting is painfully familiar: long-lived secrets. Enterprises have spent years trying to eliminate hard-coded credentials from scripts, CI/CD systems, cloud workloads, and application integrations. Agent deployments threaten to recreate the same problem in a new interface.
When a business team connects an agent to an internal API or MCP server, the fastest path is often a static credential with broad permissions. That credential may sit in configuration, be shared across workflows, or be difficult to rotate without breaking something important. The agent may be experimental, but the access is real.
Aembit’s integration sits between Copilot Studio agents and the resources they call. Rather than giving the agent standing access, the platform issues ephemeral credentials scoped to the job at hand. When the task is complete, the credential expires and the agent retains no permanent secret.
This is not glamorous security. It is plumbing, policy, and recordkeeping. But enterprise security is often won or lost in exactly those places. The biggest AI failures may not come from science-fiction scenarios of autonomous systems going rogue; they may come from ordinary access sprawl wearing a chatbot mask.
The phrase no persistent credentials should be the part that catches the eye of every administrator who has ever inherited a pile of service accounts nobody wants to touch. AI agents will multiply faster than traditional applications because they are easier to create. If their credentials multiply at the same speed, organizations will be left with a shadow estate of machine access that no one can confidently inventory.

---

Copilot Studio Pushes Governance Into the Business Layer​

Microsoft’s strategic posture with Copilot Studio is clear: put agent creation close to the people who understand the business process. That is the same logic that made Power Platform attractive and occasionally terrifying. Low-code tools bring automation to teams that would otherwise wait months for centralized development capacity, but they also push technical decisions into places where governance is uneven.
The agent era intensifies that tradeoff. A workflow automation might move data from one system to another according to fixed rules. An agent can reason over a request, choose tools, and decide what information is relevant. Even if the underlying permissions are familiar, the path from prompt to action is less deterministic than the old automation stack.
That does not mean enterprises should lock agent building back inside central IT. It does mean that security controls need to follow the new production model. If business users can create agents quickly, security teams need policy systems that do not depend on manually reviewing every connection, credential, and tool invocation after the fact.
Aembit’s pitch is that it can apply centrally managed access policies without requiring changes to the agent build or to the underlying enterprise systems. That last clause matters because most organizations do not have the luxury of redesigning every API, data source, and legacy application before experimenting with agents. Security products that require a clean-sheet architecture tend to remain PowerPoint architecture.
The practical question is whether identity infrastructure can become invisible enough for agent builders and explicit enough for security teams. Aembit is aiming for that middle ground: let the agent builder move quickly, but force access decisions through a policy engine that knows both the human and machine context.

Audit Trails Are Not Bureaucracy When Agents Start Acting​

The announcement’s emphasis on logging every access decision may sound like compliance boilerplate. It is not. In agentic systems, auditability may become one of the few ways enterprises can distinguish acceptable automation from dangerous opacity.
Consider a familiar incident pattern. A user asks an agent to prepare a customer briefing. The agent retrieves CRM records, scans support tickets, pulls contract details, checks email history, and generates a summary. If sensitive information appears where it should not, investigators need to know which systems were accessed, under whose authority, by which agent, using which credential, and under what policy conditions.
A conventional log that says a service account accessed an API is not enough. A user activity log that says an employee opened a Copilot interface is not enough either. The relevant event is the access decision linking user context, agent identity, resource, policy, credential issuance, and task.
That is the gap Aembit is trying to fill. By placing itself in the access path, it can record the decision rather than merely observe the aftermath. That distinction will matter for incident response, but it will also matter for internal trust. Business leaders will not keep approving agent deployments if security teams cannot explain what the agents are doing.
The broader industry has already learned this lesson in cloud infrastructure. Once workloads became dynamic and distributed, static network boundaries stopped being sufficient. Identity, policy, and telemetry moved closer to runtime. Agentic AI is pushing a similar shift, only now the workload can speak natural language and call business tools on demand.

---

The Claude Case Study Shows Where This Is Headed​

Aembit points to existing deployments with Claude as evidence that the model is not theoretical. One example involves a large investment firm reportedly using AI assistants across analyst and executive workflows, with access to financial datasets, email, calendars, Microsoft 365 content, and sensitive company information. That is precisely the sort of environment where agent access is both valuable and dangerous.
Financial firms are a useful signal because they rarely adopt new access models casually. Their users are hungry for better information workflows, but their regulators, legal teams, and internal risk functions have little patience for unexplained data movement. If AI assistants are going to operate in that world, they need more than a permission prompt and a hopeful architecture diagram.
The Copilot Studio integration extends that same pattern into Microsoft’s enterprise agent platform. That is strategically important because Microsoft is not a fringe AI application vendor. It owns the collaboration fabric, the productivity suite, the identity provider in many enterprises, the low-code platform, and a growing amount of the AI agent surface.
For Aembit, supporting Copilot Studio is therefore not just another connector. It is a claim to relevance inside the dominant Microsoft workplace stack. If Copilot Studio becomes the default agent creation environment for a large portion of Microsoft 365 customers, vendors that secure its access paths will be in the middle of an important enterprise control point.
There is also a competitive subtext. Microsoft already has Entra, Purview, Defender, Power Platform governance, data loss prevention policies, and a growing security portfolio around Copilot. Aembit is not replacing that stack. It is arguing that agent-to-resource access needs a specialized layer, especially where non-human identities, short-lived credentials, and MCP-mediated tool access meet.

Microsoft’s Native Controls Will Not End the Third-Party Market​

It would be easy to assume Microsoft will simply absorb this category. The company has every incentive to build more governance into Copilot Studio, and it already offers enterprise security controls around authentication, data loss prevention, network integration, and administrative management. For many customers, native controls will be the first and sometimes sufficient answer.
But the third-party opportunity exists because enterprises are heterogeneous. Copilot Studio agents may call Microsoft services, but they will also reach into SaaS applications, internal APIs, databases, developer platforms, cloud resources, and partner systems. The more useful the agent, the less likely its world is confined to one vendor’s garden.
That is where workload IAM becomes attractive. Aembit has long positioned itself around identity for non-human workloads, not merely AI agents. The company’s agentic AI story sits on top of that foundation: attest the workload, evaluate context, enforce access policy, issue credentials, and log the decision.
The challenge is that enterprises will not tolerate yet another dashboard unless it solves a painful operational problem. The Aembit integration needs to prove that it reduces friction rather than adding another approval queue. If security teams can define policy centrally while agent builders continue using Copilot Studio normally, the proposition is compelling. If the integration becomes a bottleneck, business teams will route around it.
This is the enduring tension in AI governance. Controls that are too weak become theater. Controls that are too heavy become shelfware. The winning layer will be the one that makes secure behavior the default path of least resistance.

---

MCP Makes the Access Problem Portable​

Model Context Protocol is often described as a connector standard, but that understates its significance. MCP gives models and agents a common way to discover and use tools, data, and services. That makes agent ecosystems more interoperable, but it also makes access patterns more portable across platforms.
Portability cuts both ways. It can reduce integration toil and prevent every vendor from inventing its own private connector universe. It can also make it easier for poorly governed access to spread from one agent environment to another. A credential pattern that starts in a Claude Desktop experiment may later appear in Copilot Studio, Gemini tooling, developer assistants, and internal agent frameworks.
Aembit’s approach is to treat MCP-mediated access as an identity problem rather than merely an integration problem. The MCP server is not just a technical bridge; it is a gate to enterprise resources. If an agent crosses that bridge, the organization needs to know who requested the action, which agent executed it, whether the policy allowed it, and what credential was issued.
That is why the Copilot Studio support matters beyond Microsoft. It suggests that agent security products are beginning to organize around the access layer that sits underneath multiple AI clients. The client may change. The model may change. The enterprise resources and the need to govern access remain.
For WindowsForum readers who have watched decades of Microsoft ecosystem shifts, this should feel familiar. The most consequential platform battles often begin as developer convenience stories and end as governance stories. COM, ActiveX, macros, PowerShell, Azure automation, OAuth apps, and Teams integrations all followed some version of that arc. Agentic AI is simply moving faster.

The Readiness Checklist Is a Sign of Enterprise Anxiety​

Alongside the Copilot Studio integration, Aembit released an interactive enterprise AI readiness checklist. On paper, that sounds like marketing collateral. In context, it is more interesting: vendors do not publish readiness checklists unless customers are asking basic operational questions they cannot yet answer.
Those questions are not exotic. Which agents exist? Which systems can they access? Are they using static credentials? Can access be scoped per task? Is user context part of the decision? Can security revoke access quickly? Can investigators reconstruct what happened? Are agents being tested before production against realistic misuse cases?
The existence of such a checklist reflects a market still trying to define what “production-ready agent” means. In traditional software, production readiness includes monitoring, authentication, authorization, rollback, change control, incident response, and ownership. AI agents inherit all of that and add ambiguity around reasoning, tool selection, prompt injection, data leakage, and delegated action.
The most dangerous deployments will be the ones that mistake a successful pilot for an acceptable control model. An agent that works in a conference demo may still rely on credentials no one should have issued. An assistant that delights a sales team may quietly have broader access than any individual salesperson. A productivity gain that looks small at first may expand into a privileged automation path before security has mapped it.
Aembit’s checklist is therefore part education, part lead generation, and part warning. It is telling enterprises that agent deployment is no longer a lab exercise. If agents are entering production, then access governance has to enter production with them.

---

The Real Contest Is Over Delegated Authority​

The industry’s AI security conversation has been noisy, and not always precise. Some discussions focus on model safety. Others focus on data privacy, hallucinations, prompt injection, copyright, or regulatory exposure. All of those matter, but Aembit’s announcement points to a more operationally immediate concern: delegated authority.
Delegated authority is what turns an AI system from a suggestion engine into an enterprise actor. Once an agent can retrieve records, call APIs, update systems, or trigger workflows, the central security question changes. It is no longer only “What did the model say?” It becomes “What was the agent allowed to do?”
This is where agentic AI starts to resemble cloud workload security more than chatbot moderation. The agent needs identity. The resource needs policy. The credential needs a lifespan. The decision needs a record. The system needs a way to deny access without breaking the entire enterprise.
That framing also helps cut through some of the hype. Aembit is not claiming to solve hallucination, model bias, or the full spectrum of AI risk. Its claim is narrower: when agents access enterprise resources, they should not do so through static secrets and invisible delegation. That is a practical claim, and it is easier to evaluate.
The downside is that access control alone cannot make an agent safe. A perfectly authenticated agent can still perform the wrong permitted action if its instructions are manipulated or its reasoning fails. IAM is necessary infrastructure, not a complete AI governance program. Enterprises will still need testing, monitoring, data controls, prompt-injection defenses, human approval patterns, and business process design.

The Windows Enterprise Has Seen This Movie Before​

For Microsoft customers, the lesson should resonate. Windows and Microsoft 365 environments have always balanced empowerment with control. Macros empowered users and created malware ecosystems. PowerShell empowered administrators and attackers alike. OAuth app consent made integrations easy and became a major governance headache. Power Platform democratized automation and forced organizations to mature their tenant policies.
Copilot Studio is entering that lineage. It gives business users a way to create useful software-shaped behavior without writing traditional software. That is both its magic and its risk. The platform’s success will depend not just on how smart the agents become, but on whether enterprises can govern them without crushing adoption.
Aembit’s integration is one answer to that governance problem. It inserts identity discipline into the access path without demanding that every agent be hand-built by security engineers. It acknowledges the reality that enterprises will not stop building agents while security architecture catches up.
There is a broader cultural shift here as well. For years, IAM teams have focused on human users, privileged admins, SaaS access, and cloud workloads. Agentic AI adds a new class of actor that is neither quite human nor quite conventional software. Treating that actor casually because it arrived through a chat window would be a mistake.
The right mental model is closer to a junior employee with API access, perfect memory, incomplete judgment, and the ability to operate at machine speed. No sane organization would give such an employee a permanent master password and no audit trail. Agents should not get one either.

---

The Copilot Studio Security Story Now Has a Missing Middle​

The most interesting part of this announcement is the space it occupies between Microsoft’s platform controls and enterprise resource security. Microsoft can govern Copilot Studio at the tenant and platform level. Individual systems can enforce their own permissions. But agentic workflows often require a middle layer that understands the relationship between the user, the agent, the task, and the target resource.
That missing middle is where policy becomes contextual. A finance analyst’s agent may be allowed to query one dataset during business hours from a managed device, but not export sensitive records through an unfamiliar connector. A support agent may summarize tickets but not modify customer entitlements. An executive assistant agent may read calendars but not retrieve confidential board materials unless additional conditions are satisfied.
These are not exotic policies. They are the kinds of rules enterprises already try to express across identity, endpoint, network, and data systems. The difficulty is applying them to an agent that may call multiple tools across a single natural-language request.
Aembit’s promise is that the access decision can be made at the point of resource access, with enough context to be meaningful. That is stronger than relying solely on front-door authentication and weaker than pretending every possible agent behavior can be predicted in advance. It is a pragmatic architecture for an unpredictable interface.
The open question is how far customers will take it. Some will use the integration mainly to eliminate static credentials. Others will attempt more granular policy models tied to agent identity, user attributes, environment, resource sensitivity, and task type. The second path is harder, but it is where agent governance becomes genuinely differentiated.

The Marketing Term Is New, but the Architecture Debt Is Old​

“Agentic AI” is the phrase of the moment, and like most industry phrases, it risks blurring more than it clarifies. Still, beneath the jargon is a real architecture shift. Software is moving from passive response to semi-autonomous action, and enterprise security models are not automatically ready for that.
The debt is not only technical. It is organizational. Business teams want results. Security teams want control. Compliance teams want evidence. Platform teams want standardization. Developers want fewer bespoke integrations. Executives want AI adoption without becoming the next cautionary tale.
Aembit’s Copilot Studio support is aimed at that organizational knot. By giving agents distinct identities, replacing persistent secrets with ephemeral credentials, and logging access decisions, it offers a language security teams already understand. It turns the agent from a mysterious AI object into a workload with identity and policy.
That may sound unromantic, but it is exactly how enterprise technology becomes real. The flashy part gets attention; the boring part determines whether it survives procurement, audit, and incident response. Agentic AI will not scale in serious organizations on vibes, demos, and shared tokens.
The companies that win this layer will be the ones that make governance feel like infrastructure rather than supervision. Aembit has a credible claim there because workload IAM was its starting point, not a slogan bolted onto an AI landing page. The Copilot Studio integration tests whether that foundation translates into Microsoft’s agent ecosystem.

---

The Lesson From Aembit’s Copilot Move Is That Agents Need Leashes, Not Just Launch Buttons​

The practical meaning for Windows and Microsoft 365 shops is straightforward: agent adoption is now an access governance project. Copilot Studio may make it easy to build and deploy agents, but production use requires decisions about identity, credentials, policy, logging, and ownership before those agents touch sensitive systems.

• Enterprises should inventory Copilot Studio agents and the internal systems, APIs, data stores, and MCP servers they can reach.
• Security teams should treat agents as distinct non-human identities, not merely as invisible extensions of the users who invoke them.
• Long-lived credentials in agent or MCP configurations should be viewed as temporary scaffolding, not a production security model.
• Access policies should evaluate both user context and agent context so that delegated authority is explicit rather than assumed.
• Audit logs should capture the access decision itself, including the user, agent, resource, policy outcome, and credential issuance event.
• Agent readiness reviews should happen before production deployment, because retrofitting governance after business teams depend on an agent is much harder.

The larger story is not that Aembit has solved AI security, or that Copilot Studio is unsafe by design. It is that enterprise AI is crossing the line from answering questions to exercising authority, and that line demands a different control model. If Microsoft’s agent platform keeps expanding at its current pace, identity for agents will become as ordinary — and as non-negotiable — as identity for users, devices, and cloud workloads. The organizations that understand that now will move faster later, because they will not have to choose between useful agents and governable ones.

---

References​

1. Primary source: AiThority
   Published: 2026-06-17T14:50:08.440086
   
   

   Aembit Extends IAM for Agentic AI to Microsoft Copilot Studio

   Aembit on Tuesday announced support for Copilot Studio, extending its identity and access management capabilities to Microsoft&#039;s enterprise AI agent platform.

   aithority.com
2. Official source: microsoft.com
   
   

   Extend agents with Model Context Protocol (MCP) in Copilot Studio | Microsoft Copilot Blog

   Discover how Model Context Protocol (MCP) extends Microsoft Copilot Studio, connecting agents to data, APIs, and external systems.

   www.microsoft.com
3. Related coverage: aembit.io
   
   

   Aembit | Agentic AI and Workload Identity &amp; Access Management

   Aembit is IAM for agentic AI and workloads. Enable secretless access and real-time policy enforcement across any environment to protect data and accelerate AI adoption.

   aembit.io
4. Related coverage: docs.aembit.io
   
   

   Securing AI agent access to your resources | DOCS

   How Aembit secures AI agent access to enterprise resources through the Model Context Protocol (MCP)

   docs.aembit.io
5. Official source: learn.microsoft.com
   
   

   Select a primary AI model for your agent - Microsoft Copilot Studio | Microsoft Learn

   Choose an AI model for your Microsoft Copilot Studio agent. You can select default models and try out experimental models.

   learn.microsoft.com
6. Official source: developer.microsoft.com
   

   Microsoft 365 Copilot | Extend and Customize Copilot

   Extend, enrich, and customize Microsoft Microsoft 365 Copilot. Explore Copilot extensibility options such as agents, API plugins, and Copilot connectors to expand AI-powered productivity, skills, and creativity.

   developer.microsoft.com

Spoiler: Additional references (3)

1. Related coverage: streetinsider.com
   
   

   Aembit Extends IAM for Agentic AI to Microsoft Copilot Studio

   ...

   www.streetinsider.com
2. Related coverage: zonebourse.com
   
   https://www.zonebourse.com/actualite-bourse/aembit-inc-etend-la-gestion-des-identites-et-des-acces-pour-l-ia-agentique-a-microsoft-copilot-stud-ce7f5cdcdd80f524
3. Related coverage: windowscentral.com
   
   

   "Agents are only as good as the context we give them": Microsoft IQ connects AI agents to your workspace data and the web | Windows Central

   The newly unveiled Microsoft IQ data stack and Scout assistant turn generic AI into a personalized workplace tool.

   www.windowscentral.com