Provable Recourse and Human Override in Autonomous Delivery

Provable Recourse and Human Override in Autonomous Delivery

Voruganti Kiran Kumar
Senior DevOps Engineer

Abstract— Autonomy must provide recourse: clear, actionable steps to overturn a denial. We formalize recourse for release decisions as the search for minimal edits to evidence and configuration (e.g., attach an SBOM, raise SLSA level, add a NetworkPolicy, rotate to approved ciphers) that flip the decision while respecting safety constraints. The system produces contrastive explanations that identify binding constraints, synthesizes one-click remediation pull requests, and supports governed human override (“break-glass”) with expiring tokens and mandatory post-mortems. We specify the recourse problem, propose algorithms grounded in counterfactual and minimal-change reasoning, describe a Kubernetes-native implementation, and outline an evaluation protocol focused on time-to-compliance, override misuse rates, and auditor satisfaction.

Index Terms— explainability, recourse, counterfactuals, overrides, governance, safety, DevSecOps, CI/CD, admission control.

I. Introduction

Autonomous delivery systems increasingly gate promotions using policy-as-code, provenance checks, and progressive rollout analysis. When a gate denies promotion, developers need recourse—a principled method to understand why and to determine the smallest change that would make the release admissible without diluting safety. Equally important, production operations require a governed override path for emergencies, with guardrails and accountability.

This paper advances autonomy from “deny with a message” to deny with a proof and a fix. We (i) formalize release-recourse as a minimal-change decision problem, (ii) compute contrastive explanations that isolate binding constraints, (iii) synthesize remediation artifacts (patches, policy edits, attestations) and one-click PRs, and (iv) provide a human override protocol that is tightly scoped, time-limited, and auditable.

II. Background

Contrastive explanations. Local surrogate and attribution methods (e.g., LIME, SHAP) help identify features driving a model decision and can be adapted to policy engines that evaluate structured manifests and evidence. Counterfactual work in the ML literature formalizes actionable change sets that flip outcomes subject to feasibility and cost.

DevSecOps and supply chain. DevSecOps guidance for CI/CD emphasizes verifiable evidence (SBOMs, signatures, provenance) and policy enforcement. SRE practice recommends rapid rollback, error-budget discipline, and clear operational runbooks when automation blocks or reverts.

III. Problem Formulation

Let a release request include concrete artifacts xxx (manifests, images) and evidence eee (SBOM, signatures, attestations). A policy engine f(x,e)∈{allow,deny}f(x,e)\in\{\text{allow},\text{deny}\}f(x,e)∈{allow,deny} returns a decision along with justifications JJJ. Define:

• Feasible edits A\mathcal{A}A: atomic changes allowed by governance (e.g., add SBOM, upgrade dependency, attach provenance, add NetworkPolicy, change cipher suite).

• Cost model c:A→R≥0c:\mathcal{A}\rightarrow \mathbb{R}_{\ge 0}c:A→R≥0​: operational cost (effort, risk, lead-time impact).

• Safety constraints Φ\PhiΦ: invariants that edits must preserve (e.g., no reduction of crypto strength, no widening of network exposure, no disabling of mandatory checks).

Recourse objective. Find a set of edits S⊆AS\subseteq \mathcal{A}S⊆A of minimal cost such that f(x⊕S,e⊕S)=allowf(x\oplus S,e\oplus S)=\text{allow}f(x⊕S,e⊕S)=allow and S⊨ΦS\models \PhiS⊨Φ.

This is a constrained minimal-change problem, often reducible to hitting-set or MaxSAT: a deny decision yields a set of violated clauses {C1,…,Ck}\{C_1,\dots,C_k\}{C1​,…,Ck​}; each edit covers zero or more clauses; choose the least-cost set covering all violated clauses.

IV. Methods

A. Contrastive Reasoning

We compute a contrast set B⊆JB\subseteq JB⊆J of binding constraints—those whose satisfaction is necessary to flip the outcome. For policy engines, bindings are structural (e.g., “privileged pod in namespace tier=pci”); for model-based gates (e.g., anomaly-based risk), we use local attributions to surface the top contributing features and map them to actionable edits (e.g., revert a high-risk dependency).

B. Minimal-Change Search

1. Clause extraction. Normalize deny justifications into a set of violated predicates (e.g., has_sbom(image)=false, is_signed(image)=false, privileged_pod(ns=pci)=true).

2. Edit catalog. Maintain a catalog mapping edits to clauses they resolve (e.g., generate_sbom(image) resolves has_sbom=false).

3. Optimization. Solve a weighted set cover or MaxSAT instance to find minimal cost SSS. If multiple solutions tie, pick the one with least operational blast radius (e.g., edit a single manifest vs. touching a shared policy).

4. Validation. Dry-run the edited state through the policy engine and spec checks; reject proposals that violate Φ\PhiΦ.

C. Remediation Synthesis

