Runtime code and security reviewer for coding agents

Kerno gives every agent session an independent reviewer that validates code changes locally against your live stack and catches broken functionality and security risks before they reach a PR.

Set up Kerno for this repo: install the CLI, bind it to this workspace, register MCP with my coding tool, then trigger workspace analysis and list the available apps for me to choose from. Follow the Kerno MCP's instructions throughout. Don't run any tests, and don't set up the environment yet.

Read rather than improvise. kerno init prints what you need, and once MCP is live every Kerno tool carries a What/When description saying what to call next. Follow those, and call kerno_guide for detail. The commands below are the happy path; if kerno init prints something different, its output wins.

Prerequisites that must already exist. If any of these is missing, stop and tell me: Node.js 18+, npm, Docker running, and a git repo.

  npm install -g @kerno/cli
  kerno login
  kerno init -w "<absolute path to this repo>"

Don't run kerno login yourself. It renders an interactive terminal UI and dies immediately in an agent shell with "Raw mode is not supported on the current process.stdin", so the browser never opens. Instead, tell me to run ! kerno login in the prompt myself, then pause and wait for me to confirm I've logged in before continuing.

Run kerno init -w even if something seems to be listening already, never two at once, then use the workspace, port and registration snippet it prints verbatim. The port is per-session, so never reuse one from docs, an old config, or memory. Be aware that init's port and registration snippet render through the same terminal UI, so in an agent or piped shell the plain output may stop at "Starting agent..." with no port and no registration line. If that happens, don't guess: either re-run under a pseudo-TTY to force the full snippet to render (script -q /dev/null kerno init -w "<path>"), or read the port from ~/.kerno/agent.stdout.log (the line "Kerno MCP server started on port N") and build the endpoint as http://localhost:N/mcp. kerno doctor --clean fixes an orphan or inconsistent agent.

Default to registering with the host you are running in, but confirm r, and ask if I want a different one. Don't infer my preference fromthe tool alone. Register at one scope only, project or user, and merge rather than overwrite other servers.                                                           Then allowlist Kerno before calling any tool. A single task runs manypeated status and job polling, so without this I am clicking approveevery few seconds. Explain that to me, show me the change, and apply it once I accept. If it's already present, tell me and move on. Claude Code: "mcp__kerno__*" in permissions.allow in .claude/settings.json or ~/.claude/settings.json. Codex: default_tools_approval_mode = "approve" under [plugins."kerno@kerno".mcp_servers.kerno] in ~/.codex/config.toml. Cursor: no file, tell me to set Run Mode to r id you registered if it isn't "kerno".

Registering the server does not load its tools into a session that was already running. Before you try to call anything, expect the kerno_* tools to be absent, and tell me to reconnect: in Claude Code run /mcp, select the server, and reconnect, or restart the tool. A "Connected" line from claude mcp list is not proof your current session can call the tools, because that check opens its own  Verify only with kerno_get_applications.

Verify with kerno_get_applications; that succeeding means connected. Don't use a healthcheck, which blocks 120 seconds and can report a schema error while MCP is fine, and don't use kerno status, which needs a TTY and exits 1 in agent shells even with CI=true.

Also note: any stop, restart or workspace switch kills the MCP session even on the same port. Re-parse the MCP endpoint URL from the registration snippet and reconnect the same way.

Once connected, let Kerno finish analyzing the workspace, then list the apps it found and present them to me so I can choose which one to test. Stop there and follow the Kerno MCP's tool guidance for what comes next.

COPY SETUP PROMPT

COPY CLI COMMAND

Get started for free | Works with your AI stack

IMPROVE DEVELOPER CONFIDENCE

Developers trust what they ship, so PRs move faster instead of stalling in review.

ACCELERATE RELEASE CYCLES

Find, fix, and verify within the agent session, instead of post merge.

REDUCE PRODUCTION ISSUES

Fewer breaking changes, less on-call fallout, and fewer production incidents.

Trusted in production by AI-native engineering teams.

Kerno was up and running in minutes with no manual work, and it made our API migration so much smoother. We could instantly validate that every change made by Cursor worked the way we expected, and now it's a core part of how we build.

Misch Strotz

Co-Founder & CEO, LetzAI

Using Kerno with Claude Code has been a game changer. You get quick feedback with no manual effort, and it saves you a lot of time and hassle debugging integration issues post-merge.

Jonathan Bernales

CTO, Germen

Kerno saves us a lot of manual work and helps us catch side effects and issues that would definitely break our projects' backends. Our engineering team loves it.

Santiago J. Valls

Co-Founder & CTO, Bewise

Meet Kerno

An independent evidence layer to verify every AI code change

Kerno gives your AI agent a local feedback loop to verify and fix its work in context and ship code that's secure and works as part of your system.

01 | Agent First

Runs inside the agent loop over MCP

Kerno runs inside your agent's session across worktrees, giving it a fast, local feedback loop to validate its code changes.

85,459+ Agent sessions covered

02 | Complete Context

Learns how your product works

Kerno indexes your whole codebase to understand how everything connects, and learns your domain knowledge and business logic over time.

