Your Copilot Studio Agent May Be Acting as You — Not the User
Copilot Studio · Identity · Governance
Your agent may be acting as you — not the user.
A signed-in user does not tell you whose permissions a Copilot Studio tool will use. That hidden identity boundary can turn a helpful agent into a privilege-escalation path.
A user opens an agent in Teams, sees their name, and signs in with Microsoft Entra ID. It feels natural to assume that every action now runs with that user's permissions. In Copilot Studio, that assumption can be wrong.
The agent's conversational identity and a tool's runtime identity are separate decisions. A connector or embedded Power Automate flow can use the end user's credentials, the agent author's stored connection, or a deliberately managed service identity. The answer determines which records the action can read, which emails it can send, and which business operations it can perform.
Authentication tells the agent who is asking. The tool connection decides what the request can do.
One conversation, several identities
Most agent diagrams show a person, an agent, and a data source. The security model is more complicated. At minimum, review these identities separately:
| Identity | What it controls | Typical failure |
|---|---|---|
| Conversation user | Who can open and interact with the agent | Teams access is mistaken for data authorization |
| Agent maker | Who configured and published the agent | A personal connection remains behind a production tool |
| Tool connection | Which identity calls SharePoint, Dataverse, Outlook, or another API | The tool can see more than the requesting user |
| Flow owner and references | Who owns an embedded flow and which connections its actions use | Ownership changes, but old connection references still point elsewhere |
| Service identity | What an autonomous or centrally operated process may access | Broad permissions turn the agent into a shared privileged endpoint |
None of these identities is automatically wrong. The mistake is allowing the identity to be accidental or invisible.
Run the negative-permission test
Create a harmless test record that the maker can read but a test user cannot. Add a tool that retrieves it, then ask the agent for that record as the restricted user.
- Confirm that the test user cannot open the record directly.
- Run the tool with end-user credentials. Access should be denied.
- Change only the tool authentication to maker-provided credentials and repeat the request.
- Inspect the agent activity, flow run history, connector connection, and downstream audit log.
If the second configuration returns the record, the agent has not bypassed security. It has used a more privileged identity exactly as configured. That is why a successful demo is not evidence of a safe design.
Test writes as well as reads.
A maker-owned connection might let a user update a restricted record, send mail as the connection owner, or trigger an approval the user could not start directly.
Maker, user, or service identity?
End-user credentials
The tool acts within the requesting user's permissions. This is usually the safest choice for interactive agents accessing user-specific enterprise data. It preserves downstream authorization and attribution.
The cost is user experience. Users might need to create or approve connector connections, sometimes more than once when an agent uses several connectors. A missing permission correctly becomes a failed tool call rather than an invisible privilege upgrade.
Maker-provided credentials
The tool uses the connection stored by its author. This is useful for controlled shared capabilities, anonymous APIs, or cases where users intentionally should not receive direct access to the underlying system.
But the connection is now an authority boundary. Every parameter accepted by the tool, every row returned, and every action exposed must be constrained. Treat it like an application API, not a convenience toggle.
Service principal or managed service identity
A non-human identity removes dependency on an employee account and is the right direction for many mission-critical automations. It does not remove the need for authorization. Its permissions, ownership, secret or certificate lifecycle, licensing, request limits, and audit trail must all be designed.
Safe sharing is becoming a product boundary
Microsoft's 2026 release plan introduces safe-sharing enforcement intended to detect unsafe identities during agent design, publishing, and sharing. The public preview is listed for July 2026 and general availability for September 2026; roadmap dates can change.
This matters because a warning at tool configuration time is easy to miss. A publish-time control can stop an agent or flow from being shared while it still relies on credentials that were never intended for reuse.
The existing administrator control is broader than one agent. It can be set for an environment or environment group, and it covers connectors, built-in actions, and Power Automate flows used as tools. Changing it can affect existing agents, so it should be rolled out as a governed migration—not a surprise tenant setting.
The autonomous-agent trap
“Require end-user credentials everywhere” sounds safe, but it is not a complete architecture. Scheduled and autonomous agents have no live user available to complete an authentication prompt. Microsoft explicitly notes that preventing maker-provided credentials can cause background or autonomous triggers to fail.
The correct conclusion is not to keep personal maker credentials. It is to separate two execution models:
| Scenario | Preferred identity | Required control |
|---|---|---|
| Interactive lookup of user-authorized data | End user | Downstream permissions and clear consent |
| Shared narrow business operation | Managed service identity | Input validation, least privilege, full audit |
| Scheduled or autonomous process | Non-human identity | Explicit ownership, lifecycle, monitoring, kill switch |
| Prototype in a development environment | Maker may be acceptable | No production data and no broad sharing |
Power Automate does not hide the problem
Putting a Power Automate flow behind an agent adds another identity layer. The flow has an owner, but each connector action also resolves through a connection or connection reference. Changing the owner does not automatically prove that every action now runs through the intended identity.
For solution-aware flows, inspect connection references in every target environment. For production and DevOps scenarios, consider service-principal ownership, while checking the applicable Power Automate licensing and request limits. A stable non-human owner is useful only when the connections behind the flow are equally deliberate.
Before you publish
- Name the runtime identity for every tool and every flow action.
- Test with a user who lacks access to at least one requested resource.
- Verify read, write, delete, approval, and email side effects separately.
- Confirm whether a user consent prompt is acceptable in the target channel.
- Do not use an employee's personal connection for an autonomous production process.
- Scope service identities to the smallest tables, sites, mailboxes, and operations possible.
- Record ownership, connection references, licensing, credential rotation, and an emergency-disable procedure.
- Repeat the test after solution import and after changing environment-group policies.
If you cannot answer “who executes this tool?” without opening the designer, the agent is not ready for production.
Sources and further reading
- Control maker-provided credentials for authentication — Microsoft Learn
- Configure user authentication in Copilot Studio — Microsoft Learn
- Enforce safe sharing by detecting credential oversharing — Microsoft release plan
- Support for service-principal-owned flows — Microsoft Learn
- Use connection references in solutions — Microsoft Learn
Comments
Post a Comment