Cynative: Open-Source Agent Prioritizes Safety in Cloud Security Research
Cynative is a new open-source security research agent designed to safely probe cloud environments by defaulting to read-only operations and implementing strict checks against unintended modifications.
The exploration of cloud environments for security vulnerabilities, particularly when leveraging advanced AI models, carries inherent risks. A misstep by an agent with broad permissions could lead to accidental deletion of critical resources, alteration of sensitive configurations, or unintended data exposure. Cynative, a newly released open-source security research agent, directly addresses these concerns by enforcing a default read-only posture and meticulously verifying every action against this boundary.
The tool is engineered to orchestrate frontier AI models against a company's own code, cloud infrastructure, and runtime environments. Before any credentials are attached or actions are executed, Cynative runs generated code within a built-in sandbox and classifies each potential operation. It seamlessly integrates with major cloud providers like AWS, GCP, and Azure, as well as managed and self-managed Kubernetes clusters, and platforms such as GitHub and GitLab, utilizing existing operator credentials. Crucially, any write operations are an explicit opt-in, with all other actions strictly adhering to read-only policies, such as SecurityAudit on AWS, roles/viewer on GCP, and Reader on Azure.
A significant technical challenge in maintaining such a read-only boundary is keeping the classification of actions up-to-date, especially as cloud providers continuously introduce new functionalities. Cynative's approach to this problem involves dynamically resolving action classifications directly from the providers' official sources. For AWS, this includes leveraging the Service Reference API, with the community iam-dataset and AWS SDK service models serving as fallbacks. These sources are fetched at runtime and cached for a configurable period, typically 24 hours, ensuring that newly published actions are incorporated into the agent's policy on subsequent runs.
Even actions that are not yet mapped or understood by the agent are handled with a fail-safe mechanism. Any operation that Cynative cannot definitively classify as permitted by its read-only policy is denied outright. This is further reinforced by AWS's iam:SimulateCustomPolicy check, which ensures that even newly introduced write actions are blocked if they are not explicitly included in the read-only policy. This robust checking prevents unintended writes from being executed, with the worst-case scenario being a temporary over-denial of a new read action, rather than a write being mistakenly allowed.
While the read-only boundary effectively constrains actions, it does not inherently protect against sophisticated prompt injection attacks that could poison the AI model's reasoning process. Cynative feeds source code, cloud configurations, and runtime data directly into the model, any of which could be manipulated to steer the agent toward erroneous conclusions. The tool's design acknowledges this gap, stating that it does not claim immunity to injection but rather guarantees containment. This means that even if an injection is successful, the damage is bounded by the read-only rule, preventing it from escalating into unauthorized write operations, lateral movement, or other harmful actions.
To further enhance containment, Cynative fences all tool output and scanned content as untrusted data, employing mechanisms to prevent content from breaking out of its designated boundaries. Each tool call is meticulously traced back to the operator's task, ensuring accountability. Findings are then subjected to a second verification gate before being confirmed. A dedicated verifier component reads the raw evidence, treats it as untrusted, and performs two independent refutation passes. If any anomaly is detected during these passes, the verification process fails closed, preventing a single compromised step from yielding a falsely verified result.
This verification process operates entirely within the read-only sandbox, raising questions about how proof is established for certain types of findings, such as privilege escalation. Cynative's demonstration showcases a verified OIDC privilege-escalation path, achieved not through exploitation, but through meticulous reading of accessible data. The agent examines the role's trust policy and attached permissions, identifying a wildcard OIDC subject combined with IAMFullAccess, which are all directly readable preconditions for the escalation. Findings that would require write operations for proof remain marked as 'UNVERIFIED' and carry low confidence, reinforcing the agent's commitment to its read-only stance.
Several design choices bolster Cynative's read-only commitment. Every tool call is logged in a persistent JSONL audit log, with the run aborting if a call cannot be recorded. For AWS assumed-role identities, credentials are re-vended through STS with a scoped managed policy, ensuring that IAM enforces the agent's read-only boundary. The project is distributed as a static Go binary under the Apache-2.0 license and supports over 23 model providers via the embedded Bifrost SDK, allowing operators to maintain control over their data and model choices within their own environments. Cynative's core feature is its self-imposed restraint, enabling it to reason about cloud environments like an attacker might, while earning trust by demonstrating what it can read and strictly declining to modify anything else.