Giving an autonomous AI agent production cloud credentials is traditionally an exercise in anxiety. When frontier models are tasked with discovering complex attack chains across live infrastructure, a single hallucinated CLI flag, a malformed parameter, or a hijacked reasoning loop can drop a relational database or expose an internal bucket. Most security teams resolve this tension by either pulling the plug entirely or keeping the agent confined to static code scans.
Cynative takes a different route. It is an open-source deep research agent designed to hunt for live vulnerabilities across multi-cloud environments, but it operates on a singular architectural invariant: write operations are treated as fatal errors. By enforcing a verifiable, read-only boundary across every execution layer, the agent matches attacker-level discovery without the risk of operational blast damage.
The Read-Only Boundary as a Hard Architectural Invariant
Cynative analyzes code, infrastructure configurations, and live runtimes by orchestrating frontier models via an embedded engine. The agent supports AWS, GCP, Azure, three managed Kubernetes services, self-managed Kubernetes clusters, GitHub, and GitLab.
+-------------------------------------------------------------+
| Operator Shell |
| (Ambient Cloud/Cluster Credentials) |
+------------------------------+------------------------------+
|
v
+-------------------------------------------------------------+
| Cynative Static Go Binary |
| |
| +---------------------+ +-----------------------+ |
| | Multi-Model Routing | <-----> | Embedded Sandbox | |
| | (23+ Model Backends| | (Generated Code Run) | |
| | via Bifrost SDK) | +-----------+-----------+ |
| +---------------------+ | |
| v |
| +-----------------------+ |
| | Read/Write Classifier | |
| | (Dynamic API Parsing) | |
| +-----------+-----------+ |
| | |
+----------------------------------------------+--------------+
|
[Pre-Flight Policy Check]
|
+------------------+------------------+
| |
v v
[Is Action Read-Only?] [Write / Unresolved]
| |
YES NO
| |
v v
+-----------------------+ +-------------------+
| Re-scoped Identity | | Hard Rejection |
| (STS Scoped / Viewers)| | Execution Dropped |
+-----------+-----------+ +-------------------+
|
v
+-------------------------------------------------------------+
| Target Infrastructure |
| (AWS / GCP / Azure / Kubernetes / Git) |
+-------------------------------------------------------------+
Instead of relying on isolated synthetic environments, Cynative operates directly against target environments using the ambient credentials already present in the operator's shell. To prevent accidental drift or state changes, the platform maps its execution identity to default-deny read-only primitives across every ecosystem.
| Target Platform | Default Identity Mapping | Fallback Posture |
|---|---|---|
| AWS | SecurityAudit | Default-Deny (Requires Explicit Write Allow) |
| GCP | roles/viewer | Default-Deny (Requires Explicit Write Allow) |
| Azure | Reader | Default-Deny (Requires Explicit Write Allow) |
| Kubernetes / Git | Equivalent Read-Only Scopes | Default-Deny (Requires Explicit Write Allow) |
Actions are classified and screened before any credentials attach to the request. If an operation is not explicitly provable as a read operation, it never reaches the provider's API endpoint.
Dynamic Action Classification and Provider Drift
Static permission spreadsheets deteriorate quickly. Cloud providers continuously release new APIs, expand existing service surfaces, and introduce novel actions. A static blocklist inevitably leaks unmapped write calls.
Cynative solves this by generating its action taxonomy directly from canonical upstream provider sources:
- Upstream Ingestion: For AWS, the engine parses the official Service API Reference, incorporates community data, and validates calls against AWS SDK service models.
- Runtime Caching: Classification schemas are pulled dynamically at runtime and cached locally for a configurable window (defaulting to 24 hours). Expired caches automatically refresh on subsequent runs.
- IAM Simulation Verification: Unmapped or ambiguous operations undergo simulation via
iam:SimulateCustomPolicyevaluated against the read-only baseline.
[Discovered API Operation]
|
v
+-----------------------+
| Upstream Cache Valid? |
+-----------+-----------+
|
+---------+---------+
| |
(YES) (NO)
| |
| v
| +-----------------------+
| | Fetch API References, |
| | SDK Models & Datasets |
| +-----------+-----------+
| |
+---------+---------+
|
v
+-----------------------+
| Evaluated Action |
+-----------+-----------+
|
+---------+---------+
| |
[Known Read] [Unknown / Write]
| |
v v
Execute +-----------------------+
| iam:SimulateCustom- |
| Policy Check |
+-----------+-----------+
|
+---------+---------+
| |
[Permitted] [Unresolved]
| |
v v
Execute Auto-Reject
Under this model, unknown operations face a failsafe: if an action cannot be definitively resolved as a read-only call, the engine triggers an automatic rejection. A brand-new, unindexed read action might be temporarily blocked until the next cache cycle, but a zero-day write action cannot slip past the security gate.
Prompt Injection and the Principle of Blast-Radius Containment
Running autonomous security evaluations requires exposing models to untrusted inputs: arbitrary source code repositories, runtime environment variables, container metadata, and log dumps. These surfaces can carry prompt injection payloads designed to hijack the model's objective.
Cynative separates the reasoning layer from the execution enforcement layer. The platform does not claim prompt injection immunity. Instead, it guarantees complete blast-radius containment.
Because policy enforcement sits strictly outside the LLM context in the Go runtime, a compromised reasoning path cannot grant itself write permissions, escalate its operational scope, or perform lateral movements. If an injection forces the model to emit a destructive payload, the engine rejects the generated system call at the pre-execution boundary.
To reinforce this containment:
- Delimiter Hardening: Scanned content and tool outputs are treated as untrusted data strings, stripped of closing delimiters to prevent context escaping.
- Execution Routing: Every tool output is strictly forced to return directly to the operator-defined task context rather than an arbitrary sub-routine.
Adversarial Verification Without Exploitation
Automated scanning frequently creates high noise ratios by confusing potential theoretical risks with verified vulnerabilities. Cynative incorporates a dedicated Verifier module that evaluates discoveries through an adversarial double-rebuttal pipeline.
[Candidate Finding Identified]
|
v
+------------------------------+
| Verifier Module |
| (Untrusted Evidence Read) |
+--------------+---------------+
|
v
+------------------------------+
| Independent Rebuttal #1 |
| (Adversarial Disproof) |
+--------------+---------------+
|
v
+------------------------------+
| Independent Rebuttal #2 |
| (Anomaly / Logic Audit) |
+--------------+---------------+
|
+----------+----------+
| |
[Disproven / [Unchallenged
Write-Needed] Static Read]
| |
v v
Mark Finding Mark Finding
UNVERIFIED VERIFIED
The Verifier parses raw evidence, treats the context as unvalidated, and launches two separate rebuttal processes specifically tasked with disproving the finding. If logical anomalies appear, or if proving the vulnerability requires triggering a write call or an active state mutation, the finding is discarded or marked as UNVERIFIED with low confidence.
A prime example is Cynative's detection of an OpenID Connect (OIDC) privilege escalation path. The agent flags the finding as VERIFIED not by deploying a rogue payload or mutating identities, but by completely mapping the read chain:
- Reading and evaluating the target role trust policy.
- Auditing all attached permission sets.
- Identifying a wildcard OIDC subject matched with
sts:AssumeRole. - Reading all environmental prerequisites to verify the path is mathematically reachable.
If reaching certainty requires actually firing an exploit write step, the finding remains UNVERIFIED. The system never compromises read-only purity to claim a confirmed finding.
Systems Implementation: Scoped Identity and Deterministic Auditing
The system is distributed as a single static Go binary under the Apache-2.0 license, using the Bifrost SDK to interface with over 23 model providers. This design ensures that credentials, telemetry, and model routing can remain entirely inside local or sovereign infrastructure.
To ensure strict zero-trust operations between the runtime binary and the cloud control plane, Cynative layers two complementary runtime mechanisms:
1. STS Role Re-scoping
For AWS execution paths leveraging assumed-role identities, Cynative calls the AWS STS endpoint to re-issue session credentials down-scoped with an inline managed policy. This aligns internal binary validation with external cloud IAM enforcement.
2. Fail-Closed Audit Telemetry
Every single tool invocation, query parameter, and system action is streamed to an append-only JSONL audit log. The runtime monitors this write stream with an absolute fail-closed trigger: if the logger experiences an I/O error or fails to persist a call event, the main Go process terminates immediately.
By pushing policy controls, taxonomy resolution, and identity down-scoping outside of model context, Cynative demonstrates that autonomous agents can safely operate across complex environments. The constraint is not an operational bottleneck. It is the fundamental architecture that makes autonomous investigation viable.