136,050,370+ Lines of code indexed

03 | Real Evidence

Catches what static reviews miss

Kerno manages the data layer and runs code against your live stack, catching real functional and security issues without false positives.

678,090+ code changes reviews

04 | E2E coverage

Reviews the full impact of every change

When code changes, Kerno computes the blast radius and reviews every impacted part of your codebase so issues don't slip through.

287,482+ Issues caught

05 | Self-healing

Coverage evolves with your codebase

As your app evolves, Kerno automatically retires stale tests and generates new ones to close coverage gaps and and minimize production risk.

450,000+ Endpoints covered

How Kerno Works

Set up once, scale to your whole team.

Connect Kerno to your codebase and stack once, and every developer and agent gets the same review on every change they make.

KERNO VERIFIES WHAT SAST & CODE REVIEW TOOLS CAN ONLY guess FROM SOURCE

Functional API Workflows

Contract Validation

Error Handling & Resilience

Authorization & Authentication

Boundary & Edge Cases

OWASP Top 10 Vulnerabilities

Multi-Tenant Isolation

Idempotency & Side Effects

Set up Kerno for this repo: install the CLI, bind it to this workspace, register MCP with my coding tool, then trigger workspace analysis and list the available apps for me to choose from. Follow the Kerno MCP's instructions throughout. Don't run any tests, and don't set up the environment yet.

Read rather than improvise. kerno init prints what you need, and once MCP is live every Kerno tool carries a What/When description saying what to call next. Follow those, and call kerno_guide for detail. The commands below are the happy path; if kerno init prints something different, its output wins.

Prerequisites that must already exist. If any of these is missing, stop and tell me: Node.js 18+, npm, Docker running, and a git repo.

  npm install -g @kerno/cli
  kerno login
  kerno init -w "<absolute path to this repo>"

Don't run kerno login yourself. It renders an interactive terminal UI and dies immediately in an agent shell with "Raw mode is not supported on the current process.stdin", so the browser never opens. Instead, tell me to run ! kerno login in the prompt myself, then pause and wait for me to confirm I've logged in before continuing.

Run kerno init -w even if something seems to be listening already, never two at once, then use the workspace, port and registration snippet it prints verbatim. The port is per-session, so never reuse one from docs, an old config, or memory. Be aware that init's port and registration snippet render through the same terminal UI, so in an agent or piped shell the plain output may stop at "Starting agent..." with no port and no registration line. If that happens, don't guess: either re-run under a pseudo-TTY to force the full snippet to render (script -q /dev/null kerno init -w "<path>"), or read the port from ~/.kerno/agent.stdout.log (the line "Kerno MCP server started on port N") and build the endpoint as http://localhost:N/mcp. kerno doctor --clean fixes an orphan or inconsistent agent.

Default to registering with the host you are running in, but confirm r, and ask if I want a different one. Don't infer my preference fromthe tool alone. Register at one scope only, project or user, and merge rather than overwrite other servers.                                                           Then allowlist Kerno before calling any tool. A single task runs manypeated status and job polling, so without this I am clicking approveevery few seconds. Explain that to me, show me the change, and apply it once I accept. If it's already present, tell me and move on. Claude Code: "mcp__kerno__*" in permissions.allow in .claude/settings.json or ~/.claude/settings.json. Codex: default_tools_approval_mode = "approve" under [plugins."kerno@kerno".mcp_servers.kerno] in ~/.codex/config.toml. Cursor: no file, tell me to set Run Mode to r id you registered if it isn't "kerno".

Registering the server does not load its tools into a session that was already running. Before you try to call anything, expect the kerno_* tools to be absent, and tell me to reconnect: in Claude Code run /mcp, select the server, and reconnect, or restart the tool. A "Connected" line from claude mcp list is not proof your current session can call the tools, because that check opens its own  Verify only with kerno_get_applications.

Verify with kerno_get_applications; that succeeding means connected. Don't use a healthcheck, which blocks 120 seconds and can report a schema error while MCP is fine, and don't use kerno status, which needs a TTY and exits 1 in agent shells even with CI=true.

Also note: any stop, restart or workspace switch kills the MCP session even on the same port. Re-parse the MCP endpoint URL from the registration snippet and reconnect the same way.

Once connected, let Kerno finish analyzing the workspace, then list the apps it found and present them to me so I can choose which one to test. Stop there and follow the Kerno MCP's tool guidance for what comes next.

COPY SETUP PROMPT

COPY CLI COMMAND

Get started for free | Works with your AI stack

Runtime code and security reviewer for coding agents

Writing code is no longer the constraint. Runtime verification is.

An independent evidence layer to verify every AI code change

Runs inside the agent loop over MCP

Learns how your product works

Catches what static reviews miss

Reviews the full impact of every change

Coverage evolves with your codebase

Set up once, scale to your whole team.

Built for enterprises. Ready on day one.

Supports all coding languages and architectures

Built to support enterprise-scale codebases.

SOC 2 Type II (audit in progress)

Encrypted end to end

Zero code retention