AISDLC Insights

I06 · Evidence and control · 8 min read

Evidence before autonomy

Autonomy should expand only when the organization can prove what the system did, why it was allowed, how it was challenged, and how it can be stopped.

By AISDLC Editorial · Published 2026-08-08 · Reviewed 2026-08-09

Enterprises often discuss autonomy as a binary capability: either the agent acts independently or a human remains in the loop. Real operating models need a richer control surface. An agent may read broadly but write narrowly, propose a transaction but not commit it, execute within a limit, or continue only while runtime evidence remains inside an authorized operating envelope.

Evidence is the operating memory of accountability

A transcript can show what a model said. It cannot, by itself, establish which specification applied, what context was visible, which identity held authority, which tool effect occurred, which verifier challenged the result, who approved release, or what exact artifact ran. Evidence engineering connects these elements with stable identifiers and versioned records.

Software supply-chain provenance provides an important foundation: released artifacts should be attributable to the process that built them. Agentic systems require that chain to extend in both directions—back to intent, context, and delegated authority, and forward to deployment, runtime decisions, outcomes, incidents, recertification, and retirement.

The evidence spine

  1. Intent · Why the work exists Objective, owner, risk tier, constraints, acceptance criteria, and prohibited outcomes.
  2. Build · What produced the artifact Agent, model, harness, context, tools, environment, changes, tests, and provenance.
  3. Challenge · How the work was contested Verifier identities, methods, findings, disagreements, remediations, and residual risk.
  4. Authorize · Who accepted the decision Approval authority, policy result, conditions, scope, expiry, and exact artifact binding.
  5. Operate · What happened in reality Run traces, interventions, outcomes, drift, incidents, overrides, and lifecycle disposition.

Observability is necessary. It is not control.

Telemetry can reconstruct behavior and reveal anomalies. A control plane uses that evidence to decide what may happen next. It evaluates identity and policy, obtains approvals, constrains tool effects, holds uncertain actions, revokes authority, quarantines execution, and stops systems. A dashboard without enforcement can explain a harmful action beautifully while remaining unable to prevent the next one.

Autonomy must be promotable and reversible

Organizations frequently design a path to increase autonomy but no path to reduce it. That creates a one-way ratchet even when ownership changes, evidence quality falls, drift appears, or incident patterns emerge. The operating model should support promotion, hold, degradation, suspension, and retirement as normal states.

Static autonomy

  • Configured once at product launch
  • Human review added to every action or removed entirely
  • Success measured by completion rate
  • Telemetry retained for investigation

Evidence-adaptive autonomy

  • Operating envelope recalculated from tier, effect, and runtime state
  • Human attention reserved for consequential uncertainty
  • Success includes policy adherence, side effects, and outcomes
  • Evidence triggers allow, hold, constrain, revoke, and stop decisions

Promotion criteria

Repeated performance
Representative evaluations and production outcomes remain inside declared thresholds across time and conditions.
Independent assurance
Verifier coverage addresses the material risk hypotheses and unresolved disagreement is dispositioned.
Complete evidence
Runs are attributable to intent, identity, versions, tool effects, approvals, and outcomes.
Operational control
Hold, degrade, revoke, quarantine, rollback, and stop paths are tested and owned.

Control-plane acceptance questions

  • Which actions are observed versus actually intercepted?
  • Can the system deny or hold an action before the enterprise effect occurs?
  • Is approval bound to a specific action, artifact, purpose, and expiry?
  • Does every run preserve the identity and delegation chain?
  • What evidence automatically narrows the autonomy envelope?
  • When was revocation, quarantine, rollback, or stop last exercised?

Primary sources

  1. SLSA — SLSA provenance specification v1.2
  2. OpenAI — Building self-improving tax agents with Codex
  3. NIST CAISI — Challenges in monitoring deployed AI systems
  4. OpenTelemetry — GenAI observability
  5. OpenAI — How we monitor internal coding agents for misalignment

AISDLC Insights publishes source-informed editorial synthesis and implementation positions. It is reference material, not a standard, certification, legal opinion, or authorization to deploy an agent.