Govern agent tools with the MCP Gateway

Publish one MCP endpoint for your AI agents with only the tools you approved. Add servers from the App Catalog, review and pin tool definitions, create a gateway, let people sign in their MCP client with their WASViking account or use a key, require approval for risky actions and protect tool results.

The WASViking^® MCP Gateway gives your AI agents one Model Context Protocol endpoint with only the tools you approved. Every tool definition is scanned and pinned: if a server changes a tool, the tool stops being callable until someone reviews it again. Every call is authorized by your AI Guardian policies, taking into account the risk of what it touches in your WASViking data. A call can require a person's approval, and its result can be masked or withheld before the agent reads it.

Before you start

• The MCP Gateway is an add-on from the Pro plan, contracted on its own. Until it is part of your contract, its screen shows a locked page with Activate, which sends the request to your partner or WASViking sales.
• You need an administrator role, or a role with AI Gateway manage access (it covers both gateways).
• Your MCP client must support the Streamable HTTP transport. Claude Code, Cursor and VS Code do. People sign their client in with their WASViking account (OAuth, no key to copy); automation uses a key. The gateway serves the current revision of the protocol (2026-07-28) and the earlier ones (2025-11-25, 2025-06-18 and 2025-03-26) on the same endpoint, so newer and older clients connect the same way.

Step 1: turn on the MCP Gateway

Open AI Guardian, Protection, MCP Gateway and select Turn on the MCP Gateway. Until it is on, every agent is refused.

Step 2: add servers

The quickest way is the App Catalog: it lists the WASViking servers and servers from the official MCP Registry, each with its verification level (WASViking verified, Customer registered, Unvalidated), how it signs in and its tools. Validate runs the protocol checks against a server; Install adds a validated entry to your servers. Tools of an unvalidated server are never offered to agents.

On Servers you can also add:

