Pharus with Claude and other AI agents: how the MCP server works

In short

• What it is: a server Pharus runs at https://mcp.pharussecurity.com/mcp that connects AI assistants to your Pharus workspace. You add the address to your assistant; there’s nothing to install.
• What an agent can do: read vulnerabilities, incidents, deadlines, SBOMs, security advisories and the audit trail, register a vulnerability, and propose text for a CRA report.
• What it can’t do: start a clock, decide whether something is actively exploited, approve, file, publish, send or close anything. Those need a person signed in to Pharus, and no token can do them.
• Who decides: an owner or admin allows agents for the workspace. Each person then connects their own, and it has no more rights than they do.
• Where data goes: what the agent reads goes to your assistant and whoever runs its model, under your agreement with them.
• Plans: every plan and the free trial. A read-only workspace can only read.

What MCP is

The Model Context Protocol is an open standard, published by Anthropic in November 2024, for connecting AI assistants to the systems people work in. A system offers a set of named tools, each with a description and the inputs it takes. The assistant reads the descriptions, picks the tool that answers the question, calls it, and works with what comes back. Claude, Claude Code, Cursor and VS Code support it, among others.

For Pharus, that means you can ask in plain words, such as “What’s due in the next 24 hours?”, and the assistant fetches the answer from your workspace. Every item it gets back has a link into Pharus, so it can send you to the page where you act.

How a request travels

1. You ask your assistant a question, or give it a task.
2. It picks a tool, such as list_deadlines, and sends the call to the Pharus MCP server with your token. Most assistants show you the call, and can ask before they run it.
3. The MCP server passes it to the Pharus API. It runs in Stockholm and handles each request on its own. It keeps nothing: your token passes through and is never stored or logged there.
4. Pharus checks the request, every time: that the token is valid, that its person is still a confirmed member of the workspace, with two-step verification where the workspace requires it, that the workspace allows agents, and, for a write, that the workspace isn’t read-only. What the agent may do follows from that person’s rights at that moment, not when it connected.
5. The data goes back to the assistant, which turns it into an answer.

What an agent can do

Read

Register and draft

With the permission Register vulnerabilities and draft reports, which you choose when you connect, an agent can also:

• Register a vulnerability (register_vulnerability) by its CVE, GHSA or EUVD id, or your own id when there isn’t one yet. Pharus opens one incident per product family, being assessed, and no clock starts. Asking twice changes nothing: a family that already has an incident for the id gets that one back.
• Link another product family (link_product_family) to a registered vulnerability. It gets its own incident, with its own clocks and report.
• Read a report pack (get_report_pack): a CRA report’s fields as they stand, what’s missing, and which fields it may propose text for.
• Propose report text (draft_report) for the prose fields of the early warning, the notification or the final report. It stays out of the pack until a person accepts it.

What the agent says when it registers something shows on the incident as its words, for whoever assesses it. It never goes into a report: its text reaches a pack only through a draft a person accepts. Awareness times, identity fields and yes-or-no fields are never an agent’s to fill.

What only people can do

Only a person signed in to Pharus can:

• start or correct the reporting clocks;
• record, approve or decline a decision, such as whether a vulnerability is actively exploited in your product;
• accept an agent’s text into a pack, edit the pack, and mark a report as submitted;
• set a VEX status, record that a fix is available, and close or reopen an incident;
• publish an advisory, reply to someone who reported a vulnerability, inform users, or page whoever is on call.

These limits are in Pharus, not in the agent’s instructions. A token can’t reach them, whatever the agent is told and whatever the person’s role. Filing doesn’t happen in Pharus either: ENISA’s Single Reporting Platform has no API, so a person pastes the report in there.

The line is deliberate. An agent is good at the legwork: finding which products a CVE touches, collecting what’s known, writing a first draft within the field limits. Whether something is actively exploited in your product, and what goes to a CSIRT in your company’s name, should be decided by a person who has read it.

Connect an agent

It takes three steps. An owner or admin does the first once for the workspace; each person who wants an agent does the other two.

Allow agents in the workspace

Every workspace starts with agents off. An owner or admin goes to Settings → API tokens and selects Allow agents. The audit trail records who did it. Stop allowing agents refuses every connected agent from its next request.

Add Pharus to your assistant

• Claude, on the web and in the desktop app: add https://mcp.pharussecurity.com/mcp as a custom connector, then select Connect.
• Claude Code: run claude mcp add --transport http pharus https://mcp.pharussecurity.com/mcp.
• Cursor: add the address as a server in ~/.cursor/mcp.json.
• VS Code: add it under servers in .vscode/mcp.json, with "type": "http".
• Other assistants: any that support remote MCP servers over Streamable HTTP and sign in with OAuth.

Sign in and choose what it may do

1. Your assistant opens Pharus in your browser. Sign in as usual, with two-step verification if you use it.
2. Check who is asking. The page shows the name the agent gave itself and the address it will send you back to. Unverified means it only named itself. Connect it only if you started this and trust that address.
3. Choose the workspace. A connection belongs to one.
4. Choose what it may do. Read the workspace is always on. Untick Register vulnerabilities and draft reports for an agent that should only read.
5. Select Connect, and you’re back in your assistant.

