Copilot Studio End-User Credentials vs Maker Credentials: A Least Privilege Comparison for Banks

What the choice actually decides

When a Copilot Studio agent calls a connector, tool or data action, something must authenticate that call. With end-user credentials, the call runs under the identity of the person talking to the agent. With maker credentials, it runs under a credential stored by the person who built the agent. The choice determines whose permissions the downstream system evaluates.

NIST SP 800-53 AC-6 requires allowing only the authorized accesses necessary to accomplish assigned tasks, for users and for processes acting on behalf of users. An agent is such a process. The architectural question is therefore whether the access it exercises is derived from the individual it serves or from a separate, standing identity.

NIST's draft Cyber AI Profile (an initial preliminary draft) notes that AI agents may have access to data sources or tools a user would not typically have. A maker credential is a direct way to create that condition: the agent's reach is set by the author's entitlements, not by the entitlements of whoever is asking.

Side-by-side against least privilege criteria

The matrix below evaluates each mode on six criteria. It describes the consequences that follow from whose identity is presented to the downstream system, and it assumes the stored maker account is not scoped down.

• Scope of access: End-user: limited to what the individual may already do. Maker: limited to what the stored account may do, regardless of who is asking.
• Privilege inheritance: End-user: the agent inherits the caller's privileges, no more. Maker: every user of the agent inherits the maker's privileges for that action, which can exceed their own.
• Attribution of actions: End-user: the downstream system sees the individual. Maker: the downstream system sees the stored identity, so tying an action to the person who triggered it needs a separate record.
• Revocation: End-user: removing or changing a person's access takes effect for that person's calls. Maker: the agent depends on one person's account, so a role change or departure can break the agent, or leave it running with access nobody reviews.
• Segregation of duties: End-user: existing separation between roles carries through. Maker: one credential can span duties that the bank separates between people, such as initiating and approving.
• Blast radius if misused or manipulated: End-user: bounded by the targeted user's entitlements. Maker: bounded by the maker's entitlements, and the same exposure applies to every user of the agent.

Matching the mode to the bank use case

Read-only account lookups are the strongest case for end-user credentials, because the entitlement question is already answered by the system of record. A relationship manager sees the accounts they are entitled to see, and the agent adds no access of its own. If a maker credential is used here, it will return data on behalf of a user who may not be entitled to it, which is the privilege inheritance problem in its plainest form.

Write actions, such as updating customer records, changing limits or initiating payments, should run under the end user's identity. Separation between initiators and approvers is typically defined per person, and a single stored credential cannot reproduce it. These actions also warrant explicit confirmation, discussed below.

Maker credentials have a narrower legitimate place: reading reference data that is identical for every permitted user, such as a public rate sheet or an internal policy library. Even then, the stored account should be a dedicated, minimally scoped identity with a named owner, not a personal account of the author. Consent and permission-scoping effort is the real cost of end-user mode, and it is usually worth paying for anything beyond that class.

What neither mode constrains

Authentication answers whose permissions apply. It does not evaluate an individual tool call. An agent running as a user entitled to initiate payments can be steered into initiating one the user never intended. NIST's agent identity design tenets state that prompt injection or untrusted data must not be able to manipulate credentials or expand an agent's actual permissions, and NIST agentic security material warns that agents can reuse credentials found in context, memory or tool responses, and that tokens can propagate across task boundaries beyond their original scope.

OWASP's guidance on tool-calling places the control at invocation: narrowly scoped credentials, explicit user confirmation for destructive, financial or data-sharing operations, full tool call parameters shown rather than a summary name, and policy checks enforced at execution time. OWASP also reports a June 2025 zero-click scope violation in Microsoft 365 Copilot, where instructions embedded in received email led to internal data exfiltration. That concerns a different product, but it illustrates how data reachable by an agent can be abused without the user acting.

The residual risk differs by mode. End-user mode leaves manipulation within the user's own entitlements. Maker mode leaves that same exposure plus access beyond the user's entitlements, with weaker attribution.

Decision rules for architects

These rules translate the comparison into design decisions that can be documented per agent action class.

• Default to end-user credentials for any action involving customer data, account changes or money movement.
• Permit maker credentials only for read-only actions on data every user of the agent may see, using a dedicated, minimally scoped account with a named owner.
• Set the mode per connector and action, not once per agent, so one agent can mix read and write risk correctly.
• Document, for each action class, the acting identity and why its access is necessary for the assigned task, as AC-6 frames it.
• Keep credentials out of agent context, memory and tool responses, and prefer short-lived tokens that represent the user.
• Require confirmation showing full parameters for financial or destructive calls, and enforce policy at execution time.

Where runtime enforcement and evidence fit

Examiners and model risk reviewers will want to see more than a configuration choice. They will want to know what an agent was allowed to do, what it did, and who authorized it. An authentication mode records whose identity was used. It does not record a decision about a specific call.

Trussed enforces policy in the execution path for models, agents, tools and MCP servers, at the level of individual interactions and tool calls: allow, redact, block, or escalate for human approval. Enforcement is at runtime, not reviewed after the fact. Each decision produces audit-ready evidence, mapped to frameworks including NIST and NYDFS. This complements the credential choice described above and does not replace it.

Trussed is deepest in insurance, a regulated financial sector, and runs in production for regulated enterprises, with 18+ months of continuous production in one and 99.95% uptime on live production traffic. It supports self-managed deployment in the customer cloud, with configurable retention and data residency.