Sign-in and access

Signing in

Assistants sign in with OAuth, the usual way to let one app act for you in another. The front plays the part MCP expects of a server:

• each address has its own protected-resource document, which tells the assistant where to sign in;
• one authorization server serves every address. It accepts a client that describes itself by a URL (a Client ID Metadata Document) and one that registers itself (dynamic client registration);
• before sending you to GitHub, it shows a consent page that names the client asking. It appears on every sign-in.

GitHub then signs you in, with the major-vault App as the client. Your GitHub token goes back to the assistant; the front keeps no token and no session. The token lasts 8 hours, and the assistant renews it through the front.

Who sees what

Reading follows GitHub, within the repositories the admin chose for the App:

• A person reads every chosen repository they can read on GitHub. A repository they cannot read appears nowhere: not in results, not in tool names, not in the instructions.
• The tool list depends on the person. It holds the basic tools, the names of their readable repositories, and the special tools of those.
• A change of access takes effect within 15 minutes, the time the front and the instance keep a person’s list of repositories.

Who writes what

• Writing needs write access on GitHub. Every write runs with the person’s own token, so GitHub checks their rights on each commit and names them as its author.
• One call, one repository. A call changes one repository; a move from one repository to another is refused.
• A special tool works only in its own repository.