Cynative is designed so that it cannot modify the infrastructure it inspects and cannot widen its own access — whatever the model does. Every connector call crosses an action gate, every host is pinned, credentials are never visible to the model, and research code runs in a sandboxed environment with no network or filesystem access of its own. These are not opt-in controls; they are structural properties of the system.
Design intent
Cynative is designed so that it does not modify the infrastructure it inspects and cannot widen its own access, whatever the model does. The controls below are how that is enforced.
Trust boundaries
There are three trust boundaries the model cannot move:
-
Model to agent — every tool call the model makes crosses the action gate. The gate resolves the required IAM actions from the providers’ own API definitions, authorizes them against the configured read-only policy, verifies the host and resolved IP address, and attaches a credential only after all checks pass. The model never chooses the policy.
-
Sandbox to host — scripts running inside the JS sandbox are given only the tool functions Cynative explicitly exposes. They have no network access of their own, no filesystem access, and no ability to import packages. A script can only call Cynative’s tools and observe what those tools return.
-
Agent to provider — credentials attach only after the gate authorizes the request and after the host and resolved IP are verified. When the operator configures a proxy, the connection goes only to that proxy; destination resolution and address enforcement are then the proxy’s responsibility (see Proxy).
Controls
Always provide the least-privileged credentials the task requires. The action gate is client-side software — it is not a substitute for upstream credentials with narrow permissions. If the credentials themselves are overprivileged and the gate is somehow bypassed (for example through a proxy that rewrites the authorization data it is built from), the blast radius is your credentials’ permissions, not the gate’s.
Countermeasures
Command injection
Model output never reaches a shell or the host process. Research code runs in the JS sandbox; the sandbox has no exec, no subprocess, and no mechanism to run commands on the host. There is no code path from model output to a host-side shell invocation.
Request redirection
Hosts are pinned to their connector’s mapped service and region. The resolved IP address is additionally verified before the connection is made on a direct route. Non-ASCII request hosts are refused — case folding and IDNA conversions can turn one name into a different one, and only one of the results would be the name the gate authorized. Address literals carrying zone identifiers are refused for similar reasons. On a proxied connection, host pinning still applies; destination IP verification is then delegated to the proxy.
Credential exfiltration
Credentials are redacted from tool results before they are returned to the model, from every line written to the audit log, and from every line the LLM SDK logs. The model never holds a credential value. Reasoning content a model returns is replayed to the backend that produced it (some formats require byte-for-byte replay) but is never displayed, audited, or logged by Cynative itself; any credential echoed in SDK warnings or upstream error messages is redacted like any other line.
Sandbox escape
The JS sandbox exposes only the tool functions Cynative provides. It has no built-in network access, no require/import, no filesystem access, and no ability to spawn processes. A script can observe only what those tools return.
The api_reference tool runs without an approval prompt for Kubernetes connectors. It reads the target cluster’s metadata (GET /version, GET /openapi/v3, GET /openapi/v3/<group-version>) at paths Cynative builds from validated names — never at a URL the model wrote — through the same host pinning, read-only gate, dial guard, and redaction as http_request. Every value naming a cluster is validated against the vendor’s identifier grammar before any call. Lookups are audited with decision unprompted.
Repository-supplied prompts
Agents are read only from ~/.cynative/agents/ and the binary, never from the working directory. Selection is always explicit by name; the model never chooses an agent. Every audited tool call records the agent’s name, source, and file digest, so any finding can be traced to the exact prompt that produced it.
Limitations
The action gate is a client-side control with documented, inherent limits:
- IAM users and root credentials — only AWS assumed-role identities get credential downscoping via STS. IAM user and root credentials run with their base permissions, gated only by the client-side action gate. Provide least-privileged credentials for these identity types.
- Intercepting proxies — an intercepting proxy can rewrite the authorization data (ClusterRole, IAM policy documents, permission catalogs) the action gate is built from. A rewritten policy widens what the gate allows. Only route Cynative through a proxy you trust with the credentials themselves. See Proxy for details.
- Provider coverage — the gate derives its allow-list from providers’ own API definitions and tracks those as they grow. Any API operation not yet classified by the gate is denied (fail-closed), but novel cloud APIs introduced between releases have a coverage gap until the next update.
- GCP and Azure — neither provider has a credential downscoping primitive equivalent to AWS STS. For GCP and Azure the client-side action gate and the operator-supplied credential permissions are the sole enforcement layers.
Reporting vulnerabilities
Please do not open a public GitHub issue for security reports.
Use one of these private channels:
Include in your report:
- The Cynative version — please confirm it is the latest release
- How Cynative was installed
- A clear description of the issue and its security impact
- Steps to reproduce the behavior
- Relevant logs
Do not include live credentials, tokens, secrets, or customer data in a report.
Cynative aims to acknowledge reports within 3 business days and to coordinate public disclosure of confirmed vulnerabilities within 90 days. 
