Pharus med Claude og andre AI-agenter: slik fungerer MCP-serveren

Kort fortalt

• Hva det er: en server Pharus drifter på https://mcp.pharussecurity.com/mcp, som kobler AI-assistenter til arbeidsområdet deres i Pharus. Dere legger adressen inn i assistenten; det er ingenting å installere.
• Hva en agent kan gjøre: lese sårbarheter, hendelser, frister, SBOM-er, sikkerhetsvarsler og revisjonsloggen, registrere en sårbarhet og foreslå tekst til en CRA-rapport.
• Hva den ikke kan gjøre: starte en klokke, avgjøre om noe er aktivt utnyttet, godkjenne, sende inn, publisere, sende eller lukke noe. Det krever en person som er logget inn i Pharus, og det kan ikke gjøres med et token.
• Hvem som bestemmer: en eier eller administrator tillater agenter i arbeidsområdet. Hver person kobler så til sin egen, og den har ikke flere rettigheter enn personen selv.
• Hvor dataene går: det agenten leser, går til assistenten deres og den som driver modellen, etter avtalen dere har med dem.
• Planer: alle planer og prøveperioden. Et skrivebeskyttet arbeidsområde kan bare lese.

Hva MCP er

Model Context Protocol er en åpen standard, lansert av Anthropic i november 2024, for å koble AI-assistenter til systemene folk jobber i. Et system tilbyr et sett med navngitte verktøy, hvert med en beskrivelse og hva det tar imot. Assistenten leser beskrivelsene, velger verktøyet som svarer på spørsmålet, kaller det og jobber videre med det som kommer tilbake. Claude, Claude Code, Cursor og VS Code støtter det, blant andre.

For Pharus betyr det at dere kan spørre med vanlige ord, som «Hva har frist de neste 24 timene?», og assistenten henter svaret fra arbeidsområdet. Alt den får tilbake, har en lenke inn i Pharus, så den kan sende dere til siden der dere handler.

Slik går en forespørsel

1. Du spør assistenten om noe, eller gir den en oppgave.
2. Den velger et verktøy, som list_deadlines, og sender kallet til MCP-serveren til Pharus med tokenet ditt. De fleste assistenter viser deg kallet, og kan spørre før de kjører det.
3. MCP-serveren sender det videre til Pharus-API-et. Den kjører i Stockholm og behandler hver forespørsel for seg. Den tar ikke vare på noe: tokenet går gjennom og blir aldri lagret eller logget der.
4. Pharus sjekker forespørselen hver gang: at tokenet er gyldig, at personen det tilhører, fortsatt er bekreftet medlem av arbeidsområdet, med totrinnsbekreftelse der arbeidsområdet krever det, at arbeidsområdet tillater agenter, og ved skriving at arbeidsområdet ikke er skrivebeskyttet. Hva agenten får gjøre, følger av personens rettigheter i øyeblikket, ikke da den ble koblet til.
5. Dataene går tilbake til assistenten, som gjør dem om til et svar.

Hva en agent kan gjøre

Lese

Registrere og skrive utkast

Med tilgangen Registrere sårbarheter og skrive utkast til rapporter, som du velger når du kobler til, kan en agent også:

• Registrere en sårbarhet (register_vulnerability) med CVE-, GHSA- eller EUVD-ID-en, eller deres egen ID når det ikke finnes noen ennå. Pharus åpner én hendelse per produktfamilie, til vurdering, og ingen klokke starter. Å spørre to ganger endrer ingenting: en familie som allerede har en hendelse for ID-en, får den tilbake.
• Legge til en produktfamilie (link_product_family) på en registrert sårbarhet. Den får sin egen hendelse, med egne klokker og egen rapport.
• Lese en rapportpakke (get_report_pack): feltene i en CRA-rapport slik de står, hva som mangler, og hvilke felt den kan foreslå tekst til.
• Foreslå rapporttekst (draft_report) til fritekstfeltene i den tidlige varslingen, varslingen eller sluttrapporten. Teksten holdes utenfor pakken til en person godtar den.

Det agenten skriver når den registrerer noe, vises på hendelsen som dens ord, for den som vurderer den. Det havner aldri i en rapport: teksten når en pakke bare gjennom et utkast en person godtar. Kjennskapstidspunkt, identitetsfelt og ja/nei-felt fyller agenten aldri ut.

Hva bare folk kan gjøre

Bare en person som er logget inn i Pharus, kan:

• starte eller korrigere rapporteringsklokkene;
• registrere, godkjenne eller avvise en avgjørelse, for eksempel om en sårbarhet er aktivt utnyttet i produktet deres;
• godta tekst fra en agent inn i en pakke, redigere pakken og markere en rapport som sendt inn;
• sette en VEX-status, registrere at en retting er tilgjengelig, og lukke eller gjenåpne en hendelse;
• publisere et sikkerhetsvarsel, svare noen som har meldt en sårbarhet, informere brukere eller tilkalle den som har vakt.

