✓ Human-authored analysis; AI used for formatting and proofreading.
An AI agent generates a CDK construct. It provisions an ECS cluster, an ALB, security groups, IAM roles, an ECR repository, and a CI/CD pipeline. It deploys to staging. Everything runs.
Nobody checks whether the IAM role is least-privilege. Nobody checks whether the security group allows egress to 0.0.0.0/0. Nobody checks whether the pipeline role can access resources it shouldn't. The agent built the infrastructure correctly. It runs. But "it runs" and "it's secure" are different claims.
This is the gap that keeps widening. The tooling for AI-generated infrastructure is maturing fast such as CDK skills, Terraform generators, CloudFormation agents. The tooling for verifying that infrastructure is not keeping up.
We registered Stave as a resource in the Agentic Resource Discovery specification.
What is ARD
ARD (Agentic Resource Discovery) is a federated standard for cataloging and discovering agentic resources. MCP servers, A2A agent cards, Skills, APIs, and other callable services. When an AI agent needs a capability it doesn't have, ARD is how it finds one.
Think of it as DNS for agent tools. An agent building a web application searches ARD for database, finds a managed Postgres service, and calls it. The agent didn't need to know about that specific service in advance. Discovery is federated, domain-anchored, and standardized.
What was missing
ARD catalogs resources that help agents do work. APIs to call. Services to provision. Skills to execute. Every resource type in the current spec assumes the agent is looking for something to help it build, create, or act.
Nobody had registered a resource that helps agents check their work.
That's the category gap. An agent that generates infrastructure needs to discover not just the tools to build it, but the tools to verify it. Build and verify are different capabilities, and until now ARD only covered the first one.
What we registered
Stave is now discoverable as a verification service through ARD. An agent searching for "cloud configuration verification" or "AWS security posture" finds Stave's resource descriptor, which declares:
Input: AWS configuration observations in JSON which is a snapshot of what's deployed, without live API access. No credentials required.
Output: Findings in JSON showing which security properties pass, which fail, what severity, and which failures compose into compound attack paths.
Capabilities: 3,454 controls across 131 AWS services. 748 compound chains that connect findings across resources into attack paths. Deterministic that outputs same output for the same input, every run.
An agent that just generated an ECS deployment can discover Stave, pass it the deployed configuration, and get back a structured answer: these IAM roles are overprivileged, this security group allows unrestricted egress, and together they create a compound path from the internet to your data store.
The agent doesn't gate on "did it deploy successfully." It gates on "does the deployed configuration satisfy security invariants."
Why no credentials required matters for discovery
Most security tools need credentials to the target environment. They run inside your account, assume a role, and scan live resources. That makes them hard to discover and call as an agentic resource. The agent would need to provision credentials, grant permissions, and manage the trust relationship before it can even ask the question.
Stave operates on snapshots. The agent exports the configuration state (or a collector produces it), passes the JSON, and gets findings back. No IAM role to assume. No cross-account trust to configure. No credentials to manage. The interface is: JSON in, JSON out.
That makes it work as a discoverable resource. An agent finds it via ARD, calls it with a snapshot, gets findings. The trust model is the data, not the infrastructure.
The verification gap in agent workflows
Consider what happens today when an agent builds infrastructure:
A CDK skill takes a Dockerfile and generates a two-stack CDK app for ECS. It analyzes the code, plans the resources, generates the infrastructure, and generates the pipeline. The output is a deployable application with all the AWS scaffolding.
The skill has four phases: analyze, plan, generate, deploy. There is no fifth phase. Nobody verifies that the generated IAM roles are least-privilege. Nobody verifies that the generated security groups are scoped. Nobody verifies that the pipeline role isn't overprivileged. The skill finishes when the deployment succeeds, not when the deployment is secure.
With ARD discovery, a fifth phase becomes automatic. The agent searches for a verification service, discovers Stave, passes the deployed configuration, and evaluates the findings before promoting to production. The verification service is discovered at runtime, the same way the agent discovers any other capability it needs.
What this means for infrastructure
The Twingate team recently launched privileged access for web apps, noting that "the people vibe-coding a growing share of internal tools often don't know how to build authentication securely in the first place." Twingate solves the auth problem by putting it outside the app.
The same pattern applies to infrastructure security. The person coding an internal tool probably can't write a least-privilege IAM policy either. The CDK skill generates one. But the CDK skill was trained on the same general patterns as the person it replaced. The generated policy might be fine. It might be PowerUserAccess. Nobody checks.
Discoverable verification services change the default. The agent that generates the infrastructure can also discover the tool that checks it without the developer knowing about either. The security verification becomes part of the agent's workflow, not the developer's expertise.
What we proposed to the ARD spec
We submitted a proposal to add "verification service" as a resource type in the ARD specification. The current spec covers MCP servers, A2A agent cards, Skills, and APIs. All of these are resources agents call to do work. We proposed a category for resources agents call to check work.
The proposed type includes fields for input format (what the service accepts), output format (what it returns), verification model (snapshot, continuous, or pre-deploy), and credential requirements. It's generic enough for any verification tool. A Terraform validator, a CloudFormation linter, a Kubernetes policy engine or any tool that takes a description of infrastructure and returns structured findings fits this category.
The proposal matters because the category itself is what's missing. Once "verification service" is a recognized resource type in ARD, every agent framework that implements ARD discovery can find verification tools automatically. The agent doesn't search for "Stave", it searches for "verification," and gets back whatever services are registered in the domain it's operating in.
The arc of agent-driven infrastructure
Today, agents generate infrastructure. Tomorrow, agents generate and deploy infrastructure. The day after, agents generate, deploy, verify, and remediate infrastructure. Each step in that arc requires the agent to discover new capabilities and the capabilities for building are ahead of the capabilities for checking.
ARD is how the checking catches up. Not by building verification into every agent (that doesn't scale), but by making verification discoverable as a service any agent can call.
We registered Stave because it exists today and does this today. The category should exist in the spec, so that the next verification tool, and the one after that, are equally discoverable.
Stave is an open-source cloud configuration verifier. It evaluates AWS configuration snapshots against system invariants and finds compound attack paths that single-resource scanners miss — no credentials required.
ARD is the Agentic Resource Discovery specification — a federated standard for cataloging and discovering agentic resources.
Top comments (0)