Introduction

As your organization and you personally begin to improve your productivity and job satisfaction with Microsoft 365 Copilot Studio, autonomous agents are an exciting new tool in your arsenal. With Copilot Studio, you can build autonomous agents that categorize and prioritize your emails, summarize your documents, or post updates into Teams—and it just works, because it runs as you.

The other important class of agents are enterprise-grade autonomous agents that run headless, touch sensitive data, and operate as part of your organization’s automation fabric. These agents need dedicated identities, least-privilege permissions, and robust governance. We’ll cover those in Part 2 of this series.

This article focuses on personal and maker scenarios—agents that run using end-user or maker credentials. You’ll learn:

• How interactive and autonomous agents differ in practice
• When user- or maker-bound authentication is acceptable
• Where it breaks down as your automation grows
• The governance guardrails you should apply even in “small” scenarios

In Part 2, we’ll move to enterprise-grade autonomous agents that run headless with Agent ID and least-privilege permissions.

Understanding Interactive vs Autonomous Agents

Interactive Agents: You in the Loop

Interactive agents are designed with a user-first approach. They operate in your session and under your Microsoft 365 permissions. You stay in control, invoking them when needed and reviewing the results.

Think of them as personal productivity boosters. Common examples include:

• Reviewing calendars and reminders to keep your day organized
• Automating email triage, categorization, and follow-up suggestions
• Generating quick reports from your personal or team datasets

The key characteristics:

• Scoped to you: They can only see what you can see.
• User-driven: You decide when to invoke them.
• Limited scope: Mistakes are usually limited to your own data.

Autonomous Agents: You Out of the Loop

Autonomous agents execute tasks without direct user interaction. They are event-driven and designed for headless execution—for example:

• Watching a SharePoint library and summarizing new documents
• Processing responses from a Forms survey and updating a list
• Posting daily digests or insights into a Teams channel

[!Note] Like interactive agents, autonomous agents can also run under the permissions of a user or maker account.

In this article, we focus on personal or team-scale autonomous agents—those that still operate primarily within the scope of a specific user or maker, even if they run automatically.

In Part 2, we’ll expand to enterprise-scale autonomous agents that act as infrastructure, affect many users, and must run independently of any individual account.

Personal Autonomous Agents

A few examples of personal autonomous agents include:

• A personal agent that summarizes daily activity based on your own emails and documents
• A team bot that posts updates into a project channel based on a single SharePoint library
• An experimental agent that helps your small group test a new process

Build a Personal Autonomous Agent

See Create an Inbox Summary to Teams Chat Agent for a step-by-step guide on building a personal autonomous agent that sends you summaries of emails as they arrive in your inbox. You can use as you read this post to get hands-on experience with personal autonomous agents.

Authentication Models for Personal and Maker Use

The authentication model you choose determines who the agent really is in your environment.

End-User Credentials

End-user credentials are ideal for personal assistants and lightweight automations:

• The agent acts exactly as the signed-in user.
• The mental model is simple: “If I can see it, the agent can see it.”
• It works well for scenarios like notifying you about changes, summarizing your own documents, or automating small workflows tied to your role.

Trade-offs:

• Token lifecycle: Tokens expire; re-authentication is required.
• Continuity risk: If the user is deprovisioned, changes roles, or loses a license, the automation breaks.
• Limited scope: It’s a poor fit for shared, always-on system workloads.

Maker Credentials

What “maker‑provided credentials” means

Execution identity: The tool runs using the connection you configure—such as a service account, app registration, or API key. Scope: All users of the agent share this single connection. They do not sign in or consent individually. Use cases: Ideal for back‑end systems without per‑user authentication (e.g., line‑of‑business APIs), actions requiring elevated or consistent permissions, or scenarios that need an application identity.

Why use maker credentials? They’re commonly chosen when a builder wants the agent to act on behalf of a team rather than an individual—for example:

Posting updates into a shared Teams channel

