A framework specifying a risk-tiered lifecycle and the control-plane services required to implement it.
Enterprises are not stuck because the models are not good enough. They are stuck because nobody will sign for an agent they cannot bound, supervise, or account for afterwards. This specification defines the lifecycle and controls an implementation needs before a CISO can authorize autonomy inside a boundary.
Published specification · not a deployed control plane · Crosswalk reviewed 2026-07
Agents build. Verifiers challenge. Humans authorize. A conforming control plane enforces.
Agents build.
Humans and coding agents work inside approved repositories, models, and pipelines.
Verifiers challenge.
The specification requires independent services to test the software, the model, the trajectory, and the outcome.
Humans authorize.
A named person accepts the risk and releases the work. Never the builder.
The control plane must enforce.
The specification requires every model call, tool call, and credential to pass through it, with no alternate route into enterprise systems.
The specification requires every phase, every release, and every running agent to have a named person who answers for it.
A conforming implementation produces evidence through services outside the build team. No builder approves its own work.
A conforming implementation executes policy at the gateway instead of documenting it in a wiki and hoping for compliance.
Code, services, interfaces, infrastructure
Continuous — many changes a day
Owned by Engineering
A change is a diff you can read, test, and revert.
An agent's behaviour changes when a model, a prompt, a tool, or a retrieved document changes. None of that appears in the diff.
Training data, retrieval corpora, model versions, prompts, embeddings
Vendor-driven — the model can move underneath you
Owned by Data and AI platform
Dependencies are versioned artifacts you choose when to upgrade.
A hosted model can be updated without your release. Behaviour drifts with no commit, no ticket, and no deployment.
Non-human identities, credentials, tool permissions, memory, autonomy
Per session — permissions acquired and used in seconds
Owned by Security and identity
Identities belong to people and change at the speed of HR.
Agents outnumber people, act at machine speed, and routinely outlive the person who created them.
Risk classification, approvals, controls, attestations, audit records
Regulatory — quarterly, annual, and on demand years later
Owned by Risk, compliance, privacy, legal
Evidence can be assembled from the lifecycle after the fact.
Nothing an agent did is reconstructable later unless the lifecycle recorded it at the time it happened.
Select a phase to read its activities, evidence, verifiers, and the gate that stands between it and the next.
Establish what the system is for, who answers for it, whom it affects, what data it touches, and how much autonomy it may ever hold.
Assign the risk tier, or refuse the use case.
Split the outcome into bounded agent tasks, deterministic services, human decisions, and escalation points — before anyone builds.
Confirm the decomposition and the decision rights.
Design the models, data flows, tools, identities, tenant boundaries, integrations, and the controls that hold them — and then attack the design on paper.
Approve the architecture and the threat model.
Humans and coding agents build through approved repositories, approved models, and approved pipelines — so the record of how it was made is a by-product of making it.
Accept the build into verification.
Independently challenge the software, the model, the agent's trajectory, its data access, and the business outcome. Not a review of intent — a test of behaviour.
Pass or fail against the tier's evidence policy.
Supervise runtime behaviour, policy compliance, quality, spend, drift, and incidents — with the authority to stop the system, not just observe it.
Continue, restrict, quarantine, or kill.
Confirm the agent is still needed, still owned, still compliant, and still authorized — or take it out of service and keep the record.
Recertify, transfer, restrict, or retire.
In most organisations the agent keeps running, with credentials nobody reviews, against systems nobody re-authorised. Under this specification, a conforming implementation treats the absence of an owner as a control signal.
Active named owner · valid authorization · recertification current
Full authorized permission set inside the deployment boundary.
Owner departed · authorization expired · recertification overdue
Transactional and write permissions revoked automatically. Read-only, no new sessions, sponsor and control owner notified.
No remediation inside the grace window
Credentials revoked, identity retired, integrations closed. Evidence retained to the regulatory schedule.
An agent without an active owner, a valid authorization, or a completed recertification does not keep running on momentum. It restricts itself.
Acts before generation
“The agent cannot.”
Blocks — makes the action impossible
Policy-as-code, tool and dependency allowlists, scoped credentials, protected paths, data-boundary and PII rules, approved context packaging.
There is nothing to remediate. The action was never available.
Acts during generation
“Checked while working, not after.”
Blocks — and returns a correction signal
Contract and schema conformance, deterministic tests, secret scanning, data-flow and control-flow checks, diff-scope limits, unauthorized action attempts.
The loop halts and the agent is handed the failure to fix. Work does not advance.
Acts before release
“Nothing ships unverified.”
Blocks — withholds the release
Multi-layer verification, evaluation suites, red-team results, evidence-completeness checks, and a named human release authority.
Release is withheld. A failed gate creates remediation work; it never moves accountability onto an agent.
Acts after release
“The last line, not the control.”
Detects only — it cannot stop what already happened
Runtime monitoring, drift and regression detection, anomaly detection, incident feedback into the maintenance loop.
It reports. This is the observability layer: necessary, and last.
Most enterprises have the first class and the last. They have had allowlists and identity for years, and they have bought dashboards. The gap is almost always the second — nothing acts while the agent is working. That is the difference between an unsupervised generator and a supervised one.
A verifier is a named, independently-owned check with a defined trigger, a defined scope, the authority to block, and a recorded disposition.
No builder — human or agent — approves its own work.
This is not a new control. It is segregation of duties, applied to a new kind of actor — and it is the reason a single model reviewing its own output is not verification. Every model carries its own failure modes; asking one to grade its own homework reproduces them in the verdict.
Static and dynamic analysis, dependency policy, secrets, data flow, control flow, tests, coverage, schema conformance.
It cannot tell you whether the code does the right thing.
Intent, business-logic correctness, requirement conformance, and the unknown-unknowns no rule was written for.
On its own it is not repeatable, and it must never review its own lineage's work.
Algorithmic and agentic verification are complementary, never either/or.
Six subject classes, laid across the eight phases. Control timing says when a check acts; this says what it looks at. A verifier is one of each.
| Verifier class | Design | Build | Release | Runtime | ||||
|---|---|---|---|---|---|---|---|---|
| Verifier class | 01Intake | 02Define | 03Architect | 04Build | 05Verify | 06Authorize | 07Operate | 08Recertify |
| V1Code and supply chain | Does not operate | Does not operate | Operates | Operates | Operates | Operates | Does not operate | Operates |
| V2Data and privacy | Operates | Does not operate | Operates | Operates | Operates | Does not operate | Does not operate | Operates |
| V3Model | Does not operate | Does not operate | Does not operate | Does not operate | Operates | Does not operate | Operates | Operates |
| V4Agent behaviour | Does not operate | Does not operate | Operates | Does not operate | Operates | Does not operate | Operates | Operates |
| V5Business process | Does not operate | Operates | Does not operate | Does not operate | Operates | Operates | Operates | Does not operate |
| V6Runtime | Does not operate | Does not operate | Does not operate | Does not operate | Does not operate | Does not operate | Operates | Operates |
Scroll the matrix sideways →
Establish that the artifact is what it claims to be and carries no known defect.
Acts as Preventive · Inline · Gate
Establish that the system touches only the data it is authorized to touch, and leaks none of it.
Acts as Preventive · Inline · Gate · Continuous
Establish that the model performs as claimed, for everyone it affects, and still does after it moves.
Acts as Gate · Continuous
Establish what the agent does when the world is hostile, ambiguous, or simply long.
Acts as Preventive · Inline · Gate · Continuous
Establish that the business outcome is correct — not merely that the model sounded right.
Acts as Inline · Gate · Continuous
Establish, continuously, that the system in production is still the system that was authorized.
Acts as Continuous
Risk appetite, policy, standards, approval authority, audit obligations.
Required functions: registry, identity, policy-as-code, gateway, authorization, evidence, economics, and response.
Where humans and agents do the work in a conforming implementation — under the plane, never beside it.
Challenge the work and return evidence the policy engine can evaluate.
Sandboxed execution with scoped credentials and enforced egress.
Systems of record. A conforming implementation makes them reachable only through the route above.
A conforming implementation routes every model call and tool call through a governed gateway and provides no direct agent-to-enterprise-system path.
The system helps a person think or write. It takes no action and touches nothing sensitive.
Internal assistants working over restricted material. The system reads what matters and still writes nothing.
The system acts: it creates tickets, updates records, sends communications, and invokes workflows.
Decisions that materially affect a person: claims, payment, enrollment, benefits, clinical, eligibility.
Tiers are cumulative. T1 carries every control below it — eight phases across the bottom, one new control per phase at each tier.
Fully autonomous adverse decisions affecting a person are not permitted without a separately defined high-consequence governance process.
This page is the framework standard, not an inventory of a deployed system. Every control listed is what the lifecycle requires at that tier. Any specific deployment carries its own register, which separates what is implemented today from what is documented standard.
Acceptance criterion with an id
Versioned record · Phase 02
Architecture and threat-model entry
Versioned record · Phase 03
Commit or prompt revision
Signed commit · Phase 04
Test run against the versioned set
Content hash · Phase 04
Pass or fail with findings
Signed attestation · Phase 05
Authorization decision and authorizer
Signed decision · Phase 06
Released artifact, model and prompt version
Artifact signature · Phase 06
Prompt, tool calls, outputs, policy decisions
Append-only record · Phase 07
Confirmation, transfer, or retirement
Signed decision · Phase 08
Each link is signed or versioned, and each points at the one before it. This is the chain an auditor follows — from a runtime decision back to the requirement that authorized it, or forward from a requirement to every decision it produced.
Govern, Map, Measure, Manage — with governance infused across the lifecycle rather than bolted on at the end, and TEVV run as an operational discipline.
Govern lives in the control plane and the tier policy. Map is phases 01–03. Measure is the verifier layer. Manage is phases 06–08. TEVV runs continuously, not once.
Prepare the organization, protect the software, produce well-secured software, respond to vulnerabilities — designed to integrate into an existing lifecycle rather than replace it.
Phase 04 emits provenance, SBOM and AI-BOM by pipeline. Phase 05 runs the code and supply-chain verifier class. Phase 07 carries the response practices into runtime.
Control families for access control, audit and accountability, configuration management, identification and authentication, risk assessment, system and services acquisition, and program management.
The specified control-plane functions map to families directly: identity and delegated authorization to AC and IA, the evidence store to AU, the registries to CM, tiering to RA, and the vendor catalog to SA.
Administrative, physical and technical safeguards; minimum necessary use and disclosure; audit controls; and documentation retained for six years.
Phase 01 classification and phase 03 privacy assessment establish minimum necessary. Data and privacy verifiers test it. Phase 07 audit controls and phase 08 retention hold the documentation obligation.
Application-level risks for LLM systems and the agent-specific threat classes: excessive agency, tool misuse, memory poisoning, and unsafe autonomy.
Phase 03 threat modelling and the agent-behaviour verifier class are written against these categories. Tool allowlists and autonomy ceilings are the mitigations, enforced at the gateway.
A technique library for real attacks on AI systems: agent deployment, tool invocation, context poisoning, credential harvesting, and exfiltration through agent tools.
These techniques are the input to phase 03 threat models and the red-team suites in phase 05. Runtime detections in phase 07 are written against the same technique ids.
Written for a regulated operations environment. The same walk applies to a claims adjustment, a benefits determination, or an eligibility review.
The operations owner files the use-case charter. Because the outcome affects a person's coverage, the use case classifies as Tier 4 before any design work starts.
Decision rights are fixed: the agent investigates and reconciles; a person decides and applies. The correction itself is never delegated.
Privacy approves a minimum-necessary boundary: one member record, one eligibility extract, read-only. The threat model covers poisoning of the source document.
The system is built in a governed workspace with four tools on the allowlist: three read APIs and one deterministic reconciliation service. The balancing logic is code, not a prompt.
Verifiers run outside the build team: retrieval authorization, tool-call correctness, injection resistance against the source document, deterministic balance check, unauthorized action attempts.
An authorizer outside the build team releases it inside a restricted boundary. The agent is registered with a read-only identity — it can propose a correction and cannot make one.
In production the agent reads the two records through the gateway, runs the deterministic reconciliation, and produces a recommendation with the reasoning and the source lines attached.
The accountable operator reviews the recommendation and the reconciliation. A second approver signs, because the change affects coverage. The update executes under the human's identity.
Runtime verifiers keep watching: drift on the reconciliation model, unusual data access, repeated failed actions, and any unexpected external communication.
Quarterly recertification confirms the owner, reviews permissions, and re-runs the verifier set against the current model version. If the owner lapses, the agent restricts itself.
Agents build. Verifiers challenge. Humans authorize. A conforming control plane enforces.
The specification defines the control-plane, observability, and verifier functions an enterprise implementation needs. Scope the architecture, operating boundary, and evidence plan before asserting conformance.
