CISA AI Guidance Needs a Lifecycle Release Record

CISA AI guidance organizes security work across design and development, followed by deployment and operation. The guidance applies to systems built from scratch and systems assembled from external models or APIs. Its strongest enterprise use is a release record that follows one AI system through all four phases and names the evidence produced at each handoff.

The document was published on November 27, 2023 by the UK National Cyber Security Centre and CISA, working with international cyber agencies including NSA and FBI. I would reject a review that marks the guidance "covered" because a team adopted a secure software policy. The guidance asks for decisions about the actual model and data. It also asks for decisions about prompts and suppliers, plus the query interface and monitoring. Updates require decisions too.

TL;DR

• CISA AI guidance divides secure AI system development into design and development, followed by deployment and operation.
• Build one release record that links the threat model and supplier evidence to security evaluation and approval. The same record should hold the monitoring plan and update history.
• Model files and cloud infrastructure need owners. Application logic and HTTP model traffic need different owners.
• DeepInspect can enforce policy and create decision records for authenticated HTTP traffic deliberately routed through it. Local models and provider-managed paths need separate controls.

CISA AI guidance covers four lifecycle phases

The official publication record names NCSC and CISA as publishers and lists the international partners. The guidance addresses AI system providers using hosted models or external APIs as well as teams creating their own components. That breadth changes the implementation question. A provider consuming an API still owns the application design and supplier decision. It also owns prompt handling and the release process. Operating controls around that API remain its responsibility.

The four phases create a useful review sequence. Design records the threat model and chosen architecture. Development records suppliers and protected assets. It also holds documentation for data and models. Prompt documentation belongs there too. Deployment records infrastructure controls and evaluation results. Incident procedures and release approval complete that phase. Operation records monitored behavior and inputs. It also captures update handling and lessons learned.

Keep those artifacts connected by a stable system ID and release version. A folder full of policies leaves the reviewer to guess which model route reached production under which approval. One indexed release record makes the relationship explicit.

Design starts with a threat model and a route map

The secure design guidance calls for staff awareness and documented threat modelling. It covers security trade-offs in model selection and supplier due diligence. It also requires controls on data sent to external APIs and restrictions on AI-triggered actions. Secure defaults and least privilege complete the list.

Turn that list into a route map for the proposed system. Name the authenticated user or agent and the application. Record the retrieval sources and model endpoint. Add the tool destinations and response path. Identify the evidence stores. Mark each trust boundary and identify where sensitive data can enter or leave. Add the model-selection decision and the accepted limitations of the chosen service.

The existing AI governance framework can hold the business purpose and accountable owner. The review cadence belongs there too. The CISA lifecycle record should go lower. It should identify the release and the routes that exist in that release. Attach the security decisions to those routes.

A one-page route map printed beside the release checklist often exposes the missing owner faster than another meeting. A line from the application to an external model with no identity or policy point marked on it is a design finding, even when every box in the procurement file is green.

Development evidence follows assets and suppliers

The secure development phase covers supply-chain review and asset protection. Documentation and technical debt are included. The guidance names models and data as assets or dependencies that need tracking. Prompts and software need the same treatment. So do logs and assessments, along with libraries and middleware. Frameworks and external APIs complete the inventory. It also recommends model cards and data cards. Software bills of materials belong with that documentation.

Create one inventory row for each production component. Record its source and version. Add the integrity reference and owner. State the approved purpose and update method. Include the fallback plan. For an external model API, preserve the provider assessment and contract reference, plus the exact endpoint and model family approved for use. For a self-hosted model, include the model artifact and its signature. Add the serving software and the environment that loads it.

Technical debt belongs in the same file because hurried AI releases accumulate undocumented prompts and temporary routes. Provider-specific workarounds belong there too. Give each exception an owner and review date. A release record with seven open exceptions is honest evidence. A clean checklist that omits them is worse than useless because it sends the next reviewer to the wrong system state.

Deployment requires a signed release decision

The secure deployment section calls for access controls on APIs and models. Data and pipelines also need access controls. It covers segregation of sensitive environments and protection of the query interface. Model and dataset integrity sit alongside incident procedures. The section also covers security evaluation and red teaming. Known limitations and secure defaults must be documented. Clear user responsibilities complete the requirements.

Package those items as a release decision with evidence references. The approver should see the threat model version and supplier status. Include the evaluation scope and unresolved findings. Add the incident runbook and rollback route. State the monitoring owner and acceptance conditions. Record the person who approved the release and the time of approval. If the model route or system prompt changes later, connect the change to a new decision instead of overwriting the old record.

The AI incident response runbook provides the operating sequence after a harmful interaction. The deployment record should prove that responders can retrieve the identity and model route before production opens. It should also retrieve the policy version and associated application event. Run that retrieval test with a synthetic request ID. A runbook earns trust when the on-call analyst can find the evidence under time pressure.

Operation turns changes into new security decisions

The operation and maintenance guidance tells providers to monitor system behavior and inputs. Providers should log inference requests or prompts in line with privacy and data protection requirements. They should apply secure update procedures and treat major changes as new versions. The guidance also calls for support for user evaluation of model changes and the sharing of lessons learned.

This phase needs two linked records. The decision log captures each governed production request at the level permitted by policy. The change log records modifications to models and prompts. It also records changes to data and routes, along with tools and controls. A monitoring alert should point back to the active release and forward to any resulting incident or change decision.

NIST's Secure Software Development Framework supplies the wider software-development vocabulary that the joint guidance aligns with. Use it for practices across the software lifecycle. Preserve the AI-specific record for model and data changes. Prompt and behavior changes belong there too because those elements can alter system behavior without a conventional source-code release.

Control ownership follows the enforcement point

The lifecycle record should assign controls according to where they can operate. Model signatures and training-data governance belong with model and ML platform owners. Infrastructure isolation belongs with cloud or platform engineering. Application authorization and tool approval belong with the application owner. Provider retention and hosted-model behavior require provider evidence and contractual controls.

An HTTP enforcement layer covers a narrower path. It can inspect traffic deliberately routed between an authenticated user or agent and an LLM endpoint. It can evaluate application-supplied identity and context. It can also apply destination or data policy and write its own decision record. Native AI inside a SaaS product may use a provider-managed route the enterprise cannot redirect. Local inference and STDIO tool execution bypass that path. Training pipelines and model weights also sit elsewhere. Endpoint protection and human approval quality do too.

The record should say "outside" beside those surfaces and name the adjacent owner. Coverage maps become credible when blank areas stay visible.

DeepInspect

DeepInspect sits at the HTTP AI request boundary between authenticated users or agents and LLM endpoints. For traffic deliberately routed through it, DeepInspect evaluates application-supplied identity and role. It also evaluates the model destination and content classification. The active policy determines whether an allowed request is forwarded. Each decision creates a signed, tamper-evident record outside the calling application's write path.

That evidence can populate the request-control portion of a lifecycle release record and support retrieval during an incident test. DeepInspect leaves model signatures and training data with the systems that own them. Cloud isolation and local execution remain outside its boundary. So do provider-managed inference and software supply-chain review. Release approval stays with the responsible team.

Book a demo today.