Work From Your IDE: KollGuard Findings Over MCP

Compliance data belongs where the work happens

The context switch is small but it adds up. You're deep in a codebase, an agent flags something, and to check it against your compliance posture you leave the editor, open a portal, log in, find the finding, read it, and come back. Every one of those hops is a chance to lose your place — and in practice it means the compliance data mostly gets ignored while you're actually writing code, which is exactly when it's most useful.

KollGuard's answer is to bring the data to you. Through an MCP integration and scoped API keys, the agents you already work with can read your live findings — and, when you allow it, act — from inside the editor.

Scoped kgr_ keys: read-only and write

Access is governed by kgr_ API keys with explicit scope, so you grant exactly the capability you intend:

• Read-only keys let a client pull your live findings and nothing more. This is the safe default for observability — an agent can see your posture without any ability to change anything.
• Write-scoped keys additionally let a client file issues and update tickets. This is what turns the integration from a viewer into a participant in the workflow.

The scoping matters. A read-only key you hand to an IDE agent can surface findings all day with zero risk of it mutating your account. When you deliberately want the agent to do more — open a remediation issue, move a ticket forward — you use a write-scoped key for that. You decide how much reach each client gets.

Any MCP client

Because it's built on MCP (the Model Context Protocol), KollGuard works with the clients developers already use rather than forcing a proprietary plugin. That includes:

• Claude Code
• Cursor
• VS Code
• Windsurf
• any other MCP client

MCP is the shared language here — implement the protocol once and every compatible editor and agent can talk to KollGuard the same way. You don't wait for a bespoke extension per tool; if it speaks MCP, it can connect.

What the workflow feels like

Put together, the loop stays inside your editor:

1. Your agent pulls live findings from KollGuard over MCP using a read-only kgr_ key — the same data you'd see in the portal, in the place you're already working.
2. You discuss and reason about a finding with the agent right there, in context of the code that's on screen.
3. With a write-scoped key, the agent can file an issue or update a ticket so the remediation work is captured — again without you leaving the editor.

The result is that compliance stops being a separate destination you have to remember to visit. It becomes ambient — available to the agent while it's helping you write and fix code, which is the moment the information is actually actionable.

Observability first, action when you want it

The design leans deliberately toward safe-by-default. The read-only key is the entry point: give any agent visibility into your findings with no downside. Write access is a separate, intentional grant for when you want the editor workflow to push back into KollGuard. That split keeps the common case — let my agent see our security posture — friction-free, while making the more powerful case — let my agent act on it — a decision you make on purpose rather than a default you inherit.