Skip to content

progressive-trust.md

Latest commit

 

History

History
324 lines (243 loc) · 11.8 KB

progressive-trust.md

File metadata and controls

324 lines (243 loc) · 11.8 KB
Raw

Progressive Trust Model for AI Agent Operations

Overview

The Progressive Trust Model is a phased approach to deploying AI agents in Kubernetes environments. It addresses the single most common failure pattern observed across 50,000+ engineers: 68% over-automate on day one, granting AI agents full cluster access and destroying test environments within hours.

This model enforces a structured escalation path where each phase must pass measurable gates before advancing.

Design Principles

  1. Start read-only. No agent should have write permissions on deployment day.
  2. Earn trust through evidence. Promotion requires quantifiable accuracy and stability data.
  3. Fail closed. If a gate check fails, the agent stays at its current phase. No exceptions.
  4. Rollback is always available. Every phase transition is reversible within minutes.
  5. Human approval is mandatory for destructive operations. Even in Phase 4.

Phase 1: Read-Only Observability (Weeks 1-2)

Objective

Deploy observability agents that can query metrics, traces, and logs but cannot modify any cluster state.

Permissions

Resource Verbs Allowed Verbs Denied
Pods, Deployments, Services get, list, watch create, update, delete, patch
Prometheus metrics query, query_range N/A
OpenTelemetry traces read write
Jaeger spans read write
Fluentd logs read write

Agents Deployed

  • Observability Agent: Correlates Prometheus metrics with OpenTelemetry distributed traces. Generates natural language root cause hypotheses with evidence chains.

