Governance in Spec-Driven Development

A reproducible GCP example using GitHub Spec Kit, SicarioSpec, Terraform, Checkov, and Conftest to turn AI-assisted intent into enforceable policy and evidence.

AI coding agents can generate infrastructure quickly. They cannot infer an
organization's authoritative risk decisions from a seven-word request.

Consider this prompt:

Create a GCP bucket for customer documents.

That is enough to produce Terraform. It is not enough to decide:

• How the data is classified
• Which regions and retention periods are allowed
• Whether public access or object ACLs are prohibited
• Which workload identities may access the bucket
• Whether CI may use long-lived credentials
• Which logs, labels, tests, and evidence are required
• Who may approve a plan or run terraform apply

Seven words create direction—not an infrastructure specification.

This post walks through a reproducible example using
GitHub Spec Kit,
SicarioSpec, Terraform,
Checkov, and OPA/Conftest. The objective is not to claim that automated gates
make infrastructure secure. It is to show how a specification can make
security obligations explicit, testable, and capable of stopping delivery.

Why the specification matters

A common AI-assisted workflow looks like this:

prompt -> generated code -> review -> patch the missing decisions

Spec-Driven Development (SDD) moves the decisions earlier:

principles -> specification -> clarification -> plan -> tasks
           -> implementation -> validation

GitHub Spec Kit provides the workflow structure:

• A constitution for durable project principles
• A specification for the intended behavior and outcome
• A plan for architecture and technology decisions
• A task list for executable work
• Analysis and validation against the declared intent

Spec Kit also provides extension points through presets, extensions, and
bundles. SicarioSpec is an independent, community-authored governance bundle
for that ecosystem. It adds governed artifact templates, threat and risk
workflows, data classification, evidence requirements, policy-as-code
starters, CI integration, control maps, and companion CLI verification.

The core distinction is simple:

A specification that mentions security is not necessarily governed. A
governed specification makes security obligations explicit, traceable,
testable, and enforceable.

Turning the request into a security contract

I initialized the demonstration with the cloud infrastructure, security
toolchain, and compliance profiles:

sicario init gcp-customer-documents \
  --integration all \
  --profile cloud-iac,security-toolchain,compliance \
  --frameworks ccm

The selected CSA CCM map is an illustrative traceability surface. Selecting a
control map does not claim certification, legal applicability, or that every
control is satisfied.

The feature specification required:

• Confidential data classification
• Explicit residency and retention decisions
• public_access_prevention = "enforced"
• Uniform bucket-level access instead of object ACLs
• A dedicated service account with bucket-scoped object access
• Workload identity federation for CI
• No service-account keys
• Required governance labels
• Terraform, Checkov, Conftest, and SicarioSpec evidence
• Named human approval before any plan is applied
• No automatic or agent-authorized terraform apply

The specification becomes a security contract: classify, constrain, test, and approve.

The requirements reflect separate control layers. Google recommends
uniform bucket-level access
for a unified IAM model and documents
public access prevention
as a separate control against public principals. For CI,
workload identity federation
avoids the operational and security burden of service-account keys.

Negative tests: valid syntax, unacceptable policy

I created an unsafe Terraform-plan fixture before accepting the corrected
infrastructure. The fixture deliberately:

• Used US-EAST1, which was not an approved region
• Left public access prevention as inherited
• Disabled uniform bucket-level access
• Omitted the required labels
• Granted roles/storage.objectViewer to allUsers
• Created a long-lived service-account key

Terraform validation passed. That is expected: provider-schema validation does
not answer whether a configuration satisfies organization-specific security
policy.

The custom Conftest policy produced six failures:

FAIL service-account key is prohibited
FAIL required governance labels are missing
FAIL uniform bucket-level access must be enabled
FAIL public access prevention must be enforced
FAIL region US-EAST1 is not approved
FAIL bucket IAM grants access to allUsers

7 tests · 1 passed · 6 failed

Checkov independently identified five unsafe conditions: missing public-access
prevention, versioning, access logging, uniform bucket-level access, and
protection against anonymous access.

Syntax validation asks “can this run?” Policy asks “are we willing to run it?”

These results came from containerized executions against committed fixtures.
They are not hand-written example output.

Remediating the Terraform

The corrected bucket configuration included the controls required by the
specification:

resource "google_storage_bucket" "customer_documents" {
  location = "us-central1"

  uniform_bucket_level_access = true
  public_access_prevention    = "enforced"

  versioning {
    enabled = true
  }

  logging {
    log_bucket = var.audit_log_bucket
  }

  labels = local.required_labels
}

The application service account receives only bucket-scoped
roles/storage.objectUser. The Terraform contains no service-account key
resource.

The first corrected Checkov execution still identified missing Cloud Storage
access logging. I added log delivery to a separately governed audit bucket and
reran the complete stack. This is an important benefit of layered checks: the
custom policy enforced the declared organization-specific contract while
Checkov supplied a broader known-misconfiguration check.

Governance changed both the Terraform and the authority model around it.

The corrected gate stack

The final results were:

Terraform validate    configuration valid
Checkov               6 passed · 0 failed
Conftest              7 passed · 0 failed
SicarioSpec           governance contract passed

The tools are complementary rather than interchangeable:

The demonstration used no GCP credentials and ran no terraform apply.
Passing automated gates made the change ready for human plan review. They did
not authorize a deployment.

Green gates establish readiness for review—not permission to deploy.

Contributing the bundle upstream

SicarioSpec is not only a preset collection. I built the distribution as a
versioned Spec Kit bundle containing the presets, an extension, governed
artifact templates, security and policy-as-code workflow starters, control
maps, and companion CLI verification. The goal is to make the integrated
governance system installable and repeatable rather than asking adopters to
assemble each component independently.

This is a personal community contribution developed during my weekend time. I
started it as part of a broader effort to improve my skills and become more
effective at producing useful outputs rapidly without sacrificing structured
governance. In my recent learning journey, I have also been using these ideas
to build and test workflows for malware analysis and reverse engineering.
Those use cases make evidence provenance, repeatability, and human authority
especially concrete.

The upstream status is specific:

• github/spec-kit#3161, the original bundle feature request, closed on July 21, 2026.
• github/spec-kit#3619 is the active SicarioSpec submission, opened through the official Bundle Submission form on July 21.
• At the latest check, #3619 was still open and carried only the enhancement label, not bundle-submission.
• The GitHub Actions workflow for community bundle validation had triggered multiple times, but its runs were skipped. The latest run checked was July 21 at 22:19 UTC.

This is not a case where there is no submission path. The bundle is submitted
and visible. The current gap is maintainer triage: applying the
bundle-submission label should put #3619 onto the validation and
catalog-assignment workflow. I have already posted a comment identifying the
missing label, so the remaining action is with the maintainers unless they ask
for changes.

A practical authority model for AI-assisted delivery

The resulting authority chain is:

AI or developer proposes
        ↓
non-AI tools validate
        ↓
humans approve material impact
        ↓
the cloud platform enforces deployed policy

Or, stated as an operating model:

Development owns the change. Security defines the guardrails. Code enforces
the minimum contract. Humans approve material risk.

This does not require every team to adopt every possible governance artifact.
A practical starting point is one repository and one meaningful feature:

1. Establish project principles before feature-level implementation.
2. Classify data and identify trust boundaries before selecting architecture.
3. Convert security requirements and abuse cases into tasks and negative tests.
4. Run governance verification before implementation and again before release.
5. Require structured, time-bound exceptions instead of silent bypasses.
6. Tune the baseline using findings from real features.

What deterministic verification does not prove

A passing sicario verify result does not prove that software is secure. It
does not grant compliance approval or certification. Templates do not replace
expert analysis, and an AI-generated threat model is not authoritative simply
because it is detailed.

“Deterministic” applies to the gate's verdict: non-AI code reads repository
artifacts and applies fixed rules. It does not make AI output deterministic or
automatically correct.

Human judgment remains necessary for architecture, legal applicability,
production readiness, security exceptions, and accepted risk.

What a deterministic gate can prove is narrower and useful: the declared
repository contract was evaluated consistently, required artifacts were
present, and known omissions could stop delivery instead of becoming forgotten
advice.

The larger point

AI has made producing code cheaper. It has not made explaining, governing, and
accepting the risk of that code cheaper.

If specifications become executable inputs to delivery, security and
governance should become first-class parts of those specifications. The goal is
not more paperwork. The goal is to make the secure path the normal path and
preserve evidence of the decisions that got us there.

Explore the projects:

• GitHub Spec Kit
• SicarioSpec

The real question is simple: why wouldn’t we make Spec-Driven Development with
SicarioSpec the standard for AI-assisted delivery?