Allowing agents and connecting one are separate steps on purpose: a link from someone else shouldn’t be one click away from opening your workspace.

Without sign-in: a read token

An assistant that can’t sign in can still read. An owner or admin creates a token under Settings → API tokens → Create token and chooses Read workspace data (MCP server and API). The assistant sends it as Authorization: Bearer phr_…. A read token reads the whole workspace, changes nothing and gets only the read tools. It stops working if the person who created it leaves the workspace or stops being an owner or admin.

Writing always needs a person who has signed in, so every change has a name on it. No agent writes on its own with nobody behind it.

An example: from a supplier’s advisory to an early warning

Nordmann Elektronikk AS, the made-up manufacturer from our early warning example, gets an advisory from a supplier: a flaw in a network module used in two of its products. None of the public feeds lists it yet.

1. The request. A product manager pastes the advisory into Claude: “Register this for NE Gateway 4 and NE Sensor 2, and draft the early warning from it.”
2. Registering. The agent finds the two product families with list_product_families and calls register_vulnerability with the supplier’s id and a summary of the advisory. Pharus opens two incidents, both being assessed. No clock runs. Owners and admins get an email, and so do the workspace’s Slack, Teams and webhook destinations.
3. The assessment. A person opens each incident and decides whether the flaw is actively exploited in that product. If it is, they record it with the time they became reasonably certain, and the 24-hour clock runs from then. If nobody has assessed an incident after four hours, Pharus sends the usual reminder and pages whoever is on call.
4. The draft. The agent reads the early warning’s pack with get_report_pack and proposes text for the fields it may write, in English, as the SRP is English-only. Where it doesn’t know something, it marks the gap instead of guessing, such as [[date of first exploitation]].
5. The review. The incident’s SRP pack tab says a draft is waiting, from whom and with what note. Review the draft opens the pack with the agent’s text filled in where the field was empty, marked Agent. Gaps count as missing, and Pharus flags ids and links that aren’t in the incident’s record. Save pack makes the text yours; Dismiss drops it.
6. The filing. A person pastes the pack into ENISA’s Single Reporting Platform and selects Mark as submitted.

The audit trail shows each step and who took it: “Claude (agent) for Kari Nordmann” registered the vulnerability and proposed the text, and named people assessed, accepted and filed. When the report is marked as submitted, the entry also counts the fields filed exactly as the agent wrote them.

Agents can open at most 20 incidents per workspace in 24 hours. If a feed such as CISA KEV lists the vulnerability later, Pharus opens its own incident and alerts as usual; a person closes one of them as a duplicate. When the legal 24 hours start is a question of its own: see When is a vulnerability “actively exploited”?

Questions to try

• “Which actively exploited vulnerabilities affect our products, and which have no owner?”
• “What’s due in the next 24 hours?”
• “Summarise INC-0042 for management: what happened, what we decided, what we’ve filed.”
• “Which components in NE Gateway 4 version 4.2 are past end of life upstream?”
• “Is CVE-2024-3094 in any of our SBOMs?”
• “What did agents do in the workspace this week?”

Your data: what the agent sees, and where it goes

What the tools return goes to your assistant, and from there to whoever runs its model, under your agreement with them. Pharus doesn’t choose or control that provider. Before you connect one, check that its data terms fit how you handle vulnerability information, for example zero data retention or processing in the EU.

That’s separate from Pharus’s own AI assistance, which is off until an owner or admin turns it on, and runs through sub-processors Pharus has chosen. Data processing describes it. An agent you connect is your own choice.

• Included: your workspace’s vulnerability and incident data, free text your people wrote, such as incident summaries, decision rationales and VEX notes, and people’s names.
• Never sent: disclosure reports and reporters’ details, email addresses in the audit trail, why someone is off call, and member ids. The read tools leave out report drafts too; an agent allowed to draft sees the pack of the report it’s working on.
• Text from outside: public vulnerability descriptions and SBOM component names come from outside your workspace, and text like that could try to steer an assistant. The server tells the model to treat it as data, not instructions. Keep your assistant’s approval step on for any other tool that can send data out.

Tokens, limits and the audit trail

• Tokens are issued for this server alone and belong to one person in one workspace. An access token lasts one hour and a refresh token 30 days. Each refresh replaces the refresh token, and reusing an old one ends them all for that agent and person. Pharus stores only a hash of each token.
• Disconnecting: under Settings → API tokens, Disconnect ends an agent’s access at once. Everyone sees the agents they connected; owners and admins see all of them and can disconnect any. An agent is also disconnected when the person who connected it leaves the workspace or resets their password.
• The audit trail records an agent as itself, on behalf of the person who connected it. Filter by Actor → Agents to see what agents did. An agent’s name is what its client calls itself, so it isn’t proof of who it is; the person who connected it and the address it sent them back to are what you can rely on.

Read more

The documentation has the details: the MCP server, with every tool and scope and the OAuth details for client authors, working with an agent day to day, and the HTTP endpoints behind the register and draft tools. For what an early warning holds, see A CRA early warning, filled in.