Cynative Security Research Agent
Ask your cloud anything without breaking prod. Read-only.
85 followers
Ask your cloud anything without breaking prod. Read-only.
85 followers
Open-source AI CLI that answers security questions across cloud, code and runtime - GitHub, GitLab, AWS, GCP, Azure, K8s. Ask in plain language: "what's publicly exposed that shouldn't be?" or "can my CI escalate to cloud admin?". Read-only by construction: every call is resolved to its IAM actions and authorized against a read-only policy before credentials attach. It can't modify your infra even if asked. Unlike MCP tools, it writes JS in a sandboxed runtime - a script per turn, not one call.
Cynative Security Research Agent
A debate we had: do we just document how to scope credentials right and leave it to you - or enforce read-only even if you run it with admin creds? We went with enforcing it, despite the tradeoff of keeping up as providers ship new APIs. Pulling permission definitions from each provider (a few MB, daily by default) instead of a static map keeps coverage current automatically. Every API call is resolved to the IAM actions it needs and authorized against the provider's own policy definitions before a credential is attached, failing closed on anything it can't classify. The allowed sets come from the providers themselves (AWS IAM action simulation, GCP role permission eval, Azure RBAC role definitions, the K8s cluster own live view RBAC role) so coverage tracks the APIs as they grow. On AWS, assumed-role credentials are additionally re-vended through STS AssumeRole scoped to SecurityAudit. Every request host is pinned to its mapped service and region and the resolved IP is verified before connecting, so the agent can only reach your own infra. The code execution has no host access and every call is enforced to go through the read-only action gate or it fails.
Cynative Security Research Agent
I'll be around, happy to answer any question.
Pythagora
@szin Looks super exciting and thoughtfully made. Congrats on getting it out into the world! 🚀
Enforcing it rather than documenting it is the right call, and "failing closed on anything it can't classify" is the line in your comment that would make me trust this.
The follow-up I would want: what do I actually see when it fails closed? If an unclassifiable call gets skipped quietly, I get an answer that looks complete but is missing an account, a region or a resource type, and no way to know which. In a security context that is worse than an error, because I will act on it. If the run tells me plainly that three calls were refused and this answer therefore excludes X, that is something I can put in front of an auditor.
I ship something whose whole premise is that it cannot act, and the thing that surprised me is that enforcement is not what convinces people. Nobody believes a read-only claim from the description. They believe it when they can check it themselves in about a minute without reading your source. Pulling permission definitions from the providers daily is a strong answer and it is also invisible to the person deciding whether to point this at prod, so it is worth making that checkable from the outside rather than only true on the inside.
Cynative Security Research Agent
@sam_mcewen Thanks Sam! You get notified on a fail and the error comes back to the model also so it can decide to write a new script, the hard stop is repeated no-progress calls tripping a consecutive-failure ceiling, default 5. The final summary report you'll receive from the agent has the fails in context so it will tell you if the research task is not complete.
Shaked — the "script per turn, not one call" design is neat. Curious what happens when one call inside that script hits something outside the read-only gate — full abort, or does it just fail that line and move on? My own agent chains multi-step calls, and one blocked step derailing the whole run is a real pain.
Cynative Security Research Agent
@medal411 Thanks! Keeps running. Inner tool calls are async inside the sandbox - if the script catches it, it carries on with whatever else succeeded. If it doesn't catch, that one script ends, but the error comes back to the model and it writes a new script for just the missing data, same session. So a blocked step costs an llm turn, not the run. The hard stop is repeated no-progress calls tripping a consecutive-failure ceiling, default 5, instead of letting it spin.
fail-closed-by-default on the classification is the right call, but it raises a timing question - you pull permission definitions daily, so what happens on the day a provider ships a brand new API action that isn't in that day's pull yet. does it just refuse to classify it and block the call until the next sync picks it up, or is there some other fallback for that gap window
Cynative Security Research Agent
@galdayan Thanks Gal! Two cases. New action on a service we already model: no gap - the resolver derives namespace:op off the classified operation, and the decision is a live iam:SimulateCustomPolicy against your policy. A brand new service that isn't in the cached catalog: hard deny until refresh, we won't guess. TTL is 24h and configurable.
@szin 24h fixed with no override is the right default honestly - anything shorter and you'd probably get flaky false-denies during normal AWS rollout jitter. good that it's configurable for teams who ship on faster cycles though.
The promise of investigating cloud infrastructure without risking production is compelling. How do you enforce read-only boundaries, and does every finding include the evidence and cloud resources used to reach it?
Cynative Security Research Agent
@russlan_ramdowar Thanks! Every request is host-pinned, then resolved to its required IAM actions and checked against your read-only policy before a credential is attached - SecurityAudit, roles/viewer, Reader, the cluster's live view role. Unresolved means denied. AWS assumed roles also get STS-scoped so AWS enforces it server-side too. Code runs sandboxed with no filesystem, network or host APIs.
Findings carry their raw evidence and a verifier cross-checks each against live evidence before it's reported. Every tool call hits a fail-closed audit log, so the calls behind a finding are replayable.
the read-only enforcement design is genuinely more thorough than most tools that just document best practice and hope you follow it. one thing I'd want answered before pointing this at a real environment though - the answers this thing produces are basically a complete map of what's exposed and how to get to it. where does that output live once it's generated, and is there any access control on the audit history itself, since that history becomes a pretty valuable target on its own
Cynative Security Research Agent
@omri_ben_shoham1 thanks! The report isn't stored - it goes to your terminal and that's it. The audit log retains (configurable), it's a local file on your machine: tool calls plus the findings sent to verification, secrets redacted.
@szin makes sense, and redacting secrets before it hits disk is the right default. the part that still nags at me - a local file is exactly the kind of thing that ends up in a laptop backup or synced to some cloud drive without anyone deciding that on purpose. is there a documented way to pipe that audit log somewhere with actual access control, like a SIEM or a locked-down bucket, or is "local file on your machine" the intended end state for now?
Cynative Security Research Agent
@omri_ben_shoham1 Yes, absolutely. Audit log can be disabled / path changed and you can pipe the report: cynative -p "your task" > ./report.md