LocoDELEGATIONS AI Connector – Technical Guide

This technical guide is for IT managers, security and identity teams, Power Platform administrators, and each council’s LocoDELEGATIONS Administrator. It accompanies the AI Connector beta proposal and distinguishes live capabilities from roadmap items.

1. About this document

This guide accompanies the LocoDelegations AI Connector beta proposal. The proposal explains what the connector is for and why a council might want it. This document is for the people who have to approve it, secure it and set it up. It describes how the connector works, what it exposes, how access is controlled, and how to connect it to Microsoft Copilot Studio, Claude and ChatGPT.

It is written for the beta programme. Some capabilities are live today and some are on the roadmap. Each is labelled as one or the other, so that nothing here is taken as a commitment it is not.

Setup instructions for each AI client are also shown inside LocoDelegations itself, on the AI Client Settings page under Setup. That page always reflects the exact values registered on your council’s instance, so if this document and that page ever disagree, the page is correct.

2. Summary for decision makers

The AI Connector lets an AI assistant your council already uses, such as Copilot Studio or Claude, ask your LocoDelegations instance questions on behalf of a signed-in council user. It does this using the Model Context Protocol (MCP), an open standard for connecting AI assistants to business systems, and OAuth 2.1, the same authorisation standard used by Microsoft 365 and most modern web services.

The points that usually matter most to IT teams:

• Nothing leaves your instance unasked. LocoDelegations never sends data to an AI vendor on its own. An AI assistant can only call in, and only while a council user has signed in and authorised it.
• Users sign in with their existing LocoDelegations login. If your council uses Azure AD (Microsoft Entra ID) for LocoDelegations, that is what they use. There are no new accounts, passwords or shared keys.
• Read for everyone, write for Administrators only. Every user can query through the connector and sees only what their role allows. Administrators can additionally make changes through an AI client. Each change applies the same validation as the web interface and is written to the change log.
• Scoped to your council. Each council has its own LocoDelegations database and web application. The connector is part of that application. There is no shared or central AI service.
• Off by default, and switchable per council. The connector is enabled per council by Locosoft. Your LocoDelegations Administrator controls which AI clients are approved and can withdraw any of them at any time.
• Beta scope is deliberately small. Today the connector exposes one diagnostic tool that confirms the connection works. Delegation data tools, and Administrator write tools, follow during the beta as described in section 5.

3. How it works

3.1 The pieces

Three things are involved: your council’s LocoDelegations web application, an AI client, and the council user sitting in between.

3.2 The connection sequence

The first time a user connects an AI client, the following happens. Every step uses standard, documented protocols; there is nothing proprietary in the exchange.

1. The AI client contacts the MCP endpoint at https://<your LocoDelegations address>/mcp and receives a 401 response that tells it where the authorisation server is.
2. The client reads the published discovery documents and learns the authorise and token addresses.
3. The client opens the LocoDelegations login page in the user’s browser. This is the ordinary LocoDelegations login: username and password for councils using local accounts, or Sign in with Microsoft for councils using Azure AD. If the user already has a Microsoft session in that browser, the sign-in usually completes without re-entering credentials.
4. After sign-in, LocoDelegations issues the client a short-lived access token and a refresh token, bound to that user, their email and their LocoDelegations role.
5. From then on the client sends the access token with every MCP call. LocoDelegations validates the token, identifies the user and role, and answers. When the access token expires the client silently exchanges the refresh token for a new one.

There is no consent screen beyond the login itself. The set of AI clients that may connect is controlled by the client registrations described in section 4.4, not by individual users.

3.3 Endpoints exposed on your instance

All of these are served from your existing LocoDelegations address over HTTPS. No new hostnames, ports or firewall rules are involved.

4. Security and identity

4.1 Who can connect

Only people who already have a LocoDelegations account on your instance can connect an AI client, because the only way to obtain a token is to complete the LocoDelegations login. A person with no account, or a deactivated account, cannot sign in and therefore cannot obtain a token.

During the beta, any authenticated user may connect regardless of role, because the only tool currently exposed reveals nothing but the caller’s own identity. When delegation data tools are added, access to each tool will follow the same role model the web application uses today (Administrator, Editor, UserManager, HelpEditor, Viewer). The user’s role is carried inside the token, so the connector always knows who is asking.

4.2 Azure AD and multi-factor authentication

Azure AD stays exactly where it is today: an identity provider for the LocoDelegations login. LocoDelegations does not ask Azure AD to issue tokens for the AI client, and no new Azure AD application registration or API permission is needed in your tenant. Your existing Conditional Access and MFA policies apply at the moment the user signs in, because that sign-in is the same Microsoft login the web application already uses.

For councils using local LocoDelegations accounts, the application’s own requirement that Administrators enable MFA continues to apply to the web interface. That check is a property of the browser session and is not re-applied to individual MCP calls, which carry tokens rather than browser cookies.

4.3 Tokens

4.4 Client registrations

