AI design control turns approval into a living governance control

At a glance

What this is: JetStream Security says AI governance fails when teams treat approval as a one-time document instead of a live control over the running system.

Why it matters: This matters because IAM, NHI, and AI governance teams need evidence that approved models, tools, data sources, and identities still match reality after every change.

Context

AI design control is the governance problem created when an approved system keeps changing after the approval event. In agentic environments, models, tools, data sources, and identities can shift without a new review, so the control has to track the live design rather than the original filing.

That makes the topic directly relevant to AI governance and to the identity layer underneath it. When a system reassembles itself over time, the question is not only whether the policy was approved, but whether the runtime still reflects the approved AI governance guide and the identities attached to it.

Key questions

Q: What breaks when AI approval is only a one-time review?

A: Approval without ongoing design control leaves no reliable way to prove the live system still matches what was approved. Models, tools, data sources, and identities can change after sign-off, so the gap becomes invisible until an audit or incident exposes it. The failure is not the policy itself, but the absence of a control that keeps the running system aligned with the approved design.

Q: Why does AI governance need both oversight and evidence capture?

A: Oversight without evidence is hard to defend, and evidence without oversight is just recordkeeping. Organisations need both because regulators, auditors, and risk leaders want to see how decisions were made, who approved them, and what changed over time. Good governance proves that controls operated consistently, not merely that policy existed.

Q: How should teams govern model, tool, and identity changes together?

A: Treat them as one change-managed system. A model swap, tool update, or identity change can alter behavior and access at the same time, so the control should require a single versioned record, a review of the change, and a check that the runtime still matches the approved design.

Q: When does AI design drift become a compliance problem?

A: It becomes a compliance problem as soon as the live system no longer matches the documented one and the organization cannot prove when the change occurred or who approved it. At that point, the gap is no longer just operational drift. It is a governance failure that can undermine auditability and accountability.

Technical breakdown

Why inventory is not enough for agentic systems

An inventory tells you that an AI system exists and lists its components. It does not show how those parts connect or whether a later model swap, tool change, or data-source change has altered the system's actual behavior. In agentic environments, the runtime can diverge from the documented state without a formal release, so inventory is necessary but not sufficient. Design control adds the missing layer: a versioned description of the system's parts and relationships, plus a mechanism to detect when the live system no longer matches that description. See the AI Governance Guide.

Practical implication: treat inventory as the starting point and require a versioned design record for every production AI system.

Why identity and connections matter in AI design records

A useful design record names not only the model and tools, but also the identities the system uses to act. Those identities shape authorization, data access, and the blast radius of a change. If an agent’s model or tool changes, the security impact often travels through the connected identities and permissions rather than the component that changed first. That is why design control must capture relationships, not just components: the operational risk lives in the dependency graph, not the part list. See the Agentic AI Security Policy Template.

Practical implication: document the identities and access paths that each AI workflow depends on, not just the software components.

How versioning turns approval into an auditable control

Approval becomes meaningful only when the approved state can be compared with the live state over time. Versioning makes that comparison possible by creating a new, reviewable record whenever a material change occurs. Without version history, auditors can only see a snapshot and teams cannot prove when drift began. With version control tied to governance, the organization can show what changed, who accepted it, and whether the change stayed within the approved design envelope. That is the difference between policy intent and operational evidence.

Practical implication: enforce versioned change control so every material AI modification leaves an auditable trail.

Breaches seen in the wild

• iOS apps leaking hard-coded secrets: Cybernews found 71% of 156,080 iOS apps leak hard-coded secrets, with open cloud storage and Firebase databases exposing user data.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Design control is the missing governance layer between AI approval and AI operation. Policies, risk reviews, and sign-offs matter, but they do not keep a live system aligned with the version that was approved. In agentic environments, the control has to travel with the system and keep drift visible. The practical conclusion is simple: if the runtime can change without a new evidence trail, the governance model is incomplete.

