Analyse a project's code from Lovable or a coding assistant
Send a project's source files to WASViking from an AI client through the MCP Gateway (a Lovable chat connector, Claude Code, Cursor or VS Code) and read the Code Security findings back, with no GitHub, GitLab or Bitbucket connection.
The WASViking® code analysis server is a built-in MCP server of the AI Guardian MCP Gateway. An AI client that can call tools hands it the files of the project it is working on; WASViking stages them, assembles the project and runs the same analysis as a project uploaded in Code Security: secrets, software composition (SBOM and known vulnerabilities), access control, AI and LLM usage, backend-as-a-service access, source exposure and CI/CD workflows. The findings come back to the client as summaries and locations, never as code, and the project appears in Code Security like any other.
It works with every client that speaks MCP over Streamable HTTP: a custom MCP server added as a Lovable chat connector, Claude Code, Cursor and VS Code. Plan for about twenty minutes the first time.
Before you start
- The MCP Gateway is on for your organization (see Govern agent tools with the MCP Gateway) and Code Security is part of your plan. A project analysed this way counts as one repository of your plan's repository allowance.
- You have an administrator role, or a role with AI Gateway manage access.
- Your AI client is connected to a gateway. In Lovable, open Connectors, choose a custom MCP server and paste the gateway endpoint shown on the Client Setup tab; OAuth sign-in is the default and a key from Credentials & Access works as the bearer token. Claude Code, Cursor and VS Code use the commands on the same tab.
Step 1: add the server
Open AI Guardian, Protection, MCP Gateway, then the Servers tab, and select Add WASViking code analysis (receives source files). The same entry exists in the App Catalog as a WASViking verified server.
What you should see: a server called WASViking code analysis with six tools, each approved at once: the server is first party and every definition scans clean.
| Tool | What it does | Class |
|---|---|---|
test_source_transfer |
Hashes one to twenty files and answers with the byte count and SHA-256 of each one; stores nothing. | write (by name) |
create_security_scan |
Creates the project on first use and opens a session for the files. | write |
upload_source_batch |
Receives one batch of files (up to 200 files, about one megabyte) into the session. | write |
finalize_security_scan |
Closes the session and queues the analysis. | write |
get_security_scan_status |
The session state and the project's runs. | read |
get_security_scan_results |
The project's open findings, most severe first. | read |
Step 2: tick the tools on a gateway
Open the Gateways tab, choose the gateway your client uses and tick the six tools (restrict them to the directory groups that may send code, if you want).
What you should see: the gateway's tool count grows by six and the client
lists tools whose names start with wasviking_code__ on its next listing.
A gateway created with the secure default rules asks a person to approve a
write on a target WASViking does not know or considers high risk. Opening the
analysis of a project that does not exist yet is such a write, and so is
opening a new analysis of a project whose last run left high or critical
findings: create_security_scan waits once in Approvals, the client
repeats the call, and that one approval covers the session it opens, batches
and finalize included. A project that exists and carries no high or critical
findings goes through without asking.
Step 3: prove the transfer
In the client's chat, ask:
Use the WASViking tool test_source_transfer to send the file src/App.tsx of this project.
What you should see: an answer with received: 1, the file's byte count,
its SHA-256 and stored: false, plus the limits of a real transfer. This proves
the client can read its files and pass them as tool arguments, which is all the
rest depends on. If the client answers that it cannot read files or that the
tool is not available, see the troubleshooting table.
Step 4: analyse the whole project
Paste the prompt from the Client Setup tab, or write your own:
Analyse the security of this project's whole source code with WASViking: open a session with create_security_scan, send every source file with upload_source_batch (skip node_modules, build output and lock files you cannot read), then call finalize_security_scan and report the analysis status.
What you should see, step by step:
create_security_scananswers with the project name, asession_idand the limits. Lovable shows an approval card before this tool, as before every tool that changes something; Always allow for the tool on the connection skips the card for the batches that follow.upload_source_batchanswers each batch withreceived, the files it skipped and why (dependency_dir,vcs_internal,hash_mismatch), the session totals and the remaining capacity. A file sent twice with the same content is acknowledged and not stored again.finalize_security_scananswersstate: sealedand the analysis starts in the background.
In the portal, Code Security now lists the project as an uploaded project, and its run history shows the run with Sent by an AI tool (MCP), who sent it and how many files were received.
Step 5: read the results
Ask the client for get_security_scan_status with the project name until a
run shows completed (a small project takes a few minutes; the review stages
take longer on large ones), then for get_security_scan_results.
What you should see: the open findings of the project, most severe first,
with the module, title, severity, CWE and the file and line, and the project's
totals by category. For the detail of one finding, the finding id works with
get_finding of the WASViking security data server, and the portal shows
everything under Findings filtered by the project.
Limits and what is skipped
| Limit | Value |
|---|---|
| Files per call | 200, about one megabyte of content in total |
| Files per session | 5,000 |
| Content per session | 100 MB |
| One file | 1 MB (binary files travel as base64) |
| Open session | 2 hours without a batch, one open session per project |
Skipped on arrival, never stored: version control internals (.git, .hg,
.svn), dependency and build trees (node_modules, vendor, dist, build,
target, .next, virtual environments and the like), desktop metadata files,
paths that try to leave the project, files whose SHA-256 differs from the one
the client sent. Test folders and fixtures are kept: the source exposure stage
reads them on purpose.
Privacy and security
- The files travel inside the tool calls, over TLS, to your WASViking organization only. The gateway inspects every call as it does any other tool call: secrets, personal data and prompt injection in the arguments, your AI Guardian policies and approvals. A rule that blocks secrets in tool arguments stops a batch that carries a credential; the message says which rule.
- The call log keeps metadata only (who, which tool, a hash of the arguments, the data classes found), never a file.
- Received files live as encrypted fragments in your organization's private upload area until the analysis starts, then as one archive that is deleted when the run ends. Nothing in the project is executed: the engines read manifests and text.
- Each batch is one MCP tool call for your usage counters, and the project counts as one repository of the plan.
Troubleshooting
| What you see | Why | What to do |
|---|---|---|
The client lists no wasviking_code__ tools |
The server was not added, the tools are not ticked on this gateway, or the client cached an older list | Add the server, tick the tools, then reconnect the client |
| "This tool waits for review by your administrator" | A changed definition after a WASViking release | Open Tools and approve the current definition |
| "This action needs approval by a person" | A policy rule, usually the secure default for writes on high-risk targets | Approve the request under Approvals and repeat the call; the approval covers the rest of the session |
| "Blocked by WASViking AI Guardian (policy ...)" | A rule blocked the call: secrets in arguments, source code, or a threat signal | Review the rule, or add an exception for the wasviking_code server |
| "The session would exceed its size limit" | More than 100 MB of content | Leave out generated files; split large projects |
| "Another sign-in is sending this project right now" | Someone else has an open session for the same project | Wait for it to end or expire |
Status failed with already_running |
A run of the project is still in progress | Wait for it to finish, then open a new session |
| "Code Security is not part of this organization's plan" | The module is not contracted | Activate it with your partner or WASViking sales |
| The client asks for approval on every batch | Chat connectors ask before every tool that changes something | Choose Always allow for upload_source_batch on the connection |
| The client says it cannot read the project's files | The client decides what it can send; WASViking only receives | Prove it with test_source_transfer; in Lovable, make sure the connector is added in the project chat |