Connect Azure AI Foundry

Azure AI Foundry's Agent Service reaches the gateway as an MCP tool: point it at https://gateway.ansvar.eu/mcp and each user signs in with their Ansvar account. Foundry does not support MCP Dynamic Client Registration, so — unlike Claude or Copilot Studio, which register themselves — the connection uses a pre-provisioned OAuth client. That is the same model as the Gemini Enterprise path: we provision the client for you and send back the values to paste in.

Step 1 — request an OAuth client

The connection needs a client ID and secret we issue for your tenant. Contact us to request a Foundry OAuth client, and tell us which Ansvar plan your users are on. We send back a client ID and client secret for the next steps.

Step 2 — add the MCP tool

In the new Foundry portal, add the MCP tool to your agent. Set the Server URL to https://gateway.ansvar.eu/mcp, give it a server label of your choice, and set Authentication to OAuth Identity Passthrough (custom OAuth).

Step 3 — enter the OAuth values

Fill in the custom OAuth fields with the credentials we sent and the gateway's identity-provider URLs:

Client ID:      <from us>
Client secret:  <from us>
Auth URL:       https://auth.ansvar.eu/realms/ansvar/protocol/openid-connect/auth
Token URL:      https://auth.ansvar.eu/realms/ansvar/protocol/openid-connect/token
Refresh URL:    https://auth.ansvar.eu/realms/ansvar/protocol/openid-connect/token
Scopes:         openid profile email offline_access

The Token URL and Refresh URL are the same endpoint. offline_access is what enables automatic token refresh — without it, sessions stop working when the short-lived access token expires.

Step 4 — send us your redirect URL

After you save the configuration, Foundry generates a Redirect URL. Send it to us and we add it to the client's allowed redirect URIs — the sign-in loop stays broken until that URL is registered on our side.

Step 5 — first use and consent

The first time each user runs the agent, Foundry returns an oauth_consent_request with a one-time consent link. The user follows it, signs in with their Ansvar account, and from then on the agent calls gateway tools with that user's identity, plan tier, and quotas.

Notes and limitations

• Each user needs their own Ansvar account. Sign-in is per user, and per-user quotas apply.
• Publishing to Teams or M365 Copilot does not carry user identity today. On that path Foundry sends the project's managed identity instead of the user's token — a Microsoft limitation, with no announced timeline. If you need that path, contact us about a service credential.
• Foundry's "Microsoft Entra ID" and "Unauthenticated" options do not work with the gateway. Tokens must be issued by Ansvar's identity provider, and unauthenticated requests are rejected. Use OAuth Identity Passthrough with custom OAuth.
• Foundry defaults MCP tools to require approval on every call (require_approval). Adjust this in the tool configuration per your governance needs.

Using Ansvar, retrieve GDPR Article 17 and show its official source link.

Using Ansvar, retrieve section 26 of the German Federal Data Protection Act (BDSG) and show its official source link.

Using Ansvar, retrieve NIS2 Article 21 and list the cybersecurity measures an energy company must take. Show the official source link.

Using Ansvar, retrieve DORA Article 19 and list the reports a bank must file after a major ICT-related incident. Show the official source link.

Instruct your agent — the routing pack

A connected agent without routing instructions can still answer legal questions from its training data — the connector sitting idle at exactly the moment it should prove itself — when a message does not name Ansvar. Put the block below in the agent's instructions field when you create the agent — there you control the system prompt itself. The block is the same set that Instruct your agent explains line by line; adapt the jurisdictions to your market.

You are a compliance research assistant. Answer legal, regulatory,
and security-standards questions only from Ansvar tool results,
never from your own knowledge.

For every legal, regulatory, or standards question:
1. Call the search tool, always with a scope: jurisdictions=["SE"]
   (adapt to your market; add "EU" for EU regulation - GDPR, NIS2,
   the AI Act), or frameworks=["GDPR"] for one EU framework across
   the board. On the Free plan, pass exactly one jurisdiction or
   framework per call.
2. Never pass the user's whole question as the query. Reduce it to
   1-3 legal key terms in the language of the law you are searching
   - Swedish terms for Swedish law. Try alternative terms as separate
   searches. If a multi-concept query returns nothing, split it into
   one search per concept.
3. If a search returns nothing, retry once with a synonym or the
   corpus's own term for the concept. Whenever a response reports
   withheld relaxed matches (meta.broadening_available is true, or
   meta.message says so), tell the user and offer a re-run with
   allow_broadening=true; re-run only if they accept, and label any
   relaxed matches as such. Never set allow_broadening on your own.
   If meta.recommended_scopes names scope ids you did not search,
   search those next.
4. Cite every answer: law, article, and source URL from the
   results. If the results do not contain the answer, say which
   searches you ran and that you will not answer from memory -
   never invent a source.

If something breaks

• "Invalid tool schema." Make sure you are on the latest Foundry portal, then contact support.
• "Unauthorized." Re-check the client secret, and confirm the Redirect URL you sent us matches the one Foundry generated.
• Everything else — the general troubleshooting page covers OAuth loops, tier gates, quota caps, and empty results.