3.4 Design Agents for Internal or External Audiences

The same Copilot Studio skills can power an employee helpdesk agent in Teams and a customer shopping assistant on a public website—but the design is not copy-paste. AB-620 skill design agents for internal or external audiences tests whether you adjust authentication, data exposure, channels, branding, and compliance for who is on the other side of the chat.

Define the audience before the first topic

Write a one-page audience brief:

If stakeholders cannot answer these, pause build work. Many failed deployments start as “we’ll use the same agent for everyone.”

Authentication differences

Internal agents usually rely on Authenticate with Microsoft. Users are already in Entra ID; group-based access can refine who sees the agent in Teams or M365. Tools should prefer user credentials so row-level security in Dataverse, SharePoint, or line-of-business systems is honored.

External agents require deliberate identity design:

• No authentication only for truly public content (store hours, public FAQ) with no internal knowledge and no privileged tools.
• Manual authentication (Entra ID external identities, customer IdPs as architected) when the agent must access personal orders or accounts.
• Never assume a public Direct Line channel “inherits” employee SSO.

Governance backstops still apply: data policies can block unauthenticated chat or block public channels entirely if the organization is not ready.

Scenario. Contoso builds a customer order bot. Correct design: web channel with customer authentication, tools that only return orders for the signed-in customer, generative answers limited to public product docs plus the customer’s own order records. Incorrect design: no auth + SharePoint folder of all customers’ invoices as knowledge.

Channel choice as an audience control

Channels are not just UX—they are security boundaries:

Admins can block channels via DLP so makers cannot publish an internal-data agent to social channels. When planning, list allowed channels per audience in the solution design.

Data exposure and knowledge scoping

Audience design is mostly data design:

1. Classify content — public, internal, confidential, restricted.
2. Bind knowledge sources to classification — public websites/docs for external; authenticated SharePoint/Dataverse for internal.
3. Filter tools — external agents should not call HRIS salary APIs.
4. Minimize transcripts — avoid capturing unnecessary personal data; follow retention policies.
5. Watch generative answers — models may summarize whatever they can retrieve; over-broad retrieval is over-broad disclosure.

Sensitivity labels on SharePoint knowledge help internal users see classification signals; they do not make confidential libraries safe on an anonymous external bot. Tenant isolation keeps your corporate tenant’s data from casually mixing into another organization’s agents; still, your external users are outside the employee trust boundary even inside your tenant’s hosting.

Branding, tone, and experience

Internal agents can use operational language (“submit a P4 incident,” “VPN RSA token”) and enterprise visual standards. External agents need brand-consistent colors, logos, and plain language. Use Web Chat customization and Adaptive Cards suited to the channel—Teams cards differ in constraints from public web cards.

Tone guidelines:

• Internal: concise, policy-accurate, link to intranet deep links.
• External: friendly, inclusive, localized; avoid internal jargon and employee-only URLs.
• Both: clear AI disclosure; never impersonate a human agent without labeling handoff.

Reusable Adaptive Card templates can still be audience-specific skins over the same data contract (for example, an order summary card with different branding).

Compliance and legal considerations by audience

Human handoff paths differ too: internal agents escalate to IT or HR shared services; external agents escalate to contact centers with CRM context. Plan business hours, languages, and emergency “this is not a crisis line” messaging where relevant.

Responsible AI differences

External channels generally justify stricter content moderation, tighter instructional scope, and more aggressive red-teaming (prompt injection, jailbreaks, abusive content). Internal agents still need moderation—insiders can probe systems too—but they may require richer tools and knowledge under stronger auth.

For both audiences, keep:

• Groundedness to approved sources.
• HITL for high-impact actions.
• Evaluation sets that include audience-specific abuse and privacy cases.

Decision framework you can reuse on the exam

When a scenario names an audience, walk this order:

1. Audience — employee, customer, partner, mixed?
2. Identity — Entra ID, customer auth, or limited anonymous?
3. Channel — M365 surface vs public/social?
4. Knowledge & tools — minimum necessary for that audience?
5. RAI & moderation — disclosure, filter level, refusals?
6. Compliance — privacy, retention, accessibility, geo?
7. Ops — handoff queue, owners, monitoring?

Mixed-audience anti-pattern. A single agent published to Teams and a public website with the same SharePoint knowledge and no auth on web. Fix by splitting agents or at least splitting knowledge/tool profiles and enforcing auth per channel strategy—usually two agents (or clearly separated configurations) is cleaner for governance.

Worked comparison

Internal IT agent

• Channel: Teams
• Auth: Authenticate with Microsoft
• Knowledge: authenticated IT SharePoint + Dataverse asset CMDB views the user can access
• Tools: create incident as user; optional device reset request with manager approval flow
• Moderation: Medium/High; disclosure in greeting
• Branding: Contoso IT virtual assistant

External product support agent

• Channel: Customer website via Direct Line + optional omnichannel
• Auth: customer account login for order-specific tools; anonymous only for public FAQ topic path
• Knowledge: public product docs; no internal postmortems
• Tools: order status by authenticated customer id; return initiation with fraud checks
• Moderation: High; marketing-approved disclosure; escalate to contact center
• Branding: Contoso Support, localized cards, accessibility pass

Both can reuse core fallback and logging components from a shared solution, but audience-specific shells own auth, knowledge, channels, and brand.

Exam traps to avoid

• Assuming Teams auth automatically protects a separately published anonymous web channel.
• Using public website knowledge as a substitute for authentication on personal data questions.
• Over-sharing internal deep links to external users.
• Ignoring that social channels may be blocked by DLP for good reason.
• Treating branding as optional when external legal/marketing sign-off is required.

Design for the human who will chat—and for the data they must never see. Internal and external agents share a platform, not a trust model.