Scattered tools, one platform
The usual stack is a scanner in the pipeline, an AI pentester beside it and an engagement once a year, each with its own console and its own report. Keygraph brings all three into one place.
Continuous
Agentic Pentesting
With Self-hosted and BYOK Deployments Available
Your team ships code daily, but your pentest only happens once a year. The Keygraph platform closes the 364-day gap: automated penetration testing on every build, and no finding reported without a working exploit.
AppSec and pentesting, on one platform
The scanner, the AI pentester and the yearly engagement, brought into one place and run at whatever depth you choose.
One run, every layer
The running app, its source, its dependencies and its secrets, tested together in one run, not scattered across separate tools.
Proven, then reported
Every finding carries a working exploit, in one report built to be accepted by auditors.
Fast enough for the pipeline
Agentic pentesting now runs at the speed and cost of the pipeline, so the pentest no longer waits for the annual engagement.
The same run, at any depth
The AppSec suite and the pentest are one run, on every pull request or for the full engagement, and every depth ends in the same proven report.
Full in depth pentesting, augmented by a full AppSec Suite
(No Exploit, No Report.)
Whitebox pentesting
The engine is an enhanced build of Shannon, our open-source AI pentester: agents read your source, plan attacks against it, and resolve each hypothesis by attempting a working exploit. Pre-Recon reads the repository, Recon confirms it against the live app, then five domain specialists analyze and exploit in parallel, with a sixth exploit agent for findings outside those classes.
In-scope findings from the static scans are mapped CWE to OWASP, queued as exploitation targets, and linked back to the original finding once proven.
Whitebox Pentester →Blackbox pentesting
Point the Keygraph platform at a URL and let it attack, with no source code access, ever. WhatWeb fingerprints the stack, Playwright-driven automation enumerates endpoints, and mitmproxy captures the traffic, from which an OpenAPI specification can be generated.
A strategy agent then selects a hypothesis and dispatches exploit agents to test it in a real browser. Testing stops when confidence plateaus, not when a counter runs out.
Blackbox Pentester →Agentic SAST
Your codebase compiles into a Code Property Graph: AST, control flow and data flow in one structure. The analyzer traces backward from every sink, and at each node an LLM evaluates whether the specific sanitization actually addresses the specific risk in that context.
An agent then checks each candidate path for control-flow and logic feasibility, so what advances is a traced source-to-sink path rather than a line number.
Agentic SAST →Secrets protection
Pattern matching sweeps the working tree and commit history: configs, environment files, scripts, CI/CD pipelines, application source. Every candidate is then re-read by an LLM against the surrounding code, separating live credentials from placeholders, fixtures and documentation examples.
Entropy analysis catches base64 and hex payloads matching no known signature, and each confirmed secret is classified by blast radius.
Secrets Scanning →Supply chain security
Legacy SCA matches lockfile versions against advisories and reports what is present. Here a research agent extracts the exact vulnerable function from each advisory, the Code Property Graph is queried for a real call site, and a forward walk from application entry points confirms the code can execute.
Severity is rewritten from that evidence: not reachable drops to Low, and reachable CVEs become exploit targets for the pentest.
SCA with reachability →Fix and re-test
Confirmed findings arrive with reproduction steps and a proposed fix as a labeled pull request. You review, you merge. Nothing is auto-applied to your code.
After the patch the same exploit runs again. A finding closes when the attack that proved it stops working, and the record of both runs stays with the finding.
Code Remediation →Structured results
- Traced source to sink path
- Working proof of concept
- Reproduction steps
- Proposed fix as a pull request
- Re-test verdict on the same exploit
A finding ships only when an exploit proved it.
Run one module, or the full run
Every module is a product you can run on its own. Use one at a time where speed and cost matter most, and the full run where depth does.
One module on every pull request
Blackbox, whitebox, SAST, SCA and secrets each run as a scan type of their own. Point a lighter, cheaper model at one of them and it is fast enough for every pull request, which is where most of the value is at scale.
The full run, for a complete pentest
The modules are built to feed each other. Static analysis and the whitebox engine surface different candidates, one queue merges them, and the exploitation agents work that whole queue against the running application. That combination is what makes the full run a different kind of pentest, rather than a scanner with an exploit step bolted on.
Whichever you run, the same closure comes with it: findings deduplicated so you triage once, remediation as a reviewable pull request, Jira sync, and a pentest report built to be accepted by auditors.
What a full run does, in order
A Keygraph run reads the code before it touches the app, holds the static findings back, then proves them. Static candidates and live reconnaissance meet in one exploitation queue, and only what an exploit confirms is filed as a pentest finding.
Read the code first
Phase 1 · Pre-Recon
A code analyst maps the repository end to end: entry points, auth flows, database access and security sinks. Static reasoning only, with no browser involved yet, so the run knows the shape of the application before it sends a request.
Hold the static findings
SAST, SCA, Secrets
The static stream produces candidates, not verdicts. A static finding becomes a pentest finding only after the whitebox pentest proves it against the running app, and anything never exploited is reported in its own lane instead.
Confirm against the live app
Phase 2 · Recon
A recon specialist crawls the running application to confirm endpoints, forms and auth boundaries. What the code implied is checked against what the deployment actually exposes, before any exploitation is attempted.
Five analysts, in parallel
Phase 3 · Vulnerability analysis
Injection, XSS, Auth, SSRF and Authz each get their own specialist, and the five work in parallel. Each one reads the source for its own domain and produces its own candidates, rather than waiting on a single shared pass.
One exploitation queue
Phase 4 · Exploitation
Those candidates, together with any from agentic code analysis, are merged and deduplicated into a queue per domain. In-scope static findings cross over, mapped from CWE to OWASP, and each analyst hands off to a paired exploiter.
See the five-phase run →Report, patch, re-test
Phase 5 · Reporting
A reporting agent synthesizes validated exploits with reproduction steps and severity, and drops the speculative ones. Remediation starts when you click a finding: the fix arrives as a reviewable pull request, then the original exploit is replayed to decide whether it closes.
Static analysis finds the candidates. The pentest is what proves them.
You choose the models. Always your key.
Inference runs under your own provider account, so the key and the model bill are both yours. Run the open-source engine and Keygraph never receives your source and never proxies your model traffic.
Hosted providers
Gateways
Bring your own key. Model access is always your own key and your own provider account, on the Keygraph platform and in Shannon. Because inference runs under your account, the provider's retention terms are yours to set.
One source of truth for every finding.
Reporting & Analytics
The Keygraph platform deduplicates SAST, SCA, Secrets, and Whitebox results into a single canonical entry per vulnerability per repository, surfaced on a live security dashboard and synced bidirectionally with Jira. Each entry retains its evidence and status: identified, validated, recorded.
Explore Reporting & Analytics →Canonical findings
Content-hash plus LLM semantic matching. One entry per vulnerability per repo, persistent across refactors.
Security dashboard
Live KPIs alongside risk, velocity, SLA, and MTTR trend charts. Drill down by repo, team, or severity.
Jira sync
One-click ticket creation, 15-minute status refresh, hourly drift sweep on linked pairs.
From finding to verified patch.
Code Remediation
Click a confirmed finding in the Keygraph platform. An agent reads the evidence, writes the fix, and re-runs the original scanner to prove the vulnerability is gone. The verified patch lands as a reviewable pull request in your existing workflow: your team chooses and tracks the risk response, and nothing is auto-applied.
Explore Code Remediation →Verified before delivery
Same scanner re-runs against the patched code. No patch is delivered unless the original vulnerability is gone.
Review gate stays yours
Patches attributed to a clearly labeled Keygraph bot, landing in your existing GitHub, GitLab, or Azure DevOps workflow. Never auto-applied.
User-initiated only
Patching runs only when someone clicks a finding. It never starts on its own, and it never reverts anything.
When an auditor needs a signature
Every run already produces a pentest report built to be accepted by auditors, with finding tables that carry each fix through to its verification. When an audit wants a human signature on top, the attestation layers onto that pentest, signed by a security team that works separately from the engineers who build the platform.
What is in the report
One signed document
- +The systems under test and the testing window
- +The documented methodology the engagement followed
- +Every vulnerability with its severity ranking
- +The executed proof-of-concept exploit behind each one
- +What was fixed, and how each fix was independently verified
- +The status of anything left open
Findings you choose not to fix appear in the report with their status, so nothing is hidden from your auditor.
How the attestation runs
Typically one week, kickoff to sign-off
Run your pentest on the Keygraph platform
↓
Fix what you choose, as reviewable pull requests
↓
The Keygraph security team reviews and re-tests each fix
↓
You get the signed third-party report
Priced as a flat one-time fee, with your remediation timeline left entirely to you. At the next audit cycle, re-attestation runs the same way against a fresh pentest.
Confirmed in writing
What one audit firm asked for
A SOC 2 audit firm confirmed to Keygraph in writing that an AI-generated pentest is acceptable evidence, on two conditions. The report identifies the vulnerabilities in the application under test, and every finding carries a severity ranking.
Attestation →Provides pentest evidence for compliance regimes including:
PCI-DSS
FedRAMP
GLBA
Safeguards Rule
NYDFS
Part 500
DORA
TLPT
CMMC
Level 3
Your own audits
SOC 2 and ISO 27001
SOC 2 and ISO 27001 audits expect penetration test evidence, which is the gap the signed attestation fills. Alongside it, the findings history logs each vulnerability with timestamp and author as audit-ready evidence for pentest and vulnerability-scanning requirements.
Attestation →Separate from your audit
Keygraph's own posture
This one is about Keygraph, not about you. Keygraph's own SOC 2 Type II report is available under NDA, and the Code Security Posture page sets out the controls the platform applies to your source code.
Code Security Posture →Operated where your data lives.
Keygraph Enterprise
Deploys entirely inside your AWS, GCP, or Azure account. Source and scan results stay inside your security perimeter, and inference runs against the model endpoint you choose, including one inside your own account. No managed control plane. No externally operated data plane.
See the Enterprise platform →Self-hosted
Run the entire platform inside your VPC. Fully air-gapped, with inference from a model endpoint inside your boundary.
SSO & SCIM
SAML 2.0 or OIDC for sign-in. SCIM for automated user provisioning and deprovisioning.
Deep integrations
GitHub, GitLab, Azure DevOps, and two-way Jira sync, plus CI gating in GitHub Actions and Azure DevOps Pipelines.
Cloud, self-hosted or air-gapped
Keygraph Cloud is held to the same standard as a self-hosted install, with regional isolation, and Keygraph's own SOC 2 Type II report is available under NDA. Self-hosted and air-gapped installs exist because many security teams have to keep everything inside their own boundary, and the whole platform runs that way, proof of concept included. Whichever you pick, the run happens in an ephemeral container on read-only scopes.
| What you hold | Keygraph Cloud | Self-hosted | Air-gapped |
|---|---|---|---|
| Operated by | Keygraph | You | You |
| Runs on | Keygraph's AWS, US or EU region | Your AWS, GCP or Azure account | Your network, isolated |
| Findings store | Keygraph tenant, encrypted at rest | Your Postgres, your keys | Your Postgres, your keys |
| Model endpoint | Your key, your provider account | Your key, your provider account | An endpoint inside your boundary |
| Your source | Ephemeral memory, discarded after the scan | Ephemeral memory, discarded after the scan | Ephemeral memory, discarded after the scan |
| What is kept | Only the finding record, with a redacted snippet | Only the finding record, in your database | Only the finding record, in your database |
| Model training | Never on your code or findings | Never on your code or findings | Never on your code or findings |
| Access | Read-only; write only for a fix you open | Read-only; write only for a fix you open | Read-only; write only for a fix you open |
| Sign-in | SAML 2.0 or OIDC | Your IdP, SAML 2.0 or OIDC | Your IdP, SAML 2.0 or OIDC |
| Updates and licensing | Managed continuously | Applied on your schedule | Signed artifacts, validated inside your network |
Every deployment runs the same engine. What changes is who holds the keys, the data and the schedule.
The Shannon 3.0 benchmark
Three Shannon 3.0 runs, one per model, against the Photoview 2.4.0 deployment Doyensec tested, with admin credentials only. Every run is published with a downloadable report and a SARIF file.
$6.10
Cheapest run
Model tokens for the cheapest of the three runs.
3 of 3
Every run caught the critical
Runs that caught the critical pre-auth SQL injection at CVSS 9.8.
6 of 7
Later-patched vulnerabilities
Vulnerabilities Photoview patched after 2.4.0, caught by the Claude Opus 5 run.
SARIF 2.1.0
Machine-readable by default
Written by default in exploit mode, so findings land in GitHub code scanning or GitLab's vulnerability report.
Hands-on at every level
Keygraph came out of problems its own team kept running into, and it is built to be used before it is bought. Start with Shannon today. When you are ready for the platform, a proof of concept runs it on your own code with our engineers, cloud-hosted or self-hosted in your own account.
No signup, no account
Start with Shannon, today
Shannon is the whitebox pentesting engine inside the Keygraph platform, and it writes its reports the way the platform does. Run it against your own code with Docker, Node.js 18+ and your own model key. If you like what it finds, the platform adds SAST, SCA and secrets, one queue across all of them, remediation pull requests, and runs on every build.
# Configure credentials with the interactive wizard. $ npx @keygraph/shannon@latest setup # Run a pentest against a source-available target. $ npx @keygraph/shannon@latest start -u https://your-app.com -r /path/to/your-repo
01
Shannon open source
The engine, run by you.
- Run it locally or in CI
- Any repository, public or private
- The platform's whitebox engine and report format
- You pay only your own model costs
02
Community Program
The full Pro plan for early-stage startups and nonprofits.
- Seed and pre-Series-A startups
- U.S.-based 501(c)(3) nonprofits
- 20 or fewer Active Developers
- Free until you graduate from the program
03
Pro
The full Keygraph platform, cloud-hosted and managed.
- Every module included, no add-ons
- Unlimited repositories and scans
- Seats, not scans or tokens
- SSO, RBAC, audit logs and Jira sync
04
Enterprise
The full Keygraph platform, in your own environment.
- Everything in Pro
- Self-hosted or fully air-gapped
- A dedicated engineer and white-glove onboarding
- Custom SLA, security patch SLA and DPA
Seats, not usage
A seat is a person who changed a monitored repository and still has access. Bots, read-only users and anyone who has lost access are excluded, and scans, pentests, findings and tokens are never metered.
Every module, on every plan
The Community Program, Pro and Enterprise all include every module with no add-ons. A plan decides where the platform runs and how it is supported, never what it can test.
Explore Keygraph
Go deeper on the platform, see how Keygraph compares with the tools you already run, learn Shannon from its docs, or get to know the team behind it.