AI governance now depends on proving state, not just approving intent. The standards landscape increasingly expects evidence that the live system matches the documented one, including who owns it, what it uses, and how changes are reviewed. That shifts the discipline from a document-management exercise to an evidence-management exercise. Practitioners should treat drift detection as part of governance, not as a separate technical nicety.

Identity is part of the AI control surface, not an adjacent concern. When models, tools, and data sources change, the identities bound into those flows determine what the system can reach and how far an error can spread. This is why agentic AI security policy and AI governance cannot be separated from access governance. The practitioner takeaway is to govern the AI system and its identities as one moving object.

Audit readiness will increasingly depend on continuous comparability between the approved design and the running system. A static approval artifact cannot answer the question auditors increasingly ask: what changed, when, and under whose control? The organizations that can answer that from live records will have a materially stronger governance posture. The conclusion is to make comparability a built-in requirement, not a manual reconciliation step.

The named concept here is design control. It is the practice of keeping the approved AI design and the running system in agreement through versioned records, reviewable change, and evidence of drift handling. That concept matters because it translates AI governance from intent into verifiable state. Practitioners should build their governance around that living record, not around a one-time approval.

Read next: ISO/IEC 42001 Guide

What this signals

Design drift will become a standing governance risk for agentic AI. As systems reassemble themselves through model updates, tool changes, and shifting data sources, governance teams will need continuous comparability rather than periodic review. The operating question is no longer whether the system was approved, but whether the approved design still exists in production.

Identity governance has to move closer to AI runtime control. When an AI system changes, the access paths attached to it change with it, which means identity, authorization, and evidence collection cannot sit outside the design record. That is why teams should align AI change control with agentic AI security policy rather than treating it as a separate administrative process.

Audit readiness will increasingly depend on versioned evidence. The strongest programs will be the ones that can show each material change, who accepted it, and how the live system was kept within bounds. In practice, that means building governance around the runtime record instead of trying to reconstruct it after the fact.

For practitioners

• Implement a design of record for every AI system Name the models, tools, data sources, and identities that make up each production AI workflow, then keep that record aligned with runtime reality.
• Version every material AI change Require a new reviewable version whenever the system changes in a way that could affect behavior, access, or compliance evidence.
• Tie approvals to runtime evidence Make sign-off contingent on being able to show the current system still matches the approved design, not just that the approval happened.
• Map identity dependencies inside AI workflows Document which service accounts, tokens, APIs, and human approvals each agent uses so the blast radius of a change is visible.
• Refresh impact assessments when the design changes Treat the assessment as part of the live system and re-evaluate it whenever the design of record changes materially.

Key takeaways

• AI approval becomes weak control if the live system can diverge from the documented design without a new review.
• The key governance shift is from static sign-off to versioned evidence that the running system still matches what was approved.
• Identity, model, tool, and data changes should be governed as one moving system, not as separate administrative tasks.

Related NHI Mgmt Group resources: AI Governance Guide · Agentic AI Security Policy Template · ISO/IEC 42001 Guide

Key terms

• Design Control: Design control is the practice of keeping the approved description of an AI system aligned with the system that is actually running. It combines versioned records, change review, and evidence that the live configuration still matches the approved design.
• Design Of Record: A design of record is the authoritative, versioned description of an AI system's models, tools, data sources, and identities. It gives auditors and operators a single reference point for verifying what the system is supposed to be and whether it has drifted.
• Runtime Drift: Runtime drift is the gap between an AI agent’s approved authority and its actual behaviour as conditions change. It appears when the agent adapts to new context, new integrations, or new instructions and begins acting outside the scope that governance originally defined.
• AI governance evidence: AI governance evidence is the documentation and telemetry used to show what an AI system accessed, decided, and changed. It includes logs, approvals, policy results, and ownership records. Without evidence, finance cannot justify spend and security cannot prove that AI usage stayed within approved boundaries.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners connect identity control to broader security programmes that need defensible evidence and lifecycle governance.