Grensene ligger i Pharus, ikke i instruksjonene til agenten. Et token kan ikke nå dem, uansett hva agenten blir bedt om og hvilken rolle personen har. Innsendingen skjer heller ikke i Pharus: ENISAs Single Reporting Platform har ikke noe API, så en person limer inn rapporten der.

Skillet er med vilje. En agent er god på grovarbeidet: finne ut hvilke produkter en CVE treffer, samle det som er kjent, og skrive et første utkast innenfor feltgrensene. Om noe er aktivt utnyttet i produktet deres, og hva som sendes til en CSIRT i selskapets navn, bør avgjøres av en person som har lest det.

Koble til en agent

Det tar tre steg. Det første gjør en eier eller administrator én gang for arbeidsområdet; de to andre gjør hver person som vil bruke en agent.

Tillat agenter i arbeidsområdet

Alle arbeidsområder starter med agenter slått av. En eier eller administrator går til Innstillinger → API-tokens og velger Tillat agenter. Revisjonsloggen viser hvem som gjorde det. Slutt å tillate agenter avviser alle tilkoblede agenter fra neste forespørsel.

Legg Pharus inn i assistenten

• Claude, på nett og i skrivebordsappen: legg til https://mcp.pharussecurity.com/mcp som en egendefinert kobling (custom connector), og velg Connect.
• Claude Code: kjør claude mcp add --transport http pharus https://mcp.pharussecurity.com/mcp.
• Cursor: legg adressen inn som en server i ~/.cursor/mcp.json.
• VS Code: legg den inn under servers i .vscode/mcp.json, med "type": "http".
• Andre assistenter: alle som støtter eksterne MCP-servere over Streamable HTTP og innlogging med OAuth.

Logg inn og velg hva den kan gjøre

1. Assistenten åpner Pharus i nettleseren. Logg inn som vanlig, med totrinnsbekreftelse hvis du bruker det.
2. Sjekk hvem som spør. Siden viser navnet agenten har gitt seg selv, og adressen den sender deg tilbake til. Ikke bekreftet betyr at den bare har navngitt seg selv. Koble den til bare hvis du startet dette og stoler på den adressen.
3. Velg arbeidsområdet. En tilkobling hører til ett.
4. Velg hva den kan gjøre. Lese arbeidsområdet er alltid på. Fjern haken for Registrere sårbarheter og skrive utkast til rapporter for en agent som bare skal lese.
5. Velg Koble til, så er du tilbake i assistenten.

Å tillate agenter og å koble til en er to steg med vilje: en lenke fra noen andre skal ikke være ett klikk fra å åpne arbeidsområdet deres.

Uten innlogging: et lesetoken

En assistent som ikke kan logge inn, kan likevel lese. En eier eller administrator oppretter et token under Innstillinger → API-tokens → Opprett token og velger Lese data i arbeidsområdet (MCP-server og API). Assistenten sender det som Authorization: Bearer phr_…. Et lesetoken leser hele arbeidsområdet, endrer ingenting og får bare leseverktøyene. Det slutter å virke hvis den som opprettet det, forlater arbeidsområdet eller ikke lenger er eier eller administrator.

Skriving krever alltid at en person har logget inn, så hver endring har et navn på seg. Ingen agent skriver på egen hånd uten at noen står bak.

Et eksempel: fra en leverandørs sikkerhetsvarsel til en tidlig varsling

Nordmann Elektronikk AS, den oppdiktede produsenten fra eksempelet vårt på en tidlig varsling, får et sikkerhetsvarsel fra en leverandør: en feil i en nettverksmodul som sitter i to av produktene deres. Ingen av de offentlige kildene har den ennå.

1. Forespørselen. En produktansvarlig limer varselet inn i Claude: «Registrer dette for NE Gateway 4 og NE Sensor 2, og skriv utkast til den tidlige varslingen.»
2. Registreringen. Agenten finner de to produktfamiliene med list_product_families og kaller register_vulnerability med leverandørens ID og et sammendrag av varselet. Pharus åpner to hendelser, begge til vurdering. Ingen klokke går. Eiere og administratorer får e-post, og det samme gjør mottakerne i Slack, Teams og webhooks.
3. Vurderingen. En person åpner hver hendelse og avgjør om feilen er aktivt utnyttet i det produktet. Er den det, registrerer personen det med tidspunktet de ble rimelig sikre, og 24-timersklokken går fra da. Har ingen vurdert en hendelse etter fire timer, sender Pharus den vanlige påminnelsen og tilkaller den som har vakt.
4. Utkastet. Agenten leser pakken for den tidlige varslingen med get_report_pack og foreslår tekst til feltene den kan skrive, på engelsk, siden SRP bare tar engelsk. Der den ikke vet noe, markerer den hullet i stedet for å gjette, som [[date of first exploitation]].
5. Gjennomgangen. Fanen SRP-pakke på hendelsen viser at et utkast venter, fra hvem og med hvilket notat. Gå gjennom utkastet åpner pakken med teksten fra agenten fylt inn der feltet var tomt, merket Agent. Hull teller som mangler, og Pharus flagger ID-er og lenker som ikke står i opplysningene om hendelsen. Lagre pakken gjør teksten til deres; Avvis forkaster den.
6. Innsendingen. En person limer pakken inn i ENISAs Single Reporting Platform og velger Marker som sendt inn.

