Why a CLI tool became an agent-ready cloud security platform

When the founder of a new security startup began building a tool for solo developers, they never intended to create an agent-ready platform. The goal was simple: create a maintainable command-line interface that one person could manage without juggling proprietary schemas or non-deterministic outputs. Fourteen months later, their creation had quietly become the first agent-centric cloud security solution — and the transformation came from decisions made for human productivity, not AI compatibility.

The shift began with foundational choices that prioritized clarity and determinism. Instead of inventing a custom data format, the team adopted standard JSON Schema for specifications. Exit codes replaced verbose prose in outputs, and deterministic evaluation replaced probabilistic scoring. Small, composable tools replaced monolithic pipelines, ensuring that every step was maintainable by a single developer. These decisions weren’t made with agents in mind, but they turned out to be exactly what agentic systems needed.

The unexpected rise of agent-centric security

Security vendors today are racing to embed AI features such as copilots that summarize findings or chatbots that explain remediation steps. While useful, these features often bolt AI onto human-dependent architectures. Agent-centric security, by contrast, treats agents not as consumers of insights but as active participants in the security pipeline.

The key test is straightforward: can an agent with no prior access to your codebase produce accurate security verdicts using only published contracts? If yes, the tool is agent-centric. If it requires code, internal documentation, or human guidance, it’s merely AI-enhanced human workflow.

In five independent trials, agents passed this test — including two blind runs with zero prior context. The agents were given only reasoning specifications and exported data, yet they produced correct verdicts across five different reasoning engines: Z3, Soufflé, Clingo, Prolog, and PRISM. No implementation hints. No documentation beyond the specification. Just contracts and data.

How contracts replaced human interpretation

Every interaction within the platform is governed by three machine-readable contracts:

• Specification contracts: JSON Schema or YAML files define inputs, outputs, and constraints. Agents parse these directly instead of relying on human-readable documentation.
• Binary assertions: Commands like stave validate --strict return exit code 0 on success or non-zero on failure. There’s no ambiguity. Findings are deterministic: they either match the contract or they don’t.
• Actionable errors: When a contract fails, the error explicitly identifies the problematic field and expected value. Agents read the error, correct the input, and retry — no human interpretation required.

The pipeline is built entirely on these contracts:

Steampipe table schema → Published mapping YAML (agent reads column names) → stave validate --strict (exit 0?) → stave apply (deterministic findings) → stave export-sir (JSONL triples / SMT-LIB assertions) → reasoning-spec YAML (agent maps logic → engine code) → golden answer comparison (matches?)

Each arrow represents a contract. Each contract is machine-verifiable. Agents traverse the pipeline the same way developers do — except they never need to ask whether a step is correct. The contracts provide the answer automatically.

What five trials revealed about agent reasoning

The trials used reasoning specifications written in YAML. Each spec described a security question, input data, reasoning steps, and expected output format — but not implementation code. Agents translated logic constraints into engine-specific syntax, such as Soufflé Datalog or Z3 SMT-LIB. The expected answers were withheld during testing.

The results were consistent:

• Z3: Correctly determined whether anonymous users could reach an S3 bucket, returning a valid SAT witness (attack path).
• Soufflé: Accurately counted reachable resources for an anonymous identity, matching the expected byte-identical value of 12.
• Clingo: Identified which violation rules triggered on a given configuration, with 100% accuracy.
• Prolog: Generated correct proof trees for attack paths, totaling 12 valid trees.
• PRISM: Calculated the probability of successful exploitation at 0.412, within ±0.005 of the expected value.

Two trials even uncovered defects: one in the team’s test suite (a transcription error) and one in the specification (a field naming ambiguity). The contracts allowed agents to highlight these issues without human intervention, proving their utility far beyond agentic workflows.

No other cloud security platform has demonstrated that agents can derive correct security judgments from published contracts alone.

What this means for enterprise security programs

Traditional cloud security posture management has always been a team effort. Deploying a solution typically requires:

• A team of engineers to maintain proprietary formats and schemas.
• Manual validation of non-deterministic outputs.
• Extensive documentation for human operators to interpret results.
• Ongoing oversight to correct probabilistic assessments.

Agent-centric platforms eliminate much of this overhead. Since every step is governed by machine-readable contracts and binary assertions, agents can assume responsibility for large portions of the pipeline. This doesn’t just reduce human workload — it enables continuous, automated evaluation at scale.

For enterprises, this shift promises faster detection of misconfigurations, fewer false positives from deterministic logic, and greater scalability as security tooling becomes programmable. The architecture that started as a solo developer’s productivity tool has become a foundation for a new class of intelligent security systems.

The next frontier isn’t just adding AI to security tools — it’s designing platforms where AI can operate independently, securely, and correctly. Contracts made that possible.