For each selected edit, emit a remediation patch:

• Evidence fixes: SBOM generation step, signature commands, provenance attestation job, wiring of artifact digests to manifests.

• Policy fixes: addition of required labels/annotations, NetworkPolicy manifests, PodSecurityContext adjustments.

• Dependency upgrades: minimal version bumps to fixed releases.

Patches are bundled into a one-click PR with a decision trace referencing original violations, the chosen SSS, and the expected decision after merge.

D. Governed Override (“Break-Glass”)

When recourse is infeasible within time bounds (e.g., urgent security fix), an override route allows admission under strict guardrails:

• TTL tokens with short expiry, scoped to specific resources and environments.

• Two-person rule and justification fields.

• Automatic rollback window unless explicitly extended.

• Mandatory post-mortem that evaluates why standard recourse was insufficient and whether to adjust policies or playbooks.

All overrides are recorded as attestations and are subject to periodic review.

V. Implementation

Admission surfaces. Low-latency constraints run via Kubernetes ValidatingAdmissionPolicy (CEL); richer checks use OPA/Gatekeeper. Deny reasons include machine-readable rule IDs and predicate details to feed clause extraction.

Evidence stack. CI produces SBOMs (SPDX or CycloneDX), signatures and attestations (e.g., Sigstore-style flows), and provenance claims (SLSA). Missing evidence defaults to fail-closed with recourse suggestions.

Planner hooks. If a denial repeats, create work items to “raise the floor” (e.g., add SBOM generation to the standard pipeline) to reduce future friction.

Auditability. Decision traces, patches, and approvals are signed and retained. Auditors can replay the deny→recourse→allow path deterministically.

VI. Evaluation

Scenarios.

1. Missing evidence: SBOM absent for a production image.

2. Policy violation: privileged pod in a protected namespace.

3. Provenance gap: insufficient SLSA level for target environment.

4. Time-critical override: emergency patch under lockstep governance.

Metrics.

• Time-to-compliance: median from deny to allow via recourse.

• Override misuse rate: overrides not meeting emergency criteria, and repeat occurrences.

• Change-failure rate: before/after recourse introduction.

• Audit satisfaction: reviewer ratings of clarity and sufficiency of decision traces.

• Friction: added CI time and developer effort for top-quartile recourse cases.

Baselines. Deny-only messages; manual runbooks without automated patch synthesis.

Threats. Incomplete clause extraction can propose ineffective edits; mitigate with policy unit tests and “what-if” dry runs. Poor cost models can over-optimize for speed at reliability’s expense; calibrate with incident data and SRE input.

VII. Discussion

Recourse operationalizes explainability: decisions are not just understood but fixable under constraints. Human override remains essential but must be tightly governed; the system’s default posture is “no evidence, no exposure,” with safe, minimal paths to compliance. Over time, high-frequency recourse suggestions point to structural improvements (e.g., make SBOM generation mandatory), shrinking the need for human intervention.

VIII. Conclusion

Provable recourse and governed override transform autonomous delivery from a black-box gate into a collaborative control loop. By formalizing minimal-change edits under safety constraints, synthesizing remediation, and constraining overrides with expiring tokens and post-mortems, organizations can ship quickly without compromising assurance.

References

[1] M. T. Ribeiro, S. Singh, and C. Guestrin, “Why Should I Trust You?: Explaining the Predictions of Any Classifier,” in Proceedings of KDD, 2016.
[2] S. Lundberg and S.-I. Lee, “A Unified Approach to Interpreting Model Predictions,” in Proceedings of NeurIPS, 2017.
[3] S. Wachter, B. Mittelstadt, and C. Russell, “Counterfactual Explanations Without Opening the Black Box,” Harvard Journal of Law & Technology, vol. 31, no. 2, 2018.
[4] B. Ustun, A. Spangher, and Y. Liu, “Actionable Recourse in Linear Classification,” in Proceedings of FAT*, 2019.
[5] R. Chandramouli, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines, NIST SP 800-204D, 2024.
[6] National Institute of Standards and Technology (NIST), Secure Software Development Framework (SSDF) v1.1, SP 800-218, 2022.
[7] B. Beyer, C. Jones, J. Petoff, and N. R. Murphy (eds.), Site Reliability Engineering: How Google Runs Production Systems. O’Reilly, 2016.
[8] S. Torres-Arias, H. Wu, I. Loh, R. Curtmola, and J. Cappos, “in-toto: Providing Farm-to-Table Guarantees for Every Bit,” in Proceedings of USENIX Security, 2019.
[9] OpenSSF, Supply-chain Levels for Software Artifacts (SLSA) — Specification v1.0, 2023.
[10] Open Policy Agent Project, “Open Policy Agent (OPA) and the Rego Policy Language,” CNCF documentation/white paper, 2021–2025.
[11] The Kubernetes Authors, “Pod Security Admission,” documentation and release notes, 2022–2024.