RBAC Configuration

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: agent-phase1-readonly
rules:
  - apiGroups: [""]
    resources: ["pods", "services", "endpoints", "nodes"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["apps"]
    resources: ["deployments", "replicasets", "statefulsets"]
    verbs: ["get", "list", "watch"]
  - apiGroups: ["metrics.k8s.io"]
    resources: ["pods", "nodes"]
    verbs: ["get", "list"]

Success Criteria (Gate to Phase 2)

Metric Threshold Measurement Method
Diagnostic accuracy >= 80% correct root cause identification Manual review of 20+ incidents
False positive rate < 20% Count of alerts that required no action
Agent uptime >= 99% over 14 days Prometheus up metric
Zero write attempts 0 denied write API calls Kubernetes audit log review
Team confidence score >= 7/10 average Survey of on-call engineers

Phase 2: Constrained Write with Cost Limits (Weeks 3-4)

Objective

Introduce cost optimization agents with tightly bounded write permissions. OpenCost provides real-time cost visibility and OPA enforces hard spending limits.

Permissions

All Phase 1 permissions plus:

Resource Verbs Allowed Constraints
HPA (HorizontalPodAutoscaler) update, patch Replicas between 1 and configured max
Pod resource requests/limits patch Cannot exceed namespace ResourceQuota
Node labels patch Scheduling labels only
OpenCost queries read Full cost attribution data

Cost Guardrails (OpenCost + OPA)

# OPA policy: enforce budget ceiling per namespace
package cost.enforcement

default allow = false

allow {
    input.projected_daily_cost <= data.budget_limits[input.namespace].daily_max
}

deny[msg] {
    input.projected_daily_cost > data.budget_limits[input.namespace].daily_max
    msg := sprintf(
        "Projected daily cost $%.2f exceeds budget $%.2f for namespace %s",
        [input.projected_daily_cost, data.budget_limits[input.namespace].daily_max, input.namespace]
    )
}

Rollback Triggers

The system automatically reverts to Phase 1 (read-only) if any of these conditions occur:

  • Cost spike: Hourly spend exceeds 2x the 7-day rolling average
  • Resource explosion: Any single scaling action increases resource count by more than 50%
  • OPA policy violations: More than 3 denied actions in a 1-hour window
  • Agent error rate: More than 5% of actions result in Kubernetes API errors

Success Criteria (Gate to Phase 3)

Metric Threshold Measurement Method
Cost savings documented >= $500/month verified OpenCost before/after comparison
Zero budget overruns 0 OPA budget violations that reached the cluster OPA decision logs
Scaling accuracy >= 90% of scaling decisions validated as correct Weekly review of HPA changes
Rollback count <= 2 automated rollbacks in 14 days Rollback event counter
No production impact 0 user-facing incidents caused by agent actions Incident correlation review

Phase 3: Gated Remediation with Approval Workflows (Weeks 5-6)

Objective

Enable remediation agents that can take corrective action on known failure patterns, gated by policy enforcement (Kyverno), cryptographic identity (SPIFFE/SPIRE), and supply chain attestation (in-toto).

Permissions

All Phase 2 permissions plus:

Resource Verbs Allowed Gate Requirements
Pod restarts delete (for restart) Kyverno rate limit: max 3/hour per workload
Deployment rollback update Slack approval from on-call engineer
ConfigMap updates patch in-toto attestation signed by agent SPIFFE identity
Certificate rotation create, delete Automated, logged, rate-limited

Policy Stack

Kyverno enforces Kubernetes-native constraints:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: agent-remediation-limits
spec:
  validationFailureAction: Enforce
  rules:
    - name: limit-restart-rate
      match:
        any:
          - resources:
              kinds: ["Pod"]
              operations: ["DELETE"]
              selector:
                matchLabels:
                  app.kubernetes.io/managed-by: kagent
      validate:
        message: "Remediation rate limit exceeded. Max 3 restarts per workload per hour."
        deny:
          conditions:
            any:
              - key: "{{request.object.metadata.annotations.\"agent.restart.count\" || '0'}}"
                operator: GreaterThan
                value: "3"

SPIFFE/SPIRE provides cryptographic agent identity:

# Agent workload identity
spiffeID: spiffe://cluster.local/ns/kagent-system/sa/remediation-agent
# All remediation actions are authenticated via this identity
# Audit logs bind actions to this specific agent instance

in-toto creates an attestation chain for every remediation action:

{
  "_type": "https://in-toto.io/Statement/v1",
  "subject": [
    {
      "name": "remediation-action",
      "digest": {"sha256": "abc123..."}
    }
  ],
  "predicateType": "https://kagent.dev/attestation/remediation/v1",
  "predicate": {
    "agent": "spiffe://cluster.local/ns/kagent-system/sa/remediation-agent",
    "action": "pod-restart",
    "target": "payment-service-7d4f8b6c9-x2k4m",
    "reason": "OOMKilled detected, memory leak pattern matched",
    "approval": "slack://approval/2026-03-15T10:30:00Z/oncall-jane",
    "timestamp": "2026-03-15T10:30:45Z"
  }
}

Approval Workflow

  1. Agent detects anomaly and formulates remediation plan
  2. Plan is posted to Slack with full context (what, why, impact, rollback plan)
  3. On-call engineer approves or rejects within configurable timeout (default: 15 minutes)
  4. If approved: agent executes action, creates in-toto attestation, logs to audit trail
  5. If rejected or timed out: agent logs the event and takes no action
  6. Post-action: agent monitors for 10 minutes and auto-rollbacks if health checks degrade

Rollback Triggers

Automatic demotion to Phase 2 if:

  • Failed remediation: More than 2 remediation actions that worsened the situation in 7 days
  • Approval timeout rate: More than 50% of actions time out (indicates team distrust)
  • Attestation failure: Any action executed without valid in-toto attestation
  • Identity compromise: SPIFFE identity validation failure

Success Criteria (Gate to Phase 4)

Metric Threshold Measurement Method
Remediation success rate >= 85% of actions resolve the issue Post-action health check validation
MTTR improvement >= 30% reduction Compare pre-agent vs post-agent incident timelines
Approval turnaround < 5 minutes median Slack workflow timestamp analysis
Zero unapproved actions 0 actions without valid approval chain in-toto attestation audit
Team trust score >= 8/10 average Survey of on-call engineers

Phase 4: Knowledge Base and Expanded Automation (Weeks 7-8+)

Objective

Deploy knowledge agents that index infrastructure documentation, runbooks, and historical incident data. Expand automation scope based on accumulated trust evidence.

Capabilities

  • Runbook-assisted troubleshooting: Agent retrieves relevant runbook steps during incidents
  • Historical pattern matching: Correlate current symptoms with past incidents
  • Documentation generation: Auto-generate post-incident reviews with evidence chains
  • Expanded remediation playbooks: New remediation patterns added through GitOps (ArgoCD)

Permission Expansion Process

New permissions in Phase 4 follow a mini-trust cycle:

  1. Propose new capability via pull request to policy repository
  2. Kyverno dry-run validation for 48 hours
  3. Security review of OPA policy changes
  4. Limited rollout to non-production namespace for 7 days
  5. Promotion to production with full gate checks

Long-Term Governance

# Quarterly trust review checklist
review:
  frequency: quarterly
  participants:
    - platform engineering lead
    - security team representative
    - on-call rotation lead
  checklist:
    - review_all_agent_permissions: true
    - audit_attestation_chain: true
    - validate_cost_trends: true
    - reassess_phase_placement: true
    - update_rollback_procedures: true

Rollback Procedures

Phase Demotion

Any phase can be demoted to the previous phase within minutes:

# Emergency demotion to Phase 1 (read-only)
kubectl apply -f policies/emergency-readonly.yaml
# This replaces all agent ClusterRoleBindings with Phase 1 read-only roles

# Targeted demotion of a single agent
kubectl label agent/<agent-name> trust-phase=1 --overwrite
# Kyverno policies automatically restrict permissions based on this label

Full Agent Shutdown

# Disable all agent write operations cluster-wide
kubectl annotate namespace kagent-system agent.policy/mode=disabled --overwrite
# Agents continue running but all write API calls are denied by OPA

Summary

Phase Duration Risk Level Key Controls Gate Metric
Phase 1 Weeks 1-2 Minimal Read-only RBAC 80% diagnostic accuracy
Phase 2 Weeks 3-4 Low OpenCost limits, OPA budgets $500/month savings verified
Phase 3 Weeks 5-6 Medium Kyverno, SPIFFE, in-toto, Slack approval 85% remediation success
Phase 4 Weeks 7-8+ Medium GitOps policy management, quarterly review Continuous improvement

Total time to full production deployment: 3-6 months. This is not instant magic. The 68% of teams that skip this progression and grant full access on day one consistently destroy environments and lose organizational trust in AI operations.

The progressive model protects both the infrastructure and the organizational appetite for AI-assisted operations.