Continuous runtime security for every AI backend code change.
Kerno runs inside your agent’s loop and tests every change against your live services, catching security issues before every pull request.
Security checks built from your code, and proved against your running services.
Auth model mapped from source
Which login it expects, which roles it lets through, and what a caller has to present to get past it.
Per-route, per-issue targeting
Ask for an IDOR check on one route, and Kerno runs that check on that route, at the depth you set.
Security on by default, org-wide
Set it once for your org so every engineer gets the same checks, whether or not they think to ask.
Change-level security triage
Kerno works out what a change touches, then says which of those sit behind a login or handle sensitive data.
Cross-role and cross-tenant testing
Kerno creates real accounts with different roles, then makes the same call as each one to see who gets through.
Reproducible findings
Kerno shows the call it made and what your service sent back, so your team can confirm the issue in seconds.
Catches broken access control, injection and data exposure across your backend.
Object-level authorization
Cross-tenant access, IDOR, and records reachable by the wrong owner.
Function-level authorization
Role escalation, admin-only actions, and the scopes a caller must hold.
Injection
SQL, NoSQL, command, and template injection reaching your datastores.
Server-side request forgery
Internal addresses, cloud metadata targets, and redirect chains.
Data exposure
Internal IDs, password hashes, and fields outside the caller’s scope.
Mass assignment
Protected attributes, client-set fields, and over-posted updates.
- TypeScript
- JavaScript
- Python
- Java
- Kotlin
- Go
- Ruby
- PHP
- C#
- Rust
- C
- PostgreSQL
- MySQL
- MariaDB
- MongoDB
- Redis
- Kafka
- RabbitMQ
- AWS
- Azure
- ClickHouse
- Google Cloud
Your security rules and standards shape every check Kerno plans and runs.
Reads your rules and standards in plain English
Write a rule the way you would explain it to a new engineer, and scope it to the repositories and paths it applies to.
Works from the context your team already wrote
Your security policy, agent instruction files and service READMEs shape how every check gets planned.
Gets more accurate with every run you review
Kerno learns from each run and the feedback you give it, and carries what it learns into the checks that follow.
FAQs
Got any extra questions? Reach out on our community channel and we'll be happy to help.
Does Kerno check for IDOR and BOLA?
Yes. Kerno mints credentials for a second user and a second tenant, then calls each route as both, so a record reachable by the wrong caller shows up as a failure.
Can I ask for one specific check on one specific route?
Yes. Scope a run to a single method and path, and name the vulnerability class you want checked, so you get that check rather than a broad sweep.
Can security checks be on by default?
Yes. Set security as the default for your workspace and every engineer gets the same scenarios on every run, without choosing it each time.
How does Kerno help decide whether a change needs a security review?
Kerno maps a change to the backend surfaces it touches, then flags the ones that sit behind a login or handle sensitive data, so your team starts from evidence about what moved.
Can I run a single scenario instead of the whole set?
Yes. Name the scenarios you want and Kerno runs only those. You can also lower the effort level to plan a smaller set in the first place.
Does Kerno replace a penetration test?
No. Kerno covers common API vulnerability classes on every change, all year. It complements a manual penetration test rather than standing in for one.