Sovereign cybersecurity foundation models
Cyber Super Intelligence, Fully Yours
Cynative is building super intelligence for defensive cybersecurity. You decide where it runs and what it is tuned on. It answers only to you.Start building security agents today with our open source framework.
Sovereign cyber AI. Under your control.
Your cloud or air-gapped. The weights and the context stay in your perimeter.
Your infrastructure, code and findings, as context. Tunable on your own data.
Security work. Each answer carries its reasoning and its evidence.
The attacker has a frontier model. The defender needs one that is fully theirs.
The frontier labs ship models on their terms: access programs, hosted inference, weights that never leave them and training that never saw your environment.
What's ours is yours: the model runs where your infrastructure is, it's grounded in your environment and answers only to you.
Shape the model. Get it first. The design partner program is for the teams deciding what their sovereign security model has to do.
Become a design partnerThe whole system, published.
A cyber model's results are a property of the whole system: the model, the harness around it, the policy that bounds it and the verifier that checks its findings. We publish the whole system. The threat model, the action gate, the audit log and all 45 agents are open source.
Ask your infrastructure anything.
An open-source agent framework for security engineers, with live, read-only access to your infrastructure. It runs the frontier model of your choice across GitHub, GitLab, AWS, GCP, Azure and Kubernetes as one system, verifies each finding against live evidence, and keeps what it reads in your environment. Point it at the model your cloud already runs and the model, the agent and the data share one account. 45 built-in agents ship in the binary; yours use the same file format.
Safe to point at production.
Read-only by construction. Each call is authorized before a credential is attached, on three layers.
- 01 · Action gate Each operation is resolved to the IAM actions it requires, from the providers' own API definitions, then authorized against a read-only policy before a credential is attached. Anything classified as a write fails closed.
- 02 · Network Each request host is pinned to its service and region, and the resolved IP is verified before connect. The agent reaches your infrastructure and only your infrastructure.
-
03 · Credential
On AWS, assumed-role identities are re-vended through STS scoped to
SecurityAudit. IAM enforces the boundary a second time.
What it finds.
Built-in agents for AWS, Azure, GCP, GitHub and Kubernetes, by domain. Each one is a reviewed methodology, published in full.
Paths from each principal to administrative control, and the calls that walk them.
Internet paths that complete end to end, and what the identity behind each one reaches.
Effective public and cross-account access to buckets, datastores, snapshots and resource policies.
Long-lived keys, hardcoded secrets, exportable service account keys and vault access paths.
Workflows that run untrusted code with credentials, unprotected branches and unpatched dependencies.
Regions, alarm paths and audit configurations where activity would produce no signal.
Who can invoke Bedrock, Azure OpenAI and Vertex AI endpoints, and whether abuse would be recorded.
API server, kubelet and controller reachability, and the identities that hold cluster admin.
Unsupported versions, unencrypted data and transport, unrecoverable resources and dangling DNS.
From the blog.
October 19, 2026 · Cynative ResearchHow We Write Security Agents
What we learned writing 45 security agents and running them against live AWS, Azure, GCP, Kubernetes and GitHub estates.