Keeping Humans in Control: ADLC Governance Model

One of the core principles of ADLC is that humans remain accountable. While agents can plan, code, test, and review, they cannot approve consequential changes or bypass policy. This article explores how the ADLC governance model achieves this balance.

The Problem We're Solving

Traditional agent-based workflows often suffer from two extremes:

• No guardrails: Agents autonomously make decisions, ship code, and manage infrastructure with minimal oversight, creating liability and risk.
• Excessive friction: Humans must manually approve every step, nullifying the efficiency gains of using agents in the first place.

ADLC splits the difference by defining approval gates where they matter most: at policy boundaries, not at every keystroke.

Policy-Aware Handoffs

Each stage of the ADLC lifecycle can declare intent and constraints upfront. For example:

• Planning stage: "This task must not modify authentication or billing logic. Flag for manual review if dependencies cross these boundaries."
• Implementation stage: "Do not add external network calls without documentation. Verify all new imports against the approved list."
• Verification stage: "All changes must maintain ≥80% test coverage in modified files. Failed tests block delivery."

The agent performs its work, and the system automatically escalates violations to human reviewers rather than silently passing or failing.

Approval Gates

ADLC defines three types of approval gates:

• Automatic gates: Verification rules that block or pass without human intervention (test coverage, lint checks, secret scanning).
• Policy gates: Human review required for specific change types (infrastructure, auth, critical paths) based on org policy.
• Intent gates: Human approval to proceed from planning to implementation, ensuring the plan aligns with the original request.

These gates are defined once at the organization level and apply to all agent work automatically. No per-task configuration needed.

Evidence-Driven Decisions

Every approval gate has supporting evidence attached:

• For plans: the research backing assumptions, viability checks, and acceptance criteria.
• For implementations: diffs, test results, lint output, security scans, and change traces.
• For reviews: comparison against the original intent, change impact analysis, and rollback plans.

Human approvers don't have to reverse-engineer what happened. They see the complete story in structured, reviewable form.

Bounded Agent Permissions

Agents cannot escalate their own permissions. They work within scoped access:

• Repository access is scoped to specific branches or files.
• Tracker access is limited to assigned tickets and approved projects.
• Credentials are proxied and injected only for approved destinations.
• Runtime limits (context, time, cost) prevent runaway execution.

If a task requires new permissions, the agent flags it and pauses. A human explicitly grants expanded access before the agent can proceed.

Learning and Accountability

All agent work is logged and auditable:

• Who initiated the work and when.
• What the agent planned and what assumptions it made.
• What code was written, tested, and reviewed.
• Who approved each stage and any conditions on approval.
• Cost, latency, and failure signals for future optimization.

This audit trail is not just compliance overhead—it's the foundation for learning. Future planning agents can search this history to understand what worked, what didn't, and why certain decisions were made.

Getting Started with Governance

If you're deploying ADLC in your organization:

1. Define your policy gates: what changes require human review in your domain?
2. Set automatic thresholds: coverage targets, lint rules, secret patterns.
3. Scope agent permissions: which repos, projects, and services can agents access?
4. Create approval chains: who reviews plans, implementations, and deliverables?
5. Document exceptions: when can the gates be overridden and who decides?

ADLC governance is most effective when it's explicit and organization-wide, not bespoke per-task or hidden in custom scripts.

Read the full brief: ADLC Brief
Back to blog: All posts