Foundations
What is full lifecycle AI governance?
Full lifecycle AI governance means one policy model applied across an agent's whole life: mapping what it is able to do before it ships, enforcing that scope on every action in production, and recording each decision as evidence. The stages matter less than the fact that they share a single policy definition — the scope an agent is reviewed against before deployment is the same scope it is held to in production and the same scope cited in the audit record.
Three stages, one policy
Governance that exists only at design time cannot stop anything, because an agent decides what to do while it is running. Governance that exists only at runtime cannot tell you what the agent was ever supposed to do, because there is no baseline to compare against. Both halves are necessary, and the value comes from them sharing one definition of scope.
- Map — design time. Before an agent ships, its complete action surface is enumerated: every tool connected, every operation exposed, every system of record reachable. Each operation is classified against Segregation of Duties rules and regulatory regimes. The agent's authorized scope becomes a written artifact rather than an assumption.
- Enforce — runtime. In production, every action is evaluated against that scope after the agent reasons and before the tool call executes. Safe actions clear. Actions crossing a boundary are blocked, or held and routed to a named approver.
- Record — continuous. Each decision is written as evidence at the moment it is made, tying the action to the agent, the person it acted for, and the policy it was judged against.
Because the same policy definition drives all three, there is no translation step between what was reviewed, what is enforced, and what is reported — and therefore no gap for the three to drift apart in.
What breaks when the stages are separate tools
Most enterprises assemble this from point solutions, and the seams are where the governance leaks out.
A design-time review in a spreadsheet produces a document nobody can enforce. The agent ships, someone changes a tool binding three weeks later, and the document is now fiction with no mechanism that notices. A runtime tool bought separately enforces its own rules, written in its own language, against a scope it derived independently — so passing review and passing enforcement become two different things and an agent can do both while still doing something nobody approved.
Then the audit arrives and the evidence has to be assembled from three systems that disagree. The review says the agent was approved for read access. The gateway log says a call was made. The application log says a record changed. Nothing anywhere states that the action was authorized, by which rule, or on whose authority, because no single component ever made that determination.
This is why lifecycle coverage is a property of the policy model rather than a feature checklist. Three tools each covering a stage is not the same as one policy covering three stages.
Where the lifecycle actually starts
It starts earlier than most teams expect: at the moment someone connects an agent to a tool, not at the moment the agent is deployed.
The reason is that connection is what creates exposure. An agent wired to a finance MCP server has, from that instant, the ability to call every operation that server exposes — including the ones nobody intended it to use, because access is granted per server while risk lives per operation. If the first governance step happens at deployment review, the action surface has already been set by whoever chose the integrations, and the review is characterising a decision rather than making one.
Mapping the action surface at connection time inverts that. You see the exposure the moment it is created, classified against the rules that apply to it, and the deployment review becomes a decision about a known scope rather than an investigation into an unknown one.
The lifecycle in a real deployment
Concretely, for an accounts payable agent moving into production:
- Connection. The agent is bound to the ERP's MCP server. SCOPE-MCP enumerates 31 operations across it, flags 15 as touching Segregation of Duties boundaries, and classifies which fall under SOX.
- Scoping. The agent is granted read on invoices and vendors, create on payment proposals, and explicitly not approve. That scope is now the artifact both the reviewer and the runtime read from.
- Production. Arbiter evaluates each action against it. Reading an invoice clears. Creating a proposal clears. Approving a payment the agent itself raised is blocked as an SoD violation, before it executes.
- Threshold. A proposal above the configured value is not blocked but held, routed to the named approver for that scope, and released only when they decide.
- Audit. Every one of those decisions is already recorded with its policy, decision, and approver. Nothing is reconstructed, because nothing was ever missing.
The foundation is reusable. The second agent inherits the classified catalogue, the policy model, and the approver routing, so the lifecycle cost is paid once rather than per agent.
Common questions
How is lifecycle AI governance different from AI observability?
Observability tells you what happened; lifecycle governance decides what is allowed to happen and proves it afterwards. An observability tool traces agent behaviour, surfaces anomalies, and gives you dashboards, all of which is genuinely useful for understanding a system in production. What it cannot do is refuse an action, because it sits beside the execution path rather than in it, and it has no design-time notion of what the agent was scoped to do in the first place. The distinction shows up in an incident: observability shows you the agent deleted the record, and governance is what would have stopped the call.
Where does MLOps or model governance fit in this lifecycle?
Alongside it, governing a different object. Model governance covers the model — how it was trained, evaluated, versioned, and whether it performs acceptably — and remains necessary. Agent governance covers what a system built on that model is permitted to do in your enterprise. A perfectly governed model can be wired to a tool it should never have been given and take an action nobody authorized, because nothing about model provenance constrains an action surface. ISO/IEC 42001 expects an organisation to address both, which is why the two programmes usually end up reporting into the same place without merging.
Do you need design-time mapping if you already enforce at runtime?
Yes, because runtime enforcement needs something to enforce against. A check in the path of an action has to compare the operation to a scope, and if that scope was never established the check degrades into either allowing everything not explicitly forbidden or asking a model to judge, which reintroduces exactly the problem determinism solves. Mapping first is also what keeps the runtime decision cheap: comparing an operation against a pre-computed classification is a lookup rather than an analysis, so safe actions clear without perceptible latency.
How long does it take to bring one agent through the full lifecycle?
Four to six weeks is the realistic figure for a first priority agent in a regulated workflow, and that is the scope LangGuard's forward-deployed engagements are fixed to. The first two weeks establish the governance harness across existing gateways, tools, models, and runtimes. The middle weeks wire in identities, trusted paths, and human authority controls, and author the policies for what should be allowed, escalated, or blocked. The final weeks bring monitoring, audit, and containment live and hand over runbooks. Subsequent agents are substantially faster because they reuse the classified catalogue and policy model.
What happens to the lifecycle when an agent is changed after deployment?
A change to what an agent can reach is a change to its action surface, so it re-enters the mapping stage rather than bypassing it. Adding a tool binding exposes new operations, and those are enumerated and classified the same way the originals were, which either extends the approved scope or flags that the change takes the agent outside it. This is the failure the spreadsheet-review model cannot catch: a document written at deployment has no way of noticing that someone attached a new MCP server three weeks later, whereas a scope derived from live bindings does.
Map one agent's action surface and see the lifecycle start.
LangGuard maps your complete agent action surface in minutes. Free for the first five managed agents, with every Scope included from day one.