Yes, there is a supported alternative to the iframe approach.
The key distinction is that you don't normally expose the Copilot Studio agent as a generic REST API and then simply POST questions to it. For a custom website UI, Microsoft supports connecting the website to the agent through Direct Line.
Microsoft's current documentation explicitly lists Direct Line as the option for custom applications/web clients, and Direct Line provides REST/WebSocket communication with the Copilot Studio agent.
Recommended architecture
Instead of:
Website
↓
iframe
↓
Copilot Studio Web Chat
you can build:
Custom Website UI
↓
Your backend / secure token endpoint
↓
Direct Line token
↓
Copilot Studio Agent
↓
Response
↓
Your custom UI
The website development team can therefore build their own chat interface rather than displaying the Microsoft-provided iframe UI.
Microsoft also provides a Copilot Studio client/Web Chat integration specifically for custom web applications.
One important security point
I would not put the Direct Line secret in the browser.
If you enable Direct Line channel security, the recommended pattern is to keep the secret on your server and generate a short-lived Direct Line token for the browser. Microsoft documents this secured Direct Line approach specifically for controlling access to the web channel.
So, for example:
Browser
│
│ GET /api/copilot/token
▼
Website Backend
│
│ Direct Line secret
▼
Microsoft Direct Line
│
▼
Copilot Studio Agent
The browser receives a token, not your permanent Direct Line secret.
What about authentication?
If the agent is genuinely intended to be public and unauthenticated, No authentication is supported. Microsoft notes that this means anyone who has access to the agent/link can interact with it, so you should only expose public information/actions through that agent.
If the agent needs to access user-specific/private data, I would not leave it unauthenticated just to make the website integration easier. In that case, use an appropriate authentication architecture and pass the authenticated user context through the supported authentication/Direct Line pattern.
So I would choose based on the requirement
Simple public chatbot:
Copilot Studio
↓
No authentication
↓
Web channel / iframe
This is actually a supported Microsoft scenario.
Public website + completely custom UI:
Custom website
↓
Backend token endpoint
↓
Direct Line
↓
Copilot Studio
This is the approach I would recommend if the website team wants full control over the UI/UX.
Authenticated website + user-specific data:
User
↓
Website authentication
↓
Secure backend / token flow
↓
Direct Line + Copilot authentication
↓
Copilot Studio
↓
User-authorized data
That last scenario needs more careful Entra/OAuth configuration; I wouldn't simply expose a REST endpoint containing the agent credentials.
One other point: "Create REST API actions for custom agents" is not the same thing as exposing the entire Copilot Studio conversation as a generic REST API. If the requirement is a conversational custom UI, Direct Line is the more relevant integration mechanism.
So the website team's concern about iframe doesn't necessarily mean the current implementation is insecure. The iframe itself is a Microsoft-supported web deployment option. The real security question is what the agent can access and how the channel is secured. If they need a custom frontend, I'd move to Direct Line + a server-side token endpoint, rather than trying to turn the agent into a generic REST API.
