Sekura for enterprise
Specialized AI agents run a seven-phase pipeline — static analysis, reconnaissance, vulnerability analysis, exploitation, and chain analysis — and hand back deterministic proof-of-exploit with a one-line fix. Not a pile of alerts. Not a severity score. It runs in your environment, so your code never leaves.
Why now
Three quarters of new code is written by a machine, nearly half of it insecure, shipped four times faster at ten times the defect rate — against a security workforce that is millions of people short and falling further behind every year.
Writing, breaking, and exploiting code all run on the compute curve now. Testing is the last thing still on the hiring curve. No hiring plan closes that gap; it has to be closed the same way it was opened.
Proof, not probability
Not a dashboard of alerts to triage. A report you can hand to an engineer, an auditor, or a board — every finding carrying the request and response that prove it. A severity score is a guess. A proof isn’t.
Executive summary
Severity breakdown, surfaces covered, and the scan window — one page.
Findings
Each one ranked, with the affected component and the exact line or endpoint.
Proof of exploit
The request, payload, and response that demonstrate it. Not a severity score.
Exploit chains
Where individually medium findings combine into a critical path.
Remediation
A specific fix per finding, at the line level, ready to apply.
Compliance mapping
Findings mapped to the frameworks you already report against.
$ sekura scan --repo computeid-passport --type web [sca] color-string@1.5.4 ← CVE-2021-29060 (ReDoS, CVSS 7.5)[reach] imported by simple-swizzle → color → theme loader (app entry)[proof] crafted color value "rgb(9999999999999999999999999999999999999999%..." → 100% CPU, request hangs >30s[verdict] EXPLOITABLE — single unauthenticated request stalls a worker
bump color-string to ^1.5.5 (patched) — transitive, one lockfile changeevidence · full run$ sekura scan --target acme-payments-api --mode fullsekura-rs v0.11.4 (build 2a3f91c) — orchestrator onlinetarget: acme-payments-api │ mode: full │ scope: prod-mirrorloaded 50+ tool adapters · 16 agent classes · policy=strict-opt-in── phase 1 / 7 · whitebox + SAST ──────────────────────────whitebox-reviewer: cloning git@acme/payments-api@main (2,184 files)semgrep: 312 rules · ruleset=p/owasp-top-10,p/pythongitleaks: scanning history depth=500semgrep ▸ payments/query.py:142 tainted-sql-format (high)[F-01] hypothesis: SQL injection in build_invoice_query (payments/query.py:142)gitleaks ▸ .env.sample:7 dummy token (ignored)semgrep ▸ users/routes.py:88 missing-authz-check (medium)[F-02] hypothesis: IDOR on GET /users/:id/receipts (users/routes.py:88)semgrep ▸ auth/token.py:55 weak-jwt-alg (none) (low)whitebox-reviewer: 3 hypotheses emitted · routing to phase 2── phase 2 / 7 · recon ────────────────────────────────────recon-agent: subfinder + amass · scope=acme-payments-api.prodhttpx: 200 OK api.acme.internal/healthz server=envoy/1.29katana crawl depth=3 · 12 endpoints discovered POST /v2/auth/login (auth.svc) POST /v2/auth/refresh (auth.svc) GET /v2/users/:id (users.api) GET /v2/users/:id/receipts (users.api) POST /v2/payments/charge (payments.api) POST /v2/payments/invoice (payments.api)Show the full run (51 more lines)
GET /v2/orders/:id (orders.api)nuclei: tech-detect · postgres@13.8 · redis@7.2 · s3@awsrecon-agent: surface mapped · 12 endpoints · 8 services── phase 3 / 7 · auth context ─────────────────────────────authz-analyzer: deriving role matrix from OpenAPI + tracesroles resolved: [anon, user, merchant, admin]session cookie: sid · SameSite=Lax · HttpOnly=1 · Secure=1jwt alg=RS256 · kid rotation=24h · no "none" accepted── phase 4 / 7 · vuln agents (16 concurrent) ──────────────spawning 16 agents · budget=180s · max_rps=20/hostsqli-analyzer ▸ probing F-01 · payload-gen=boolean+timexss-analyzer ▸ scanning /v2/users/:id · 41 reflection pointsauthz-analyzer ▸ probing F-02 · swap-token matrix=4x4ssrf-analyzer ▸ /v2/payments/invoice · webhook_urlsecrets-agent ▸ history scan · 500 commitssqli-analyzer: boolean diff on invoice_id=1 vs 1 AND 1=2xss-analyzer: all 41 points HTML-encoded · no reflectionauthz-analyzer: GET /users/A/receipts with token_B → 200 OK[F-02] CONFIRMED · IDOR · cross-tenant read · CWE-639sqli-analyzer: time-delay 5.02s on sleep(5) injection[F-01] CONFIRMED · blind SQLi (time-based) · CWE-89ssrf-analyzer: webhook_url=http://169.254.169.254 → blocked (egress policy)secrets-agent: 0 live credentials · 2 stale (rotated)csrf-analyzer ▸ double-submit tokens present · passesdeserial-agent ▸ no pickle/marshal sinks · passesrate-limit-agent ▸ /v2/auth/login 5rpm · bypass via x-fwd-for=rotating[F-03] rate-limit bypass on /v2/auth/login · CWE-307cache-agent ▸ redis keys: session:* TTL=3600s · OKstorage-agent ▸ s3://acme-receipts public-block=ON · OK[F-04] verbose error leaks stack trace on 500 (payments/charge)[F-05] missing HSTS preload on api.acme.com · CWE-319[F-06] CORS Access-Control-Allow-Origin: * on /v2/public/*[F-07] dependency: requests==2.28.1 · CVE-2023-32681 (medium)── phase 5 / 7 · exploitation ─────────────────────────────exploit-sqli ▸ F-01 · extracting schema via time-based oraclesqlmap: DBMS=PostgreSQL 13.8 · current_user=payments_rwsqlmap: 14 tables discovered · invoices,users,sessions,…exploit-sqli: read SELECT token FROM sessions LIMIT 1 → [redacted]proof-of-impact captured (redacted) · stored as evidence://F-01── phase 6 / 7 · chain analysis ───────────────────────────chain-analyzer ▸ graph walk · 7 findings · 3 viable chainscandidate chain: F-02 (IDOR) → F-01 (SQLi) → session.tokenchain-analyzer: IDOR leaks invoice_id from victim → feeds SQLi paramchain-analyzer: SQLi extracts session.token from db.sessionsexploit-chain: replayed session.token on /v2/auth/whoami → 200 OK as victim[CHAIN-01] ACCOUNT TAKEOVER · IDOR + SQLi + token replay · severity=critical── phase 7 / 7 · report ───────────────────────────────────reporter: de-duplicating 8 findings · attaching evidence · writing SARIFreporter: 8 findings · 3 exploited · 1 critical chain · 2m 47sartifacts: report.html report.sarif evidence/*.har chain-01.svgscan complete · idle · awaiting next target
Most teams buy five or six tools to cover this ground and then correlate the results by hand. Sekura runs it as one pass and connects what it finds.
Outside your code
The hosts, cloud configuration, and exposed surface an attacker reaches before they ever touch your code.
Inside your code
Your code and the running application — read line by line, probed live, and chained the way a real attacker would chain it.
Two mediums your scanner tells you to fix next quarter, plus one it never files at all. The chain only exists in the graph — so if your tools don’t share one, it doesn’t exist for you. It still exists for the attacker.
The pipeline
Every phase is a real set of agents and tools with a real output record. Open a phase to see who runs it and what it emits.
Read the code before probing the service
Seven SAST engines plus a whitebox LLM reviewer read the repo, emit hypotheses, and seed every later phase with ground truth.
7 SAST engines · 1 reviewer
Finding (hypothesis)
Finding {
id: "F-01",
kind: Vuln::SqlInjection,
verdict: Verdict::Hypothetical,
source: Source::Whitebox,
anchor: "payments/query.py:142",
evidence: "semgrep ▸ tainted-sql-format",
cvss_est: 7.5,
}Map the surface across 9 OSI layers
Fifty-plus Kali tools, orchestrated as a single plan, map the attack surface from layer-3 up to application. Output feeds phase 4 so vuln agents probe only what exists.
50+ kali tools · 9 osi layers
Finding (surface)
Surface {
endpoints: 12,
services: 8,
stack: ["envoy/1.29", "postgres/13.8",
"redis/7.2", "python/3.11"],
public_ingress: Some("api.acme.com"),
fingerprint_confidence: 0.94,
}PQC + CBOM inventory
Emits a Cryptographic Bill of Materials and flags anything a CRQC would break. Quiet phase; mostly reads configs, certs, and library calls.
cbom · pqc posture
Finding (crypto)
CryptoFinding {
primitive: "RSA-2048 key exchange",
quantum_vulnerable: true,
migration: Pqc::Kyber768,
appears_in: ["tls handshake",
"jwt signing"],
severity: Severity::Medium,
}16 agents, concurrent, budgeted
Sixteen specialist agents fan out on the surface from phase 2, each with a focused prompt and tool set. They run concurrently under a rate budget and emit hypothesis-level findings with evidence.
16 agents · concurrent
Finding (hypothesis → confirmed)
Finding {
id: "F-02",
kind: Vuln::Idor,
verdict: Verdict::Hypothetical,
endpoint: "GET /v2/users/:id/receipts",
evidence: "swap-token matrix 4x4 · 200 OK",
cvss: 6.5,
next: Phase::Exploitation,
}Prove impact with safe proofs
Sixteen exploit agents confirm hypotheses with safe, evidence-only proofs-of-impact — boolean and time oracles, scoped payloads, redacted captures. Mediums get upgraded to confirmed; anything unprovable is dropped.
16 exploit agents · evidence-only
Finding (confirmed)
Finding {
id: "F-01",
kind: Vuln::SqlInjection,
verdict: Verdict::Confirmed,
proof: "time oracle · sleep(5)=5.02s",
cvss: 7.5,
evidence: "evidence://F-01.har",
}Individually medium. Chained, critical.
Chain-analyzer walks the confirmed-findings graph and proposes multi-step attack chains; cross-validator rejects any chain that fails an independent replay. This is where separate medium findings combine into one critical exploit.
chain analysis · cross-validated
Finding (chain)
Chain {
id: "CHAIN-01",
steps: [F-02, F-01, "token replay"],
impact: Impact::AccountTakeover,
cvss: 9.3, // up from 6.5 / 7.5
verdict: Verdict::Confirmed,
caption: "individually medium.
chained, critical.",
}HTML · JSON · Markdown · CVSS · compliance
De-duplicates findings, attaches evidence, scores CVSS v3.1, and maps to OWASP, MITRE ATT&CK, PCI-DSS, SOC 2 CC-series. Emits the artifact set a human pentester would ship.
html · sarif · md · compliance
Artifact set
Artifacts {
report_html: "report.html",
sarif: "report.sarif",
markdown: "report.md",
evidence: "evidence/*.har",
compliance: ["owasp", "mitre-attack",
"pci-dss", "soc2"],
}Five findings a scanner would list separately, and the path an attacker would actually walk. Individually medium. Chained, critical.
user → gateway — exploit IDOR on /api/users/{id} (+2.3)gateway → auth — forge JWT with internal user id (+1.8)auth → payments — access payment service as victim (+1.2)payments → s3 — trigger SSRF to s3 signing url (+2.1)s3 → s3 — exfiltrate card vault (+1.6)Comparison
What changes when you replace the scan-and-triage loop with continuous, proof-first autonomous pentesting.
| Without Sekura | With Sekura | |
|---|---|---|
| Output | Ranked list of potential issues; CVSS scores divorced from your environment | List of exploited issues, each with a deterministic proof-of-exploit |
| False positives | Inherent — scanners flag what might be vulnerable, your team validates each | Eliminated by construction — Sekura only reports findings it has actually exploited |
| Scope | SAST or DAST or SCA — one surface per tool, one tool per vendor | SAST + DAST + exploit chaining + LLM-security + post-quantum crypto in one scan |
| Cadence | On-demand or scheduled — weekly at best, annually for manual pentests | Continuous — every push, every PR, optionally every hour |
| Triage burden | Hours per finding to validate, prioritize, and fix | Zero — every finding ships with the payload that demonstrates it |
Integrations and compliance
IDEs (via MCP)
CI/CD
LLM providers
Notifications + fixes
Findings auto-mapped to 14 compliance frameworks. Audit prep as a byproduct of every scan.
Your code never leaves GitHub. The scanner runs in your own GitHub Actions runner.
Node 18+ required. Works on macOS, Linux, Windows. The free tier covers one repository, public or private.
Source code never leaves your repo. We dispatch a workflow, the runner executes the scan, and we receive only the findings. SARIF flows back into the GitHub Security tab; PR review comments arrive inline on the lines we found issues on.
When you run npx sekura@latest init, the Sekura GitHub App commits this file to your repo’s default branch:
name: Sekura Security Scan
on:
push:
branches: [main, master]
pull_request:
workflow_dispatch:
permissions:
contents: read
pull-requests: write
security-events: write
jobs:
sekura:
runs-on: ubuntu-latest
timeout-minutes: 30
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: sekuraai/sekura-scan-action@v1
with:
scan-type: sast
intensity: standard
min-severity: medium
sekura-token: ${{ secrets.SEKURA_TOKEN }}
auto-fix-pr: falseThe SEKURA_TOKEN repo secret is provisioned automatically through the GitHub Actions secrets API, encrypted with the repo’s public key. You never paste a token by hand.
Pricing
Tell us what you’re protecting — repositories, live targets, hosts, cloud accounts — and that’s your envelope. Scans inside it are unlimited. Test on every commit without watching a meter.
Your first full scan is free. After that, Sekura Once buys a managed assessment on demand for $199, or Sekura Always keeps every push checked for $49 a month. The envelopes bundle capacity for teams; network testing needs a runner inside your perimeter, so it starts at Business.
Your first repository, free — the full pipeline.
$0
Your first repository is a full-pipeline scan — including proof-of-exploit — free. Re-scan that repository whenever you like. No card.
Check it onceCheck it once. We run a full assessment on demand.
$199 / scan
We run it for you. A full assessment on demand — nothing to install, no model key, no subscription. For before a release or ahead of an audit.
Check it onceKeep it checked. Every push, unlimited repos.
$49 / month
You run it. Every push and pull request scanned from your editor and CI on your own model key. Unlimited repositories and scans, cancel anytime.
Keep it checkedA product team shipping daily, wired into your pipeline.
$24,000 / yr
Application security for a product team shipping daily. Runs in Sekura cloud, wired into your pipeline.
Talk to usNetwork and application security, in your own cloud.
$60,000 / yr
Network and application security together, deployed in your own cloud. Replaces a network validation tool, a CSPM, and an annual pentest.
Talk to usOn-premises or air-gapped, with inference included.
From $120,000 / yr
On-premises or air-gapped, with inference included. No model contract, no GPU operations, no code leaving your network.
Talk to usNothing here is sent anywhere. Move the sliders and the page does the arithmetic.
Recommended envelope
—
—
What this replaces today
Sekura Always runs against your own model key, so the free tier costs us almost nothing to keep open. Each step up adds something you could not do before — not just more of the same.
What we meter
Charging per scan makes teams test less, which defeats the point of continuous validation. So we don’t. We meter the thing that actually consumes compute: how many scans run at once.
Unlimited
Scans
Run on every commit, every pull request, every deploy, and again after each fix. Nobody on your team should have to decide whether a change is worth testing.
Metered
Concurrent lanes
A lane is one scan running at a time. A full eight-phase scan takes 10–15 minutes, so lanes decide how fast a busy pipeline clears — not whether you’re allowed to test.
Unlimited isn’t generosity. It’s arithmetic.
A full scan costs us between $0.20 and $2.00 to run. Most of what a scan needs to know is pre-computed in our own vulnerability corpus rather than re-derived from a model every time, so the marginal cost of you testing again is close to nothing. That is why unlimited scanning is a structural promise rather than a launch offer — and why anyone charging you per scan is charging for the meter, not the compute.
The mechanics
| Asset class | How it counts |
|---|---|
| Repository | 1 slot · large monorepo 4 |
| Live application or API | 1 target each |
| Network hosts | blocks of 256 |
| Cloud account | 1 each, any size |
| Scans | not counted |
| Tier | Concurrent lanes |
|---|---|
| Free | 1 |
| Sekura Once | 1 |
| Sekura Always | 1 |
| Team | 2 |
| Business | 6 |
| Enterprise | 20+ |
Most repositories take one slot. A large monorepo takes four, because it genuinely costs four times as much to test — and pretending otherwise would mean charging small teams to subsidise large ones.
Capacity is expressed in lanes instead. A lane is one scan running at a time, so what you license is how fast your pipeline clears — never how many times you’re allowed to test.
Hosts are counted in blocks of 256. Cloud accounts count as one each, whatever their size. You will never see a line item measured in lines of code.
Prices in USD, billed annually.
Customers
Early adopters running autonomous penetration tests on real codebases — with proof-of-exploit for every finding.
Identity & passport platform — SDK, CLI, MCP server, and web apps.
Tax-loss harvesting platform helping DIY investors maximize tax savings.
AI-driven continuous monitoring for cyber, compliance, third-party, and reputation risk.
Research · found by Sekura
Real vulnerabilities surfaced by Sekura in design-partner engagements. Disclosed privately first; published anonymized once cleared. No scores, no spam — proof.
Across a 5-repository platform (SAST + live DAST), Sekura proved a transitive dependency (color-string@1.5.4) was reachable from a login-path service and that a single crafted, unauthenticated request pinned a worker via catastrophic regex backtracking. Delivered with evidence, a verdict, and a one-line lockfile fix.
FAQ
Autonomous penetration testing uses specialized AI agents to find and exploit vulnerabilities in a target system without a human pentester driving each step. Sekura runs a 7-phase pipeline — white-box SAST, recon, post-quantum crypto review, dynamic probing, exploit synthesis, chain analysis, and reporting — and verifies each finding by actually exploiting it.
Vulnerability scanners output a list of potential issues ranked by severity score. Sekura verifies each finding through actual exploitation and only reports what it can prove. If a vulnerability cannot be exploited in the target environment, Sekura does not report it. The result is a short, ranked list of real, exploitable issues instead of thousands of theoretical alerts.
No. Every reported finding includes a deterministic proof-of-exploit — the exact request, payload, and response that demonstrates the vulnerability is real. If Sekura cannot produce a proof, the finding is not reported.
A manual pentest is a point-in-time engagement that takes weeks and costs $30,000 to $150,000 per cycle. Sekura runs continuously, covers the whole attack surface, and updates as your environment changes. Both produce proofs-of-exploit; only Sekura runs every hour.
Sekura works with Anthropic Claude and OpenAI GPT models. LLM calls are routed through proxy.sekura.ai so customers see exact token counts and pay one metered cost. Self-hosted Enterprise deployments can use private model endpoints.
No. The scanner runs entirely inside your GitHub Actions runner (cloud distribution) or behind your firewall (enterprise distribution). Sekura sees prompts and responses to the LLM proxy but never your repository contents. Findings are uploaded; source code is not.
The scanner CLI and agent runtime are source-available. The orchestration platform, dashboard, and managed cloud are commercial. See github.com/sekuraai for the public components.
Sekura combines application security testing (SAST + DAST + exploit chaining) with LLM-security testing (prompt injection, jailbreak, data exfiltration) and post-quantum cryptography review (crypto-agility audits flagging quantum-vulnerable algorithms) in a single scan. Most tools cover one of these surfaces; Sekura covers all three.
No. The scanner runs entirely in your GitHub Actions runner. Sekura sees prompts and responses to the LLM proxy but never your repository contents.
By attack surface envelope, not per scan. You license a number of repositories, live targets and networks, and scans inside that envelope are unlimited. What is metered is concurrent lanes — how many scans run at the same time.
Yes. Business deploys into your own cloud and Enterprise runs on-premises, including air-gapped networks. Network testing requires a runner inside the perimeter it is testing, which is why it starts at Business.
One workflow file gets added to your repo on install. Edit it freely; running `npx sekura ci-setup` again will not overwrite your changes.
One scan running at a time. A full eight-phase scan takes 10–15 minutes, so lanes determine how fast a busy pipeline clears, not how many times you are allowed to test.
Nothing breaks and no scan is blocked. We tell you which asset class you have outgrown and what the next envelope costs.
Bring your own model key on Team and Business, or use ours. Enterprise includes inference, so an on-premises deployment does not come with a model procurement problem attached.
Request a POC
Tell us what you are protecting and where it has to run. Someone from the Sekura team replies within one business day.
Someone from the Sekura team will be in touch within one business day. Check your inbox at .