AI & TechArtificial IntelligenceCybersecurityNewswireTechnology

Cynative: Open-Source AI for Deep Research

Originally published on: July 14, 2026
▼ Summary

– Cynative is an open-source security research agent that operates with a default read-only policy, refusing to perform any write actions unless explicitly opted in.
– The agent reaches multiple cloud platforms (AWS, GCP, Azure) and services, classifying actions as read or write using live sources from providers rather than a manually maintained mapping.
– Any unmapped or new action is denied by default, preventing writes from being allowed through, with the worst case being a temporarily over-denied read.
– The read-only boundary contains the impact of prompt injections by preventing poisoned reasoning from turning into any write or lateral action, while not claiming full injection immunity.
– Findings are verified through an adversarial refutation pass that reads evidence without exploiting or writing, leaving issues requiring writes as unverified with low confidence.

Running a large language model against a live cloud account to hunt for security holes carries an obvious risk. An agent holding real credentials and a mandate to probe can accidentally delete a bucket, flip a permission, or leak a secret on its way to a finding. Cynative, an open-source security research agent, addresses that risk by refusing to write anything by default and verifying that refusal on every single call it makes.

The tool orchestrates a frontier model against a company’s own code, cloud, and runtime. It runs generated code in a built-in sandbox and classifies each action before any credential is attached. Cynative reaches AWS, GCP, Azure, the three managed Kubernetes services, self-managed clusters, GitHub, and GitLab using whatever credentials already sit in the operator’s shell. Writes require an explicit opt-in. Everything else stops at a read-only policy: SecurityAudit on AWS, roles/viewer on GCP, Reader on Azure.

The hard part of that promise is keeping the map of which actions read and which write current as cloud providers add new actions week to week. Shaked Zin, co-founder of Cynative, said the classification comes from the providers’ own live sources. “The mapping isn’t a table we maintain by hand – it’s resolved from the providers’ own live sources,” he told Help Net Security. For AWS the agent reads the Service Reference API, with the community iam-dataset as a fallback and AWS SDK service models for operation classification. Those sources are fetched at runtime and cached for a configurable window, 24 hours by default, so a provider’s newly published actions get picked up on the next run past that window.

A brand-new action that has yet to be mapped still receives a verdict. Anything the agent cannot resolve to an action the read-only policy grants is denied outright. A new action gets the same treatment through AWS’s iam:SimulateCustomPolicy check against that policy. “A new write isn’t in a read-only policy so it’s denied; worst case is a new read briefly over-denied, never a write let through,” Zin said.

The read-only boundary handles actions. It does nothing for the model’s reasoning, and that gap matters because Cynative feeds source code, cloud configuration, and runtime data straight into the model. Any of that could carry text written to steer the agent toward a false conclusion. “The read-only gate constrains actions, not a poisoned chain of reasoning, and we don’t claim injection immunity. What we do claim is containment,” Zin said.

Containment, in his account, means the damage from a successful injection stays bounded. Because the read-only rule lives outside the model, a poisoned input can corrupt a conclusion and go no further. “It cannot turn into a write, a lateral move, or any action. That separation is the guarantee,” Zin said. The agent also fences all tool output and scanned content as untrusted data, escapes the closing delimiter so that content cannot break out of its boundary, and requires every tool call to trace back to the operator’s task.

Findings then pass through a second gate before the agent calls them confirmed. A verifier reads the raw evidence, treats it as untrusted, runs two independent refutation passes, and fails closed on any anomaly. One poisoned step cannot mint a verified result.

That verification runs entirely inside the read-only sandbox, which raises a question about proof. Confirming that an over-privileged role can escalate to account takeover would ordinarily call for a write or an intrusive step. Cynative’s demo marks exactly such an issue, an OIDC privilege-escalation path, as VERIFIED. Zin said the verdict comes from reading, never from exploiting. “Verification confirms from readable evidence, not by exploiting,” he said. In the demo the agent reads the role’s trust policy and its attached permissions, finds a wildcard OIDC subject paired with IAMFullAccess, and every precondition for the escalation turns out to be directly readable.

Findings whose proof would need a write stay marked UNVERIFIED and carry low confidence. “The verification is an adversarial pass that tries to refute each finding; what it can’t confirm stays UNVERIFIED – low-confidence. It never writes to reach a verdict,” Zin said.

A few design choices reinforce the read-only stance elsewhere. Every tool call lands in a persistent JSONL audit log that aborts the run if a call cannot be recorded. For assumed-role AWS identities, credentials get re-vended through STS with a scoped managed policy, so IAM enforces the same boundary the agent does. The project ships as a static Go binary under Apache-2.0 and talks to 23 or more model providers through the embedded Bifrost SDK, which lets an operator keep both the data and the model choice inside their own environment.

The result is an agent that treats its own restraint as the feature. It reasons across a stack the way an attacker might, and it earns trust by proving what it can read and declining to touch the rest.

Cynative is available for free on GitHub.

Must read:

Subscribe to the Help Net Security ad-free monthly newsletter to stay informed on the essential open-source cybersecurity tools. Subscribe here!

(Source: Help Net Security)

Topics

security agent tool 95% read-only policy 92% cloud provider support 88% action classification 86% injection containment 84% verification process 82% open source availability 80% credential safety 78% audit logging 76% model orchestration 74%