3.1.1. Enterprise Integration and Identity Strategy
💡 First Principle: Identity decides what the agent may reveal, per user, per answer. An authenticated agent knows who is asking and can pass that identity down to knowledge and tools, so retrieval honors each user's actual permissions; an unauthenticated agent answers everyone as if they were no one — every user sees whatever the agent can see.
That single principle drives the configuration space. Copilot Studio's authentication options span no authentication, Microsoft Entra ID integrated authentication, and manually configured OAuth-based providers. With Entra ID user authentication, connections and knowledge sources can operate under the end user's identity — SharePoint answers reflect the asker's document access; Dataverse queries respect their row permissions. With maker-supplied credentials instead, everything runs as the maker's account — simpler, but every user inherits that single view, which is a data-exposure decision, not a convenience.
Enterprise integration planning is the same thinking applied to systems: inventory which systems the agent must reach (Dataverse, ERP, ticketing, Microsoft Graph), then decide as whom each is accessed — the user (for permission-trimmed data), a service identity (for system actions users shouldn't hold rights to), or a mix. The exam rewards noticing when a scenario's data sensitivity forces user-context access.
⚠️ Common Misconception: "No authentication" is acceptable for internal-only agents. Without authentication, anyone who obtains the link can converse with the agent, and per-user permission trimming is impossible — internal agents should authenticate with Entra ID so answers respect each employee's access.
Reflection Question: An HR agent must answer "how much leave do I have left?" Which identity design is forced by that single requirement, and what breaks under maker-credential connections?