An AI client can only start the login flow if it has been registered on your instance with a matching redirect address. Registrations live in your council’s own database. There is no dynamic self-registration: an unknown client is rejected before the user ever sees a login page.

Two registrations are pre-defined rather than typed in by your Administrator, because their redirect addresses are fixed and published by the vendor:

Copilot Studio and ChatGPT generate their redirect address inside their own setup process, so they cannot be pre-registered. Your LocoDelegations Administrator registers them on the AI Client Settings page, which generates a client ID to paste back into the vendor’s tool. That page can also edit or delete those registrations. The two pre-defined registrations are shown read-only, since their redirect addresses are set by the vendor and cannot be changed.

4.5 Removing access

There are three levels at which access can be withdrawn.

• One user. Deactivate or delete their LocoDelegations account as you do today. They can no longer sign in, so they cannot obtain new tokens. Any access token they already hold keeps working until it expires, within the hour.
• One AI client. Delete its registration on the AI Client Settings page. All stored authorisations and refresh tokens for that client are removed with it, so nobody can refresh through that client again.
• The whole feature for your council. Ask Locosoft to disable it. Because the MCP endpoint only accepts tokens issued by your own instance for registered clients, removing the registrations is sufficient to stop all AI access.

4.6 What the AI vendor receives

This is the question most councils ask first, and the answer depends on the AI vendor you choose rather than on LocoDelegations.

• LocoDelegations returns only the result of the specific tool the assistant called, for the specific user who is signed in. It does not bulk-export, synchronise or index your data for the vendor.
• Whatever the tool returns becomes part of the conversation inside the AI vendor’s service, in the same way as text a user pastes into that assistant. The vendor’s own terms, data-residency commitments and retention rules govern it from that point. For Copilot Studio that means your Microsoft 365 tenant’s existing agreements; for Claude and ChatGPT it means the plan your council holds with Anthropic or OpenAI.
• Because every tool is role-scoped, the assistant can never see or do more than the signed-in user could already see or do in the LocoDelegations web interface.

Locosoft recommends that councils connect the AI Connector only to an AI service already approved for council data, on a business or enterprise plan where the vendor commits not to train on customer content.

4.7 Logging and audit

• Live today. Every registration, edit or deletion of a client on the AI Client Settings page is written to the LocoDelegations change log with the administrator’s identity, matching how other administrative actions are recorded. Requests to the MCP and OAuth endpoints are captured in the application’s standard Azure Application Insights telemetry, which Locosoft uses for operational monitoring.
• Roadmap. A per-call audit record (who asked, which tool, when) written to the LocoDelegations change log, so that AI queries can be reviewed inside the application alongside other user activity. This is planned to land with the first delegation data tools. Changes made through Administrator write tools will be recorded in the change log in the same way as changes made in the browser.

4.8 Software components

For teams that maintain a software inventory or run their own vulnerability tracking, the connector is built from these components inside the existing ASP.NET Core application.

5. What the connector can do: today and roadmap

5.1 Available now

Nothing else is exposed in the beta build. This is intentional: it lets councils complete the security review, connect their chosen AI client and confirm the login experience before any delegation data is reachable.

5.2 During the beta: delegation data tools

The following tools are designed and will be released during the beta programme. All are read-only and available to every role. Each will honour the caller’s LocoDelegations role, so a Viewer through an AI client sees what a Viewer sees in the browser.

5.3 During the beta: Administrator write tools

The beta also introduces tools that let an Administrator make changes through an AI client. Three rules apply to every one of them:

• Administrator role only. The role is read from the token on every call. A user in any other role is refused, whatever the assistant asks for.
• Same validation as the web interface. A write tool goes through the same checks the corresponding LocoDelegations page applies, so the assistant cannot create a record the page would reject.
• Every change is logged. Each write produces a change-log entry in the Administrator’s name, exactly as a change made in the browser does, so the audit trail is complete regardless of how the change was made.

The specific changes supported will be agreed with the councils taking part in the beta, and each will be described in this guide when it is released.

5.4 During the beta: platform items

• Per-call audit records in the LocoDelegations change log (section 4.7).
• Re-checking the user’s account and role each time a token is refreshed.
• Role-based restriction on the MCP endpoint itself, once data and write tools exist.
• Automatic client registration (dynamic client registration or client ID metadata documents) when the underlying OAuth library supports it. This would remove the manual registration step for Copilot Studio and ChatGPT.

5.5 Explicitly out of scope

• Write access for any role other than Administrator.
• A central, multi-council AI service. Each council’s connector remains inside its own instance.
• Any change to how your council signs in to LocoDelegations today.

6. Before you connect

6.1 Prerequisites

6.2 Network and firewall

• No new inbound ports, hostnames or certificates. Everything is served on the existing HTTPS address.
• Hosted AI clients (Copilot Studio, Claude, ChatGPT) connect to your instance from the vendor’s cloud. If your council restricts access to LocoDelegations by source IP address, the vendor’s published address ranges will need to be permitted. Locosoft can confirm whether such a restriction is in place on your instance.
• Claude Code connects from the user’s own workstation and completes login through a browser redirect to localhost port 33418 on that workstation. Endpoint security software that blocks local loopback listeners would need an exception.
• Users need normal outbound HTTPS access to their AI vendor, which they will already have if they use the assistant today.

