Geheimen met omgevingsvariabelen

In .mcp.json geef je inloggegevens door via het env-blok van de server, met expansie van ${VAR}. De letterlijke tekst ${GITHUB_TOKEN} wordt veilig vastgelegd — het echte token wordt tijdens het starten uit de omgeving opgehaald.

De GitHub MCP-server ontvangt hier zijn token zonder dat het geheim ooit het bestand aanraakt.

De verwijzing ${GITHUB_TOKEN} doet niets totdat de runtime de werkelijke waarde aanlevert. Je geeft die door via je shellomgeving — meestal vanuit een lokaal, door git genegeerd .env-bestand of de geheimenopslag van je besturingssysteem.

Het token wordt buiten de repository ingesteld. De gecommitte configuratie blijft schoon; elke ontwikkelaar (en elke CI-runner) injecteert zijn of haar eigen waarde.

Een omgevingsvariabele gebruiken is slechts de helft van de beveiliging. Je moet ook garanderen dat het bestand met de echte waarde nooit wordt gecommit.

Voeg je bestanden met geheimen toe aan .gitignore. Commit een voorbeeldbestand met namen als tijdelijke aanduidingen, zodat teamgenoten weten welke variabelen ze moeten instellen — zonder de waarden ooit mee te leveren.

De scope bepaalt ook van wie de referentie wordt gebruikt:

• Een gedeeld servicetoken dat het hele team gebruikt, kan worden opgenomen in de projectconfiguratie .mcp.json — elk teamlid levert de waarde nog steeds via zijn of haar eigen omgeving.
• Een puur persoonlijk token (je individuele PAT) past natuurlijk bij de gebruikersscope ~/.claude.json, die toch niet wordt gedeeld.

In beide gevallen geldt hetzelfde principe: het bestand mag de naam bevatten; de omgeving levert de waarde. Draai dit nooit om.

Geef voor standaardintegraties — GitHub, Postgres, Slack en het bestandssysteem — de voorkeur aan een onderhouden MCP-server van de community boven een aangepaste server. Ze implementeren het verwerken van geheimen op basis van env al correct, bieden de juiste Tools/Resources/Prompts aan en geven gestructureerde fouten terug.

Je eigen server schrijven om alleen GitHub aan te roepen, betekent dat je authenticatie en tokenverwerking opnieuw moet implementeren, terwijl je die veilig had kunnen overnemen. Gebruik aangepaste servers alleen voor systemen die echt bedrijfseigen zijn.

In een pipeline is er geen .env-bestand van een ontwikkelaar om in te lezen. In plaats daarvan injecteert de versleutelde geheimenopslag van je CI-platform de variabele in de omgeving van de taak, en wordt dezelfde verwijzing ${GITHUB_TOKEN} op identieke wijze ingevuld.

Daarom is het verwijzingspatroon belangrijk: één gecommitte .mcp.json werkt lokaal en in CI, waarbij de waarde op elke plek anders wordt aangeleverd — en nooit wordt afgedrukt.

Een MCP-token krijgt alle machtigingen die je eraan hebt toegekend. Een GitHub PAT met de scope repo kan code pushen; een token met de scope read:org kan dat niet.

Pas de gewoonte van de architect om minimale bevoegdheden te gebruiken ook toe op het ontwerp van tools en subagents: geef elk token alleen de scopes die de server daadwerkelijk nodig heeft. Als ${GITHUB_TOKEN} ondanks je beveiligingsmaatregelen toch uitlekt, beperkt een token met een strikt beperkte scope en korte geldigheidsduur de schade aanzienlijk.

Behandel elk gecommit geheim als gecompromitteerd — zelfs nadat je het hebt verwijderd, blijft het in de git-geschiedenis staan. De enige echte oplossing is de referentie bij de bron in te trekken en te roteren (in de GitHub-instellingen), en vervolgens een nieuwe in je omgeving te plaatsen.

Omdat je configuratie naar ${GITHUB_TOKEN} verwijst in plaats van een waarde in te sluiten, verloopt roteren probleemloos: trek het oude token in, werk de omgevingsvariabele bij en start opnieuw. Geen codewijziging en geen commit.

Het volledige patroon voor MCP-geheimen, zoals je dat op een examen moet kennen:

• Declareer de server in het projectbestand .mcp.json (gedeeld via versiebeheer).
• Verwijs in het blok env naar het geheim als ${GITHUB_TOKEN} — nooit naar de onbewerkte waarde.
• Lever de waarde lokaal vanuit een door git genegeerd .env-bestand en in CI vanuit een versleutelde opslag.
• Negeer bestanden met geheimen; commit alleen een .env.example met namen.
• Beperk tokens tot minimale bevoegdheden en roteer ze bij elk vermoeden van misbruik.

Configuratie kan worden gedeeld; geheimen niet. Die scheiding is de essentie.

Belangrijkste punten:

• MCP-configuratie heeft twee scopes: project .mcp.json (gedeeld via versiebeheer) en gebruiker ~/.claude.json (persoonlijk).
• Gecommitte configuratie mag een verwijzing zoals ${GITHUB_TOKEN} bevatten — nooit de waarde van het token.
• Echte waarden komen lokaal uit een door git genegeerd .env-bestand en in CI uit een versleutelde geheimenopslag; commit alleen een .env.example met namen.
• Geef de voorkeur aan MCP-servers van de community — zij verwerken geheimen op basis van omgevingsvariabelen meteen correct.
• Beperk tokens tot minimale bevoegdheden; trek ze bij elk lek bij de bron in en roteer ze — dankzij het verwijzingspatroon is roteren een wijziging van één regel in een omgevingsvariabele.

Scheid wat gedeeld kan worden van wat geheim moet blijven, en je hebt de regel die in het examen wordt getoetst goed begrepen.