> ## Documentation Index
> Fetch the complete documentation index at: https://docs.cynative.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Cynative Security Model: Trust Boundaries and Controls

> Cynative's defense-in-depth security model: action gate, host pinning, JS sandbox, credential handling, and how to report vulnerabilities.

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:

1. **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.

2. **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.

3. **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](/proxy)).

***

## Controls

| Control | How it is applied |
| - | - |
| **Least privilege** | Action gate authorizes against `SecurityAudit` (AWS), `roles/viewer` (GCP), `Reader` (Azure), and the cluster's live `view` RBAC role (Kubernetes). For AWS assumed-role identities, credentials are re-vended via STS scoped to a managed policy, so AWS IAM enforces the boundary independently in addition to the client-side gate. GitHub and GitLab are read-only by default, with secret-scanning and GraphQL endpoints blocked regardless of permission settings. |
| **Fail closed** | Anything unclassified, unresolvable, or not explicitly allowed by the configured policy is denied. There is no allow-by-default path. |
| **Complete mediation** | Authorization is evaluated per request, not per session. A credential is not cached in an authorized state; every call is independently gated. |
| **Defense in depth** | Three independent layers: the client-side action gate, host pinning with IP verification, and provider-side IAM (for AWS assumed-role identities). Defeating one layer does not defeat the others. |

<Warning>
  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.
</Warning>

***

## 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.

### Unprompted metadata reads

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](/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:

* **GitHub private advisory (preferred):** open a draft at [github.com/cynative/cynative/security/advisories/new](https://github.com/cynative/cynative/security/advisories/new)
* **Email:** [security@cynative.com](mailto:security@cynative.com)

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**.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.