Revisjonsloggen viser hvert steg og hvem som tok det: «Claude (agent) for Kari Nordmann» registrerte sårbarheten og foreslo teksten, og navngitte personer vurderte, godtok og sendte inn. Når rapporten markeres som sendt inn, teller oppføringen også feltene som ble sendt inn akkurat slik agenten skrev dem.

Agenter kan åpne høyst 20 hendelser per arbeidsområde i løpet av 24 timer. Dukker sårbarheten senere opp i en kilde som CISA KEV, åpner Pharus sin egen hendelse og varsler som vanlig; en person lukker den ene som duplikat. Når de lovpålagte 24 timene starter, er et eget spørsmål: se Når er en sårbarhet «aktivt utnyttet»?

Spørsmål å prøve

• «Hvilke aktivt utnyttede sårbarheter rammer produktene våre, og hvilke mangler eier?»
• «Hva har frist de neste 24 timene?»
• «Oppsummer INC-0042 for ledelsen: hva skjedde, hva vi bestemte, hva vi har sendt inn.»
• «Hvilke komponenter i NE Gateway 4 versjon 4.2 har mistet oppstrømsstøtten?»
• «Finnes CVE-2024-3094 i noen av SBOM-ene våre?»
• «Hva har agenter gjort i arbeidsområdet denne uka?»

Dere kan spørre på norsk.

Dataene deres: hva agenten ser, og hvor det går

Det verktøyene returnerer, går til assistenten deres og derfra til den som driver modellen, etter avtalen dere har med dem. Pharus velger ikke og styrer ikke den leverandøren. Før dere kobler til en agent, sjekk at vilkårene for data passer med hvordan dere håndterer sårbarhetsinformasjon, for eksempel at ingenting lagres (zero data retention) eller at behandlingen skjer i EU.

Det er noe annet enn AI-assistansen i Pharus, som er av til en eier eller administrator slår den på, og som går gjennom underleverandører Pharus har valgt. Databehandling beskriver den. En agent dere kobler til, er deres eget valg.

• Med: sårbarhets- og hendelsesdataene i arbeidsområdet, fritekst folkene deres har skrevet, som sammendrag av hendelser, begrunnelser for avgjørelser og VEX-notater, og navn på personer.
• Aldri med: sårbarhetsrapporter og opplysninger om dem som meldte dem, e-postadresser i revisjonsloggen, hvorfor noen ikke har vakt, og medlems-ID-er. Leseverktøyene holder også rapportutkast utenfor; en agent som kan skrive utkast, ser pakken for rapporten den jobber med.
• Tekst utenfra: offentlige beskrivelser av sårbarheter og navn på komponenter i SBOM-er kommer utenfra arbeidsområdet, og slik tekst kan prøve å styre en assistent. Serveren ber modellen behandle den som data, ikke som instruksjoner. La godkjenningssteget i assistenten stå på for andre verktøy som kan sende data ut.

Tokens, grenser og revisjonsloggen

• Tokens er utstedt bare for denne serveren og hører til én person i ett arbeidsområde. Et tilgangstoken varer en time og et fornyelsestoken 30 dager. Hver fornyelse bytter ut fornyelsestokenet, og brukes et gammelt, avsluttes alle for den agenten og personen. Pharus lagrer bare en hash av hvert token.
• Frakobling: under Innstillinger → API-tokens fjerner Koble fra tilgangen med en gang. Alle ser agentene de selv har koblet til; eiere og administratorer ser alle og kan koble fra hvilken som helst av dem. En agent kobles også fra når personen som koblet den til, forlater arbeidsområdet eller tilbakestiller passordet sitt.
• Revisjonsloggen viser en agent som seg selv, på vegne av personen som koblet den til. Filtrer på Utført av → Agenter for å se hva agenter har gjort. Navnet på en agent er det klienten kaller seg, så det beviser ikke hvem den er; personen som koblet den til, og adressen den sendte personen tilbake til, er det dere kan stole på.

Les mer

Dokumentasjonen, på engelsk, har detaljene: MCP-serveren med alle verktøy, tilganger og OAuth-detaljene for dem som lager klienter, å jobbe med en agent i hverdagen, og HTTP-endepunktene bak verktøyene for registrering og utkast. Hva en tidlig varsling inneholder, viser Tidlig varsling etter CRA, fylt ut.