6.3 Finding the values you will need

Sign in to LocoDelegations as an Administrator and open Setup, then AI Client Settings. The page shows the client IDs registered on your instance and the exact command or field values for each vendor. Use the values from that page in preference to the examples below.

7. Connecting Microsoft Copilot Studio

Copilot Studio adds MCP servers as tools on an agent. It offers three OAuth modes. Two of them, Dynamic discovery and Dynamic, rely on the server supporting automatic client registration, which LocoDelegations does not yet provide. Use Manual mode. The sequence matters, because Copilot Studio only reveals its redirect address after you begin creating the tool.

Once configured, IT can publish the Copilot Studio agent centrally and assign it to selected users or groups through the Microsoft 365 admin centre; end users do not add the connector themselves. The LocoDelegations connection remains per user: on first use Copilot prompts the user to connect. For Entra councils this will normally complete using the user’s existing Microsoft sign-in, and is then remembered subject to the token lifetimes in section 4.3.

7.1 Steps

1. In Copilot Studio, open the agent that should have access, go to Tools, choose Add a tool, then New tool, then Model Context Protocol.
2. Enter the server address https://<your LocoDelegations address>/mcp and a name such as “LocoDelegations”.
3. For authentication choose OAuth 2.0, then Manual. Copilot Studio displays a redirect URL for this connector. Copy it.
4. In another tab, sign in to LocoDelegations as an Administrator, open Setup, then AI Client Settings. Under Add a client, enter a name (for example “Copilot Studio – Compliance agent”) and paste the redirect URL. Click Add client. The page shows the generated client ID; copy it.
5. Back in Copilot Studio, complete the manual OAuth settings using the table below, then save the tool.
6. Test the agent. The first call prompts the user to connect to LocoDelegations. For an Entra council this will normally complete using the user’s existing Microsoft sign-in. Ask the agent to “check my LocoDelegations connection”; it should call the status tool and report your council name, the user and their role.

7.2 Values for the manual OAuth screen

Each Copilot Studio connector has its own redirect URL, so if you build the tool on a second agent or in a second environment, register it as a separate client with its own name. Registrations are cheap and independently deletable. This registration is for the agent/connector, not each end user; the published agent can be centrally assigned to users or groups.

8. Connecting Claude

8.1 Claude web, Desktop and mobile

All hosted Claude surfaces share one connector configuration, so setting it up once in Claude’s settings makes it available in the web app, the desktop app and mobile. Custom connectors require a Claude plan that supports them; for council use that will normally be a Team or Enterprise plan administered by the council.

1. In Claude, open Settings, then Connectors, and choose Add custom connector.
2. Enter a name and the server address https://<your LocoDelegations address>/mcp.
3. Expand Advanced settings. In OAuth Client ID enter claude. Leave the client secret blank.
4. Click Add, then Connect. A browser window opens on the LocoDelegations login page. Sign in as normal.
5. Back in Claude, start a conversation and ask it to check the LocoDelegations connection. It should report your council, your name and your role.

On Team and Enterprise plans an organisation owner can add the connector centrally so that individual users only need to click Connect and sign in.

8.2 Claude Code

Claude Code is Anthropic’s command-line tool, typically used by developers and technical staff. It completes the OAuth login through a temporary listener on the user’s own machine, and that listener must use the port LocoDelegations has registered.

claude mcp add --transport http locodelegations https://<your LocoDelegations address>/mcp --callback-port 33418

Alternatively set the environment variable MCP_OAUTH_CALLBACK_PORT=33418 or the oauth.callbackPort setting in Claude Code’s configuration. Then run /mcp inside Claude Code to trigger the login. The port must be 33418; any other port will be rejected by LocoDelegations because the redirect address will not match the registration.

9. Connecting ChatGPT

ChatGPT supports custom MCP connectors on its Business, Enterprise and Edu plans. Its current connector design generates a unique redirect address per connector, which cannot be pre-registered. ChatGPT still honours an older fixed redirect address, and that is what the beta uses.

1. In LocoDelegations, open Setup, then AI Client Settings. Under Add a client, enter a name such as “ChatGPT” and the redirect URI https://chatgpt.com/connector_platform_oauth_redirect. Click Add client and copy the generated client ID.
2. In ChatGPT, open the connector or apps settings for your workspace and create a custom MCP connector pointing at https://<your LocoDelegations address>/mcp.
3. Choose OAuth authentication and paste the client ID. Leave the client secret blank.
4. Connect, sign in to LocoDelegations when prompted, and ask ChatGPT to check the LocoDelegations connection.

10. Questions IT teams commonly ask

11. Glossary

Document status: draft for the beta programme. Locosoft will revise this guide as delegation data tools are released and as the AI vendors’ setup screens change. Feedback from council IT teams during the beta is welcome and will be incorporated.