Maker mode is the default connection type in Microsoft Copilot Studio.
Security engineers reviewing Copilot Studio for the first time often ask the same question: whose credentials does this agent actually use? The answer depends on how the connector was configured, and the default answer is the maker's.
In Microsoft Copilot Studio, agents connect to external data sources and services through connectors. Each connector has an authentication setting that determines which identity the agent presents when it calls a downstream system. Maker mode means the connector authenticates using the credentials of the person who built the agent, not the person who is running it. The maker's identity, along with all the permissions that identity holds, is embedded into the connector at build time.
This default exists for a practical reason. When a developer or power user builds an agent, they want it to work immediately without requiring every downstream user to authenticate separately. Maker mode removes that friction. The agent connects to SharePoint, Salesforce, or any other integrated system using the builder's existing access, and the agent works for anyone the builder shares it with.
The convenience is real. The risk is equally real, and it scales with every agent deployed.
Configuration is not reality. What the agent is set up to do and what it can actually execute are two different things, and maker mode is where that gap is widest.
The core maker mode security risk is an identity mismatch that your IAM architecture was never designed to detect.
When a user invokes a maker mode agent, the downstream system does not see the user. It sees the maker. The request arrives authenticated with the maker's credentials, carrying the maker's permissions, and the downstream system responds accordingly. If the maker is a Salesforce administrator, the downstream Salesforce environment treats every agent-mediated request as an administrative action, regardless of who triggered it.
This is the IAM bypass mechanism. The invoker, the person actually running the agent, has no Salesforce access. The agent has full administrative Salesforce access. The agent does not check whether the invoker is entitled to the data it retrieves. It has no mechanism to perform that check. It simply executes the request using the credentials it was given at build time.
The result is a privilege escalation path that operates entirely within expected system behavior. No authentication alert fires. No anomaly is logged. The Salesforce audit trail shows a valid administrative session. The Copilot audit trail shows a user invoking an agent. Neither log connects those two events into a single picture of what actually happened.
The invoker-credential disconnect in plain terms:
What the invoker hasWhat the agent hasWhat the downstream system seesNo Salesforce accessAdmin Salesforce credentials (maker's)A valid admin sessionRead-only SharePointFull SharePoint write access (maker's)A legitimate write operationNo CRM visibilityFull CRM access (maker's)An authorized data export
This is not a bug. It is the designed behavior of maker mode. That is precisely what makes maker mode security so difficult to address with controls that were designed for human identity governance.
Understanding maker mode security risks requires moving from the abstract mechanism to concrete scenarios. Three patterns appear consistently across enterprise deployments.
A Copilot Studio administrator builds an agent to help the sales team query CRM data. The administrator configures the Salesforce connector in maker mode using their own admin credentials because it is the fastest path to a working agent. The agent is deployed org-wide.
A sales development representative with no Salesforce license invokes the agent. They ask for the full pipeline report for a competitor-facing account. The agent queries Salesforce using the administrator's credentials, retrieves the complete opportunity record including confidential pricing and deal terms, and returns it in the chat response.
The sales development representative now holds data they have no right to see. The administrator's credentials were never compromised. The agent behaved exactly as designed. No alert fired on either platform. This is AI agent privilege escalation in its most common production form.
An IT administrator builds a Copilot agent to automate HR data lookups. The agent connects to the HR system in maker mode using the administrator's credentials. Six months later, the administrator leaves the organization. Their account is disabled in Active Directory.
The agent continues running. The connector's embedded credentials persist independently of the maker's account status. Any user with access to the agent can still invoke it, and it still executes HR data queries using the embedded credentials from the now-disabled account.
This is an orphaned agent: a persistent, unmonitored access path where the maker is gone but the blast radius remains. Security teams with no AI agent inventory cannot identify these agents because they have no system of record that correlates agent credentials with account lifecycle events.
A Copilot Studio agent is built to support customer success workflows. The maker configures connectors to both SharePoint and Salesforce in maker mode. The maker holds admin access to both platforms.
A user in a geography with restricted data access invokes the agent. The agent queries Salesforce for customer records subject to regional data residency requirements, then writes a summary to a SharePoint site accessible to the entire organization. Two platform controls are bypassed in a single agent interaction. The data moves across both platforms in seconds.
This is action chaining through maker mode credentials. Each individual step looks legitimate. The sequence produces an outcome that violates data governance policy on both platforms simultaneously. Toxic combinations like this, where multiple risk factors compound in a single agent workflow, are the scenarios that produce the highest blast radius.
Security teams are not ignoring maker mode. They are using tools that structurally cannot see it.
Configuration-based tools see the connector. They can tell you that a maker mode connector exists and that it has a certain permission scope. What they cannot tell you is who invoked the agent, whether that invoker was entitled to the data the agent retrieved, or whether the retrieval actually occurred. This is ghost chasing: reviewing theoretical configuration signals with no runtime evidence of what actually happened.
IAM tools see the human. They track the invoker's identity, their group memberships, and their direct application entitlements. They do not see the agent as a separate identity. They do not model the agent's embedded credentials as a distinct access path. The invoker appears to have no Salesforce access, which is accurate. The fact that they just extracted Salesforce data through an agent is invisible to the IAM layer.
Native platform tools do not flag this as a risk. Microsoft Copilot Studio's native audit logs record agent invocations and connector calls. Salesforce's native logs record authenticated API sessions. Neither platform's native tooling correlates the invoker identity from Copilot with the credential identity presented to Salesforce. The connection between those two events requires cross-platform identity correlation that no single platform's native tooling performs.
The result is a visibility gap that sits precisely at the intersection of three tool categories, and falls into none of them. This is the structural reason that maker mode privilege escalation persists in production environments that have mature IAM programs, active SaaS monitoring, and regular security reviews.
Addressing maker mode security requires three capabilities working together. Detection alone is not sufficient. Identity correlation without enforcement produces expensive logging. Enforcement without detection context produces false positives. All three must operate at runtime.
The first requirement is a complete agent inventory that maps every maker mode connector to its embedded credentials. Security teams cannot govern what they cannot see. That inventory must include the maker's identity, the permission scope of the embedded credentials, the platforms the connector reaches, and the set of users authorized to invoke the agent.
This inventory must be live, not periodic. Agents are deployed continuously. A weekly scan of Copilot Studio produces a snapshot that is outdated before the report is read.
The second requirement is runtime correlation between the invoker's identity and the maker's effective authority. This is the core technical capability that existing tools lack. When a user invokes a maker mode agent, the security layer must resolve two questions simultaneously: what is this user entitled to access directly, and what can the agent access on their behalf using the maker's credentials?
The gap between those two answers is the privilege escalation surface. Obsidian's Identity Graph performs this correlation by mapping the runner's identity against the agent's embedded credentials and the downstream entitlements those credentials carry. This produces a view of effective authority, not theoretical configuration. When the runner's direct entitlements do not match the agent's effective authority, the system flags the mismatch as a privilege escalation risk.
The third requirement is enforcement. Detection and correlation produce risk signals. Deterministic guardrails act on those signals before the data moves.
Probabilistic agents make decisions based on context and instructions. They cannot self-enforce access boundaries because they have no mechanism to verify the invoker's entitlements against their own embedded credentials. That verification must happen outside the agent, in a control layer that applies fixed, predictable rules regardless of what the agent's instructions say.
For maker mode specifically, the guardrail logic follows a clear pattern: if the invoker's direct entitlements do not include access to the data the agent is about to retrieve, the action is blocked and the event is logged with full identity context. This is what agentic guardrails look like in practice: not a policy document, but a runtime enforcement decision made in the window before the agent's tool call completes.