Cynative Security Research Agent

Ask your cloud anything without breaking prod. Read-only.

Open Source

Developer Tools

Security

Visit WebsiteSee on Product HuntGithub ⧉Twitter ⧉

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.

@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?

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

ran a couple of checks against our AWS setup and the read-only guard is genuinely enforced, not just a claim. the per-turn sandboxed scripts feel like the right way to do this instead of hoping an MCP tool behaves.

Honestly love that the IAM-bound read-only layer is the default, not a setting you have to remember to flip on. Most security tools treat least-privilege as homework, you basically baked it into the call path. That kind of restraint takes real thought.

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?

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

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.

Hi Shaked, the reassurance that it only ever reads and never touches my systems is exactly what would make me brave enough to really poke around a live setup. That peace of mind matters more than people tend to admit.

Enforcing read-only even when someone gives it broader credentials is the part I like here. Relying on everyone to configure access perfectly would probably defeat the point pretty quickly. Congrats on the launch!