• WASViking code analysis (receives source files): an AI client sends a project's source files and WASViking scans them in Code Security, where the project shows a badge naming the AI platform and the person who sent it ("Via MCP · Claude, by Ana Lima"); see Analyse a project's code from Lovable or a coding assistant.
• WASViking security data (read-only): your agents can read your security posture split by module (web and API scanning, code security, supply chain, mobile, external exposure, cloud and infrastructure), the worst open findings of each module, the targets, repositories, assets, hosts and cloud resources WASViking knows, findings searched with every filter of the Findings page, the complete record of one finding (how to fix it, where it is, its lifecycle, a link to open it in the portal and the evidence scrubbed of credentials and secret values), the comparison of two scans, the security of a repository, when a target or a repository was last scanned, a library's advisories, the risk of an asset and recent AI threat detections. Nothing can be changed or started through it; see What agents can see and start (MCP).
• WASViking security actions (starts scans): a web scan of a registered target and a new analysis of a monitored repository, one at a time per target or repository, with a minimum interval, the plan's capacity and a monthly ceiling. Nothing is registered or connected through it. Same guide.
• Lab Simulator: cloud, CI and ticket tools for safe demos and tests. Write and destructive tools answer with a simulated result and never change anything.
• A remote MCP server: its Streamable HTTP endpoint (https:// only, reachable from the internet), a trust level and how it signs in: a bearer token, a custom header or OAuth sign-in. Credentials are stored encrypted. Servers on the current or on an earlier protocol revision both work; the gateway finds out which one the server speaks.

Adding a server syncs its tools right away. Remote servers are synced again every six hours, so a tool changed upstream is caught without waiting for you. Use Sync now at any time.

The built-in servers are synced on the same six-hour pass. When a WASViking release adds tools to them, the new tools arrive approved in your list of tools; the tools you already reviewed keep their state. A gateway offers a new tool only after you tick it on that gateway.

Servers in your network or on a host

A server that only your network reaches, or a stdio command, runs behind a WASViking Sentinel agent in that network. The agent keeps its outbound tunnel and only serves what its host declares in /opt/wasviking-sentinel/configs/mcp_connectors.json:

{
  "runner_socket": "/run/wasviking-sentinel-mcp/runner.sock",
  "connectors": [
    {"id": "wiki-internal", "kind": "http", "url": "http://10.0.0.5:8080/mcp"},
    {"id": "files", "kind": "stdio", "command": ["/usr/bin/node", "/opt/mcp/files/server.js"],
     "sha256": "<sha256 of /usr/bin/node>",
     "pins": [{"path": "/opt/mcp/files/server.js", "sha256": "<sha256 of the script>"}],
     "env": {"LOG_LEVEL": "warn"}, "timeout_seconds": 60}
  ]
}

For stdio connectors also run systemctl enable --now wasviking-sentinel-mcp-runner: the commands start in that separate unit, one process per request, only if the executable and the pinned files still match their hashes, and with only the variables you declare. wasviking-sentinel check shows what the agent serves.

Then, on Servers, choose Add a private server (through an agent) or Add a command on an agent host (stdio), pick the agent and type the connector id. The URL or the command never leave the host: the agent refuses any connector it does not declare.

Step 3: review the tools

Tools & Security starts with the review queue: new tools, tools whose definition changed since you approved them, and tools the scanner flagged. Each finding shows the rule, where in the definition it was found and its confidence. Typical findings: a description that asks the agent to read credential files, to send data to an external address, to change how other tools are used, or to hide what it did from the user.

• Approve makes the tool callable at its current definition.
• Accept findings and approve requires a written reason.
• Quarantine removes the tool from every gateway until you decide.
• Show changes compares the approved definition with the one the server offers now.

The built-in servers come approved. Tools of remote servers always wait for a person, and a tool with a high-confidence finding goes straight to quarantine.

In the tool list of the same tab, the Action column shows the action class of each tool and lets you override it. The class decides how the gateway treats the tool, so a wrong class changes decisions:

• Read only looks things up: any sign-in may use it, Turn reads on switches it with its module, and no default rule asks for approval.
• Write changes something (starts a scan, sends code, creates or edits): a sign-in needs the write permission ticked on the permission screen, the recommended protection waits for a person when the target is unknown or high risk, the stricter protection always, and the module switch never turns it on.
• Destructive deletes, disables or revokes: it always waits for a person's approval under the default rules and needs the write permission on a sign-in.
• Unknown could not be classified and is treated as the worst case: write permission on a sign-in, counted as destructive for toolkit limits, left off by the module switch. Classify it.

The class comes from the server's annotations and the tool name (an annotation can make a tool more dangerous than its name says, never less). Your override always wins and is recorded, without changing the approved definition. The fold What each action class means above the list repeats this, and lowering a tool to read asks for confirmation, because it leaves the approval rules and opens to every sign-in.

Step 4: create a gateway and choose its tools

Guided setup: the short way

If you are new to MCP, select Guided setup on Overview & Gateways (the first-use screen offers it too). It asks four questions in plain words and does the rest with safe defaults:

1. What the AI may do: ask about vulnerabilities and fix code, analyse the code of a project sent from the chat, start scans on targets already registered, or follow infrastructure, cloud and certificates. Each card says what the AI will never be able to do.
2. Who will use it: people on your team (they sign in with their WASViking account once MCP access is on for them in Team Management; here you can also restrict the gateway to groups made there), an automation (a key is created and shown once) or both.
3. Which AI client: ChatGPT, Claude on the web, Claude Code, Cursor, VS Code, Lovable or another; this only decides the instructions you get at the end.
4. How much protection: recommended (reads are free; destructive actions and writes on unknown or high-risk targets wait for a person) or stricter (every write waits for a person).

Before creating anything it checks what is missing, with a link to fix it (nobody with MCP access yet, no registered target for scans, an organization that accepts only verified MCP clients). The last screen shows the instructions of the clients you chose, the key once, three questions to ask the AI first and the connection watch, which lights up when the client first reaches the gateway. One rule to keep in mind: when the gateway has action tools, the sign-in page asks each person whether the AI may also act (start scans, send code), ticked by default; a key needs no such page. Your protection level and approvals apply to both. Everything it set up stays editable on the tabs below, and Guided edit on the gateway reopens the same questions with the current answers: it shows what would change before applying, keeps what you set by hand, and never deletes a rule or a key.

Create a gateway by hand

On Overview & Gateways, select New gateway:

Keep Start with secure default rules ticked on a new gateway and it starts with five rules of its own in AI Guardian Policies: destructive tools and writes on unknown or high-risk targets wait for a person's approval, tool results with hidden instructions are withheld, and secrets in tool results are masked. They carry the gateway's name, and you can edit, turn off or delete them like any other rule. Existing gateways never change.

Then tick the tools the gateway offers. On the gateway card the tools come in folds, one per WASViking module (Web & API Security, Code Security and Supply Chain, Infrastructure Defense, Cloud Security, Certificates, Exposure Intelligence, the findings and posture tools that span every module, and one fold per server you added yourself): Turn reads on ticks every approved read tool of the module at once, a write tool always keeps its own box, and the search box finds a tool across the folds. A tool is listed to agents only while it is approved at its current definition and its server is active.

Give each person their own tools: toolkits

A gateway can list the same tools to everyone (Tool source: Tools enabled on this gateway, groups per tool optional) or give each person their own set (Tool source: Toolkits assigned to each person). A toolkit, in the Toolkits tab, is a set of tools with limits:

• tools picked one by one, or every tool of a server, of an action class or whose name starts with a prefix;
• the highest action allowed (read only, read and write, or destructive too);
• for a tool picked one by one, limits on its arguments, for example only the bucket dev-logs;
• whether the toolkit itself requires approval (for writes, or for every call);
• an optional validity window and the gateways it applies to;
• who receives it: directory groups, people or gateway keys.

People still need their own connection on servers that use each person's account, and your policies still decide every call. Dynamic Gateway shows, for a gateway and a person or key, the tools they get and why they do not get the others. A change to a toolkit, a group, a review or a connection reaches the person's list on their next request.

Step 5: connect the client

Client Setup shows the endpoint of each gateway and the exact configuration for two ways of connecting.

People: sign in with your WASViking account. Add the endpoint without any header. For Claude Code:

claude mcp add --transport http wasviking-engineering \
  https://api.wasviking.com/mcp-gateway/<gateway id>/mcp

Then run /mcp, choose the server and Authenticate. The browser opens the WASViking portal: sign in as usual (SSO and MFA included) and select Allow on the page that names the client and the gateway. When the gateway has tools that change something, that page offers them in a box ticked by default: keep it to let the client act under your policies and approvals, or untick it to keep the client read-only (then the first write call asks you to allow write access, when the client supports that). For Cursor (~/.cursor/mcp.json) or VS Code (.vscode/mcp.json), copy the JSON block from the same tab.

Who can sign in

Two doors open the sign-in, and either is enough:

• MCP access in Team Management (Users, Access column): an administrator sets Portal and MCP or MCP for the person, or invites them with that access. WASViking then creates the person's identity in the AI Guardian directory from their account (source "Portal account"). Setting Portal back revokes their sign-ins and keys at once.
• An identity in the AI Guardian directory (SCIM, CSV import, Google or manual entry) with the same e-mail as the portal account, as long as no administrator set the person to Portal.

Every account starts as Portal, SSO accounts included. When neither door is open, the sign-in page says so and names Team Management.

Claude on the web (claude.ai, Team and Enterprise)

Claude on the web connects through a custom connector; the same steps are on Client Setup and on each person's My AI Tools page.

1. Settings, Connectors, Add custom connector. On Team and Enterprise plans an administrator of your Claude organization does this once in Admin settings, Connectors; everyone else only connects.
2. Name WASViking and paste the gateway address as the remote MCP server URL. Authentication: Sign in now. OAuth client: Use Claude's published identity (Claude shows it as detected). No headers. Add.
3. Open the connector and select Connect: the WASViking portal opens, sign in as usual and select Allow. When the gateway has tools that change something, the box on that page is ticked by default; untick it to keep the connector read-only.
4. In a new chat, open the tools menu and turn the WASViking connector on.
5. In the connector's Tool permissions, Claude puts every tool on Require approval by default, which asks you before each call. Set the read-only tools to Always allow and leave the tools that change something on Require approval; the gateway's policies and approvals apply either way.

Two things to know: the address must be reachable from the internet, since Claude's servers call it and not your browser (a local or private endpoint does not work); and Claude's published identity counts as a verified client, so it works even when the organization allows only verified clients, while Register automatically creates a client per person and is refused in that case. On Credentials & Access, Signed-in MCP clients the person appears with the client "Claude".

Automation: a key. On Credentials & Access, create a key for the gateway and choose who it belongs to (a person or a service account). Copy it when it appears: it is shown once. Set it as WASVIKING_MCP_KEY in the environment of the client and add --header "Authorization: Bearer $WASVIKING_MCP_KEY" to the command above.

Whichever way, the agent sees only the tools of that gateway and every call goes through your policies.

For employees: My AI Tools

Each person finds their own AI tools in AI Guardian, Protection, My AI Tools. The page opens with their numbers (gateways, tools they can use, accounts still to connect, signed-in clients) and has one tab per topic:

• My Gateways: every gateway where they get tools, the tools grouped into read only and change something, and one-click setup: Add to Cursor, Install in VS Code and the Claude Code command. No key: the client signs in with their WASViking account the first time. The browser asks permission to open Cursor or VS Code; choose Open. If nothing opens, Set up by hand has the configuration to copy.
• My Connections: servers that act with each person's own account. They connect, reconnect or revoke their account here. The tab shows how many are still to connect.
• Signed-in Clients: the AI clients they signed in, with Revoke.
• My Toolkits and Recent Activity: the toolkits they received and their last tool calls (metadata only), refused calls in red.

People who only use AI tools get Access MCP in Team Management (the same as the AI Tools User role): after signing in they land on My AI Tools and see only their own pages and their account settings.

Who signed in

Credentials & Access, Signed-in MCP clients lists every client a person signed in: the client, whether it is verified, the person, the gateway, its access (read, or read and write), when it connected and when it was last used. Revoke stops the client on its next request. Which MCP clients may sign in can allow only verified clients (clients that publish their metadata or are registered by WASViking); choosing it signs out the unverified ones at once. A person who leaves your directory loses access on the next request, and a person set to Portal in Team Management loses it at once (an access token already issued lasts up to ten minutes).

Each person's own account on a server

Some servers must see the real person, for example a ticketing or document server that applies each user's own permissions. On Credentials & Access, set the server's Whose account to Each person connects their own. Each person then connects their own account in Connections (OAuth servers open their own sign-in page); an administrator can also connect on someone's behalf with a recorded reason. A person who has not connected is told to connect and nothing runs. Connect organization account signs in once so the gateway can read the server's tools.

Step 6: add the rules that matter

In AI Guardian Policies, choose where a rule applies: MCP Gateway: tool calls or MCP Gateway: tool results. Conditions you can combine include the tool, the server, the action class, the data found in the arguments, a threat signal and the asset risk. Common first rules:

• Block destructive tools (action class destructive, action Block).
• Require approval for writes on risky assets (action class write and asset risk at least medium, action Require approval).
• Allow only read tools on a gateway (action Allow read-only tools only).
• Withhold tool results that carry hidden instructions (threat instruction override on results, action Quarantine the result).
• Mask personal data in tool results (data class pii on results, action Mask sensitive data in the result).
• Require approval when the caller's own account is exposed (Caller identity risk at least Medium, action Require approval).

The asset risk comes from your own WASViking data. When an agent names a bucket, a host, a domain or a repository, the gateway looks it up in Cloud Security, Infrastructure Defense, your attack surface, Code Security, Exposure Intelligence (leaks that mention the domain) and Supply Chain (open vulnerable components of the project), and uses its environment, exposure, open findings and exposed secrets. Servers added from the App Catalog can tell the gateway which arguments name a resource, so it looks those up first. When nothing matches, or the data is older than seven days, the risk is unknown, never safe. A rule decides explicitly what happens with unknown targets.

The Caller identity risk is about the person behind the call: High when their work e-mail appeared in a leak in the last 30 days, Medium in the last 90, Low when there is none, and Unknown for keys that belong to a service account.

Resources and prompts

With Resources and prompts set to Offered and inspected like tool results, agents can list and read the resources (files, pages, records) and the prompt templates of the servers that give them tools on that gateway, and nothing else. Each resource address starts with wasviking-mcp:// and each prompt name with the server's identifier, so a read always goes back to the right server. Resource contents and prompt messages go through the same inspection and result rules as tool results: hidden instructions are withheld and secrets are masked. Prompt templates whose own text carries instructions for the agent are not offered. Each read shows in Calls & Monitoring under Resources and prompts.

Local stdio servers on employees' computers

When an AI client on a laptop runs a stdio MCP server, put it behind the gateway: in the client, use this as the server command, with the person's key in WASVIKING_MCP_KEY:

wasviking-sentinel mcp run --gateway https://api.wasviking.com/mcp-gateway/<gateway id>/mcp \
  -- npx -y @acme/notes-server

The real server still runs on the laptop and its arguments stay there. The gateway's scanner checks the tool definitions (poisoned tools are not offered), and every tool call waits for your policies, approvals included. Each decision shows in Calls & Monitoring. Without an answer from the gateway, nothing runs.

Approvals

When a rule requires approval, the agent receives a message with the approval request id and nothing runs. The request appears in Approvals & Exceptions with the tool, the target, masked arguments and the risk facts the policy used. Someone other than the requester approves or denies it. After an approval, the agent repeats exactly the same call within the approval window and it runs once. A different call, or a second repetition, needs a new approval.

Subscribe a channel to AI Guardian Approval Requested in Alert destinations so approvers hear about it.

Read the call log

Calls & Monitoring lists every tool call with the caller (and the client a person signed in with), the tool, the decision, the asset risk and the rule. Select a row for the detail: the matched assets, the data classes found in the arguments and in the result, threat signals, the approval id and the trace id, where the targets were read from (catalog hints or the arguments) and the caller's exposure. Arguments and results are never stored, only their classes and a fingerprint.

When an agent sends its trace context (traceparent in the request's _meta or in the HTTP header), the call keeps that trace id, marked "from the client", and the tool server receives the same trace, so one trace follows the call end to end.

Change notifications and server health

Where WASViking turned change notifications on, MCP clients that listen for changes learn within about a second that their tool list changed (a tool enabled or removed, a toolkit or group change, a review, a quarantine, a connection), and within about 30 seconds after a policy change. Clients that do not listen still refresh their list every minute. A client whose access ends (key revoked, sign-in revoked, person deactivated, gateway turned off) loses its notification stream at the next check.

To protect the servers behind the gateway, calls have limits per person, per server and per tool, and each server has a maximum number of calls at the same time. When a server stops answering, the gateway pauses calls to it for 30 seconds instead of letting every call wait, then tries one call; when that call works, traffic resumes. The agent receives a clear message in each case and nothing runs.

Calls & Monitoring opens with Server health for the last 24 hours: calls, errors and refusals per server, the median and 95th percentile time, whether the server is answering, paused or recovering, the calls in progress and the busiest tools. It also says whether change notifications are on and how many clients are listening. Connections lists each notification stream with how long it was open and why it ended.

Usage and limits

Your contract sets how many tool calls the organization makes over the last 30 days and how many active identities it has in the same period. An active identity is a person, or an agent key, with at least one call. The contract also sets the concurrent connections of the organization: tool calls waiting on a server at the same time. A panel under the header of the MCP Gateway screen shows the usage against the contract, and the AI Guardian tab of Profile & Plan Usage has the same numbers in one card per module.

• Notices go out at 80% and 100% of the contract, to the alert destinations subscribed to AI Guardian Usage and by e-mail to the organization administrators.
• Above the contract nothing is billed automatically and protection never stops: every decision still applies. Allowed calls with no finding (no rule, detection, redaction, mask, approval or error) stop being recorded while usage stays above.
• After 30 days above the contract, new MCP Gateway keys and new MCP sign-ins wait until the capacity is raised. Existing keys and sign-ins keep working, and the hold lifts as soon as the capacity is raised. While usage is above, the panel shows the date new keys and sign-ins would start to wait.
• A new tool call above the concurrent connections is answered at once with "Too many tool calls are running at once for your organization. Try again in a moment." and nothing runs. Calls already running are never cut.

Your WASViking partner raises the capacity, or WASViking sales if you buy directly. If your organization received the MCP Gateway as a 60-day trial when the modules were packaged, the panel also shows the date the trial ends.

Troubleshooting

What next

• Protect model API calls with the AI Gateway.
• Run AI Security Testing, suite Your policies, to see which risky cases your rules stop and which ones they let through.
• Subscribe a channel to AI Guardian MCP Tool Changed to hear when a server changes or poisons a tool.