One Agent, Two Audiences, Two Authentication Realities
Tailspin (1,100 employees, E3 with 250 Copilot licences) wants a Field Service Helper agent. It must answer from a public product-manual website that has no sign-in, and from an internal SharePoint site holding warranty entitlement data that only the 90 warranty staff may read. It must be usable in Microsoft Teams by those 90 staff, and by 300 field contractors who have Teams guest accounts but no Microsoft 365 licence. The maker built one agent in the default environment, pointed it at the manual site anonymously, added a link to the warranty site, and published to Teams. Warranty staff say it answers 'I could not find anything about that', and contractors report a sign-in loop.
1. Diagnose the two failures and decide whether one agent can serve both audiences.
Read the worked answer
Two different failures with one common cause: the agent was designed for a single audience.
- Warranty staff get no answer. A bare hyperlink is not a knowledge source. The SharePoint site must be added as a SharePoint knowledge source, and retrieval happens in the context of the signed-in user's access. The maker tested in the authoring canvas as themselves, so the missing source and the permission mismatch never showed up.
- Contractors loop on sign-in. The agent's authentication configuration expects an Entra identity that can be authorised for the requested content. A guest without a licence and without membership of the warranty site cannot be authorised, so the flow fails at the door.
Can one agent serve both? Not with one knowledge set and one authentication mode. The moment the agent contains a warranty source, an anonymous visitor must be denied it; the moment it is anonymous, retrieval for warranty data cannot be delegated to the user. Blending them produces exactly the two symptoms observed.
Decision: split the agent. A public manual agent with no authentication and a single public knowledge source; an internal warranty agent with Entra ID authentication, SharePoint knowledge, and a security group of 90. Two small agents that behave predictably beat one agent that cannot satisfy either audience.
2. Specify channel, authentication and knowledge source for each agent, and the one configuration that must never be used.
Read the worked answer
Internal agent - warranty
- Channel: Microsoft Teams.
- Authentication: Microsoft Entra ID (SSO) so retrieval runs as the signed-in user.
- Knowledge: the SharePoint site as a SharePoint knowledge source, so entitlements are only returned to users who can open the source themselves.
- Sharing: a security group of the 90 warranty staff, not the whole tenant.
Public agent - manuals
- Channel: website (custom canvas), or Teams if contractors only ever need the manual.
- Authentication: none, because the source itself is public.
- Knowledge: the public website only. No internal source is attached, so there is nothing to leak.
Never do this: set the internal agent to no authentication to 'fix' the contractor loop. With no user identity, retrieval has to fall back to a fixed identity, which either fails outright or returns warranty data to anyone with the link. That is the failure mode that turns a support ticket into a breach notification.
If contractors genuinely need warranty data, the answer is a business and entitlement decision - grant them guest identities and add them to the security group - not an authentication workaround.
3. What environment and lifecycle changes are needed before this goes live?
Read the worked answer
Move it out of the default environment and treat it like an application.
- Environment. The default environment is shared by every maker in the tenant and is not a place for a production agent handling entitlement data. Create a dedicated environment, put the agents there, and apply a DLP policy to that environment that permits only the connectors actually needed. If the SQL or HTTP connector is not required, block it so the agent cannot quietly grow a new data path later.
- Maker governance. Restrict who can create agents and who can share them. Agent sprawl in Teams is a permissions problem wearing a productivity hat.
- ALM. Build in a development environment, promote via a solution to test, then production. Directly edited production agents have no rollback path.
- Monitoring and cost. Ensure the production environment has capacity or pay-as-you-go attached, and review conversation analytics. An agent answering 'I could not find that' is a knowledge-source defect, and analytics is the only place it shows up before users complain.
- Data minimisation. Warranty entitlement is a narrow dataset. Prefer a filtered view over the raw table so that even a misconfiguration cannot return the full dataset.