They can be acceptable for:

• Prototypes and proof-of-concepts
• Low-risk internal workflows with clear ownership and limited data scope

However, they come with serious governance risks:

• Oversharing: Remember that the agents access everything the maker can access. As makers are employees - like everyone else - all users of the agent will have access to the same data as the maker. This can lead to unintentional data exposure. The responses are in the security context of the maker - this is likely not appropriate for most scenarios.
• Accountability: It can be hard to determine whether an action came from the maker or from the agent.
• Fragility: If the maker leaves the organization or loses access, the agent quietly stops working.

Best Practices for Using Maker Credentials

• Agents with maker credentials could be used to work for a small team, but it is important to understand the risks and limitations. For example, an agent that posts updates to a team channel based on a shared SharePoint library could be built using maker credentials. Since the agent operates with the maker’s permissions, it may inadvertently expose sensitive data to team members who should not have access. Therefore, while maker credentials can be useful for small team scenarios, it is crucial to assess the risks and consider transitioning to more robust authentication methods as the agent’s role expands.
• Agents with maker credentials should not be used for enterprise-wide deployments or scenarios involving sensitive data. As the agent’s responsibilities grow, it is advisable to shift to dedicated identities like Agent ID to ensure proper governance, security, and compliance.
• Agents with maker credentials should not be shared with others, except in very limited scenarios where the risks are well understood and mitigated. Co-development would be one example. Sharing such agents broadly can lead to unintended data exposure and complicate accountability.
• Maker credentials should be treated as temporary and non-production for anything that starts to look enterprise-critical.

See Use End-User or Maker Credentials When for admin guidance on how to disable maker credentials for autonomous agents.

When Personal or Maker Authentication Is (and Isn’t) Acceptable

A simple way to decide whether to stick with end-user or maker credentials is to look at potential impact, business criticality, and longevity.

Use End-User or Maker Credentials When

• The agent acts mainly on one person’s or one small team’s data
• The data is low to medium risk (internal collaboration, drafts, non-regulated content)
• Interruptions are tolerable (e.g., if tokens expire or the maker is out)
• The goal is learning, prototyping, or local productivity, not shared infrastructure

[!CAUTION] The ‘Credentials to use’ are set to ‘End user credentials’ to ensure the agent uses the connection of the user interacting with it. If enabled by the admin, there is the option to use ‘Maker-provided credentials’. This should be selected only if the agent is intended to always use a specific connection regardless of the end user. Note that all interactions will be in the context of the maker’s connection - which may have unintended consequences when the agent is shared with others. That is, instead of sending a message to the end user’s Teams chat, it would always send to the maker’s Teams chat. Additionally, when the access token for the maker’s connection expires, the agent will fail until the maker renews the connection. Admins can see here for information on disabling the option for maker-provided credentials: Control maker-provided credentials for authentication.

Move Beyond User/Maker Credentials When

• The automation is now business-critical or supports multiple business units
• It touches sensitive or tenant-wide data (finance, HR, legal, regulated content)
• It must keep running regardless of who is on vacation, changes roles, or leaves
• You need auditable, enforceable governance (Conditional Access, DLP, access reviews)

When your answers lean toward these enterprise needs, it’s time to move to Agent ID and app-only permissions—the subject of Part 2.

Licensing and Billing for Personal and Maker Agents

Licensing for personal and maker scenarios is typically user-centric:

• Interactive agents and personal automation are covered by the user’s existing M365 Copilot license.
• As long as the agent is acting as a licensed human user, and the scenario aligns with your licensing terms, you’re within the expected model.

However, there is a common anti-pattern:

Anti-pattern: Assigning a Copilot license to a “service account” and using it as a robot user.

This approach is problematic because:

• It violates the spirit (and often the terms) of user-based licensing
• It hides enterprise workloads behind a pseudo-user, making governance harder
• It doesn’t scale operationally for hundreds of agents

The billing for personal autonomous agent scenarios are either zero-cost (included in a users M365 Copilot license) or billed via pay-as-you-go consumption (Copilot Credits).

The billing for enterprise-grade autonomous agents will typically be billed via Copilot Credits and not tied to any individual user license. We’ll cover that in Part 2.

Publishing Autonomous Agents for Personal and Maker Use

When you create an autonomous agent using end-user or maker credentials, you can publish and share it with others in your organization, but there are important caveats:

• Connection setup: Each user must set up their own connections to the services the agent uses (e.g., Outlook, Teams). The agent will run in the context of their credentials.
• Data access: The agent can only access data that the individual user or maker has permission to see.
• Token lifecycle: Each user is responsible for maintaining their own authentication tokens. They may need to re-authenticate periodically.
• Governance: Admins should monitor the use of personal and maker agents to ensure they comply with organizational policies.

[!CAUTION] It is not considered best practice to share autonomous agents broadly across the organization like interactive agents. Instead:

• Limit access to relevant roles or departments.
• Implement governance policies (approval workflows, audit logs).
• Scale sharing only after validating security, compliance, and operational impact.

Publishing to a channel is not required

Autonomous agents created with Copilot Studio do not need to be published to a channel like interactive agents do.

Here’s why:

• Interactive agents are designed for user-driven conversations in Copilot, Teams, the web or other channels, so publishing to a channel is required to make them accessible to end users.
• Autonomous agents, on the other hand do not require user interaction. They are typically triggered by events or schedules and operate without direct user interaction. Because of this, they don’t require channel publishing—they execute based on their configured triggers and permissions.

Checklist for Safe Personal Automation

Even for “small” automations, you can adopt habits that make later scaling much easier.

1. Know Which Identity the Agent Uses

• Confirm whether the agent is running as you, as a maker account, or as an Agent ID.
• Document that choice with a short description and owner.

2. Scope Data Access Narrowly

• Limit access to the minimum sites, teams, mailboxes, or file locations required.
• Regularly review what data the agent can access and adjust as needed.

3. Avoid Service Accounts with User Licenses

• Do not use shared mailboxes or generic “robot users” with end-user licenses to run autonomous agents.
• If a scenario truly behaves like a system, treat it as a system—use Agent ID.

4. Plan for Lifecycle from Day One

• Ask: What happens if I change roles, lose a license, or leave the company?
  For this scenario, admins can leverage access reviews to periodically review the access of makers to ensure that only active makers have access to the agents they created. You can use Microsoft Admin Center to monitor an agent’s owner status. See Ownerless shared agent management. If reassignment is needed, admins can use PowerShell to reassign the agent to a new maker. See Reassign an agent’s owner with PowerShell.
• Avoid anchoring critical workflows solely on your personal identity.
• If you see that happening, you’re already in Part 2 territory.

5. Communicate Token and Consent Requirements

• Make sure any collaborators understand that tokens expire and that they may be prompted to re-authenticate.
• Document the steps needed to re-establish connections if they break.

What’s Next: From Personal Helpers to Enterprise Infrastructure

Personal and maker-bound agents are a powerful on-ramp. They help you:

• Learn Copilot Studio’s capabilities quickly
• Deliver value to yourself and your immediate team
• Explore patterns and ideas before involving central IT

But as soon as your automation begins to:

• Run continuously,
• Touch sensitive or broad datasets, or
• Become business-critical for many users,

you need a different approach.

In Part 2: Enterprise-Grade Autonomous Agents with Agent ID and Least Privilege, we’ll walk through:

• Enabling Agent ID for Copilot Studio
• Designing least-privilege permission models using Sites.Selected and similar scopes
• Using PowerShell and Microsoft Graph to grant precise access to SharePoint
• Applying Conditional Access, DLP, and audit to keep agents compliant at scale
• Aligning billing and licensing with enterprise expectations

That’s where your agents stop being sidekicks—and start becoming part of your core automation infrastructure.