Skip to content

Bugz · Platform

The control plane that governs what agents may execute.

How it works

From intent to applied change, with a gate at every step

  1. 1

    Understand

  2. 2

    Ground

  3. 3

    Generate

  4. 4

    Verify

    Policy checks and the Checkov + Trivy scanner cascade run on every proposed change.

  5. 5

    Govern

  6. 6

    Apply & prove

Six pillars

Every page below shows a real artefact, not a diagram

Pillar 01

SOP engine

Every change runs a versioned YAML procedure with typed steps — intent, checks, approval and apply are steps in a definition, not free-form tool calls.

11 procedures · 9 step types

  • No change runs outside a procedure.
  • Every step is recorded in order.
  • Procedures are versioned and reviewable.
provision_vm.yaml
sop:
  id: provision_vm
  name: "Provision Virtual Machine"
  version: "1.0"
  description: "Standard procedure for provisioning Azure VMs with security and cost controls"
  trigger: "user requests VM creation"
  min_role: developer
  approval_required: true

  context_required:
    - resource_count_by_type
    - budget_remaining
    - active_alerts

  steps:
    - id: gather_intent
      type: ask_user
      prompt: |
        What is the purpose of this VM?
        Which environment (dev/staging/prod)?
        What workload type?
      mcq:
        questions:
          - id: purpose
            question: "What will this VM be used for?"
            options:
              - label: "Compute"
                value: "compute"
                description: "CPU-intensive workloads"
              - label: "Storage"
                value: "storage"
                description: "File storage services"
              - label: "Web Server"
                value: "web"
                description: "HTTP/HTTPS serving"
              - label: "Database"
                value: "database"
                description: "Database engine hosting"
          - id: environment
            question: "Which environment?"
            options:
              - label: "Development"
                value: "dev"
                description: "Development environment"
              - label: "Staging"
                value: "staging"
                description: "Pre-production testing"
              - label: "Production"
                value: "prod"
                description: "Live production"
      validation:
        required_fields: [purpose, environment]

    - id: check_existing
      type: query_world_model
      auto_execute: true
      query: "VMs in {environment} with similar purpose"
      gate:
        warn_if: "similar_resources_found"
        message: "A VM with similar purpose already exists: {match_name}. Proceed or reuse?"

    - id: select_sizing
      type: recommend
      source: knowledge_base
      query: "optimal Azure VM size for {purpose} workload"
      constraints:
        - type: cost_policy
          rule: "max_monthly_cost"
          values:
            dev: 150
            staging: 300
            prod: 600
        - type: security
          rule: "no_public_ip_unless_justified"
      present_options: true

    - id: generate_hcl
      type: generate_code
      generator: claude
      context_from_steps: [gather_intent, select_sizing]
      enforce:
        - encryption_at_rest: true
        - nsg_default_deny: true
        - managed_identity: true
        - diagnostics_enabled: true
        - required_tags: [owner, cost_center, environment, sop_id]
      validation:
        terraform_validate: must_pass
        checkov_scan: must_pass_critical
        cost_estimate: must_be_within_policy

    - id: cost_review
      type: present
      auto_execute: true
      show:
        - estimated_monthly_cost
        - budget_remaining_after
        - cost_vs_alternatives
        - security_scan_summary
      gate: user_acknowledges

    - id: plan_review
      type: run_tool
      auto_execute:
        condition: blast_radius_below
        threshold: 25.0
      tool: run_tofu_plan
      present: diff_output
      gate: user_approves_plan

    - id: approval
      type: request_approval
      required_role: approver
      present_to_approver:
        - sop_execution_summary
        - cost_estimate
        - security_scan_results
        - plan_diff
        - blast_radius
      gate: approver_approves

    - id: apply
      type: run_tool
      tool: run_tofu_apply
      post_validate:
        - verify_resource_in_azure
        - verify_tags_applied
        - verify_nsg_active
        - log_to_audit

    - id: record
      type: post_validate
      auto_execute: true
      actions:
        - log_sop_completion
        - update_world_model
        - record_cost_baseline

Pillar 02

Approvals & audit

Four roles — viewer, developer, approver, admin. The requester is never the approver, and every decision lands in the audit trail.

  • The requester is never the approver.
  • Approving a change is never automated.
  • No step goes unrecorded.
Role ladder
class UserRole(str, Enum):
    """User roles for RBAC."""
    VIEWER = "viewer"
    DEVELOPER = "developer"
    APPROVER = "approver"
    ADMIN = "admin"

Pillar 03

Compliance

Framework controls run against every proposed change before it can move forward — the live control set is synced from the product repo.

65 controls · 6 frameworks

  • Controls run on every change, not on a schedule.
  • Failed critical checks block the change.
  • The control set is versioned with the product.
Compliance control set
CERT-In v2022 — 10 controls
CIS Azure Benchmark v2.0 — 10 controls
NIST 800-53 v5.0 — 15 controls
PCI DSS v4.0 — 10 controls
RBI IT Framework v2016 — 10 controls
SOC 2 Trust Services Criteria v2017 — 10 controls
— 65 controls · 6 frameworks

Pillar 04

Cloud security

Secure defaults are enforced on generated changes — encryption at rest, default-deny network rules, managed identity and required tags — with secret scrubbing on inputs.

Guarantees

  • Default-deny network rules on new resources.
  • Secrets are scrubbed before code leaves the boundary.
  • Post-apply validation confirms what actually shipped.

Pillar 05

Agent gateway · MCP

Agents connect through an MCP server; its tools and resources are the only surface an agent can touch — the live tool list is synced from the product repo.

18 tools · 4 resources

  • An agent never calls your cloud directly.
  • Every tool call is scoped by role.
  • Any MCP-speaking agent gets the same rules.
MCP gateway tools
tools (18):
  list_sops
  start_sop
  advance_sop
  approve_sop_step
  cancel_sop
  get_sop_status
  scrub_hcl
  scrub_text
  calculate_blast_radius_from_plan
  calculate_blast_radius_from_resources
  get_dependency_graph
  estimate_resource_cost
  estimate_hcl_cost
  compare_sku_alternatives
  validate_security_compliance
  validate_naming
  validate_tags
  validate_cost_policy
resources (4):
  sop://runs/active
  sop://runs/{run_id}
  sop://catalog
  audit://recent

Pillar 06

IaC pipeline

OpenTofu plan and apply run as governed procedure steps — plan diff review, blast-radius gating and post-apply validation included.

Guarantees

  • Plans are reviewed before apply.
  • Blast radius gates auto-execution.
  • Applies are verified after they run.

Compliance packs

Checks run on every proposed change against CIS Azure Benchmark, NIST 800-53, PCI DSS, SOC 2 Trust Services Criteria, the RBI IT Framework and CERT-In guidelines. The live framework list and control counts on this site are synced from the product repository.

Deployment

Self-hosted, managed or sovereign. Same governance everywhere.

Self-hosted

Runs in your environment — your cloud credentials never leave it.

Managed

A hosted control plane, operated by Bugz.

Sovereign

Air-gapped and government profiles for regulated estates.

We use one analytics cookie to understand traffic. Nothing loads until you accept.