The system has an authorization. It took eighteen months to get, the package is thousands of pages, and the authorizing official signed it on the understanding that they knew what the system does and how it is controlled. Now the program is adding a model. The question the chief engineer and the information system security officer have to answer is deceptively simple: does the new component ride the authorization the system already holds, or does it force a new assessment. The answer is not determined by policy alone. It is determined mostly by engineering decisions that get made in the first two weeks, usually by people who do not know they are making them.
This is written for the person on the prime's side who owns that outcome. The pattern below is what a model component has to look like to be treated as a change within an authorized system rather than as a new thing needing its own assessment, and what a specialist subcontractor should be delivering so that the security artifacts are ready when the assessor asks rather than assembled afterward under pressure.
What actually determines whether the authorization extends
Authorization attaches to a system with a defined boundary, a described set of information types, a documented set of controls, and an accepted level of residual risk. A change is evaluated against those four things. When a change does not move the boundary, does not introduce new information types, does not weaken or bypass a control, and does not materially change the residual risk picture, it is handled as configuration change management within the existing authorization. When it does any of those, the assessment reopens to the extent of the change, and sometimes further.
That is the whole framework, and it means the security outcome is decided by architecture. A model component placed inside the boundary, consuming data the system already holds, protected by the controls already assessed, logging to the audit path already in place, is a configuration change. The same component placed at the edge, calling an external service, holding its own copy of data, and maintaining its own separate access model is a new subsystem, and it will be treated as one.
Programs frequently choose the second design without deliberating, because the second design is what the tooling makes easy and because the component is initially built as a demonstration where none of this matters. Then it is time to deploy and the security cost of a decision nobody discussed is discovered.
Architecture choices that keep a model inside an existing authorization
Editorial weighting, illustrative rather than measured. The last row is deliberately low: a component with its own data and its own identity model is a new subsystem, whatever anyone calls it.
Boundary placement, concretely
The design that stays inside the authorization has a specific shape and it is worth describing at the level of components rather than principles.
The model runs as an internal service, called by the application tier that already exists. It has no public route, no separate ingress, and no user-facing endpoint of its own. Its callers are the same application services that already authenticate users and enforce authorization. From the perspective of the network diagram in the security package, it is another internal service in a zone the assessor already reviewed.
Its identity is a service identity issued by the same mechanism as every other service on the system. Not an API key in a configuration file. Not a shared secret held by the development team. The component authenticates to its dependencies and its callers authenticate to it the same way everything else on the system does, which means the access control narrative in the package needs one paragraph rather than a new section.
It reads data through the same data services the application uses. This is the point where designs most often drift. It is convenient to give the model direct database access, or to stand up a separate feature store, or to keep a copy of the working data where the training team can reach it. Each of those creates a new data flow that the package does not describe, and a new copy of data that has to be protected, inventoried and eventually destroyed. Where a cache or a derived store is genuinely necessary for performance, it belongs inside the boundary, under the same protections, described in the package as a component of the system rather than as an appendage.
It writes its outputs into the application's own records. The inference result is stored where the business record is stored, with the same retention and the same access controls. No parallel results database.
Training happens outside the production boundary, and nothing built there enters production except through the release pipeline. This is the one place where separation is correct. A training environment with its own boundary, its own authorization posture appropriate to the data it holds, and a one-way path into production through the same signed release process that carries every other change. Model artifacts are release artifacts. They are versioned, scanned, approved and deployed exactly like application code, and never copied in by hand.
Data flows are what the assessor actually reads
An assessor's practical question, whatever the paperwork calls it, is: where does the data go, who can see it, and how would you know if something went wrong. A model component adds several new answers to that question and each of them needs to be written down before it is asked.
Where does the training data come from and where does it live. If it is production data, say how it was extracted, what transformation or de-identification was applied, where the extract resides, who can reach it, how long it is retained and how it is destroyed. If it was moved outside the production boundary, the environment it went to has to be described and protected accordingly. A training extract sitting in a development environment nobody assessed is one of the most common findings on this class of change.
What leaves the boundary at inference time. The answer that keeps the authorization intact is nothing. Where the design calls a hosted service, that is an external interconnection with everything that implies: an agreement, a description in the package, a data flow the authorizing official is being asked to accept, and often a separate authorization inheritance question about the service itself. This is a legitimate design and sometimes the right one, but it is a different conversation and it should be started early rather than discovered at assessment.
What is retained from each inference. Inputs, outputs, scores and the human's subsequent action are operationally valuable and are also data, subject to the same categorization and retention rules as anything else. Deciding retention deliberately, and writing it into the package, prevents the awkward discovery that a component has been accumulating a shadow record of user activity for a year.
Whether any customer data trains anything outside the delivery. The answer needs to be an explicit written no, from the prime and from any subcontractor, covering both hosted services and the subcontractor's own environments. Assessors ask this now, and program offices ask it earlier than assessors do.
Model provenance: the artifact the package needs and rarely has
The security question a model raises that ordinary software does not is where the behavior came from. Code can be read. A trained model cannot, so the assurance has to come from the record of how it was produced.
The record is a build artifact, produced by the pipeline, versioned with the release, and it names six things: the model version identifier; the exact code and configuration that produced it, by commit; the data snapshot it was trained on, by version, with its lineage back to the source system; the evaluation results on a named, frozen evaluation set; any third-party model or dataset it derives from, with its origin and license; and the human or process that approved the release. Where the component uses a foundation model obtained from an external source, its identity, version and origin are part of this record.
This record does two jobs. For the assessment, it is the evidence behind the controls covering supply chain, configuration management and integrity. For the program, it is the ability to answer a question about a specific decision nine months later without a forensic exercise. Programs that treat it as an afterthought find that reconstructing it, once the pipeline has moved on, is close to impossible.
| Design decision | Keeps the existing authorization | Reopens the assessment |
|---|---|---|
| Where inference runs | Internal service inside the assessed boundary | Hosted external service, creating a new interconnection |
| How the component authenticates | The system's existing service identity mechanism | Its own credentials or a shared key held by the team |
| Where working data sits | The application's existing data services | A separate store the package does not describe |
| How the model is deployed | Through the accredited release pipeline as a signed artifact | Copied in manually or pulled at runtime from outside |
| Where audit events go | The system's existing log pipeline and retention | A component-specific log nobody else can see |
| Where training happens | A separate environment with a one-way release path in | Inside production, against live data, by hand |
Logging and monitoring that answer the questions that get asked
Security logging for a model component has to serve two audiences and most designs serve neither well. The security operations audience needs the same events as any other service: authentication, authorization decisions, configuration changes, errors, and access to data. Those come free if the component uses the system's existing identity and logging services, which is one more reason to place it that way.
The second audience is oversight, and its question is different: for this specific case, on this specific date, what did the system produce and what did the person do with it. Answering that requires the operational record described above, and it requires the model version to be recorded with each inference, because otherwise the answer to why a decision came out that way is unanswerable once the model has been updated.
Continuous monitoring adds a third set of signals that are specific to this class of component and that assessors increasingly expect to see planned: input distribution drift against the training baseline, output distribution change, rate of low-confidence results, and the divergence between the component's output and the human's action. That last one is the most useful single indicator in the system. A rising override rate is the earliest available signal that something in the world has changed, and it is available without any labeling effort at all.
Write these into the monitoring plan with thresholds and named owners, the same way availability and error-rate alerts are written. A monitoring plan that treats the model as ordinary software is incomplete, and an assessor who has seen a few of these will notice.
Failure modes that trigger a full reassessment
An external service call added late for capability reasons. A team hits a performance or capability limit, adds a call to a hosted model, and the system now has an external interconnection it did not have. This is the single most common cause of a reopened assessment on this class of change, and it is usually discovered by an assessor rather than disclosed by the program.
A training data extract nobody described. Production data copied to a development environment for a modeling task, still there months later, outside the assessed boundary. Even where the underlying decision was reasonable, the undocumented copy is a finding.
A model pulled at runtime from an external repository. Convenient in development, and it means the deployed system's behavior is determined by something outside the release process and outside the configuration baseline. Artifacts come through the pipeline or they do not come.
New information types arriving with the component. Enriching records with data from a new source, or producing a new category of derived information, can change the system's categorization. Check this before building, because it is the one item on this list that can change the control baseline itself.
Separate user accounts for the component's own interface. A management console with its own logins, standing beside a system that has a single identity story, is a new access path and reads to an assessor as a new subsystem.
Findings that most often reopen an assessment on an AI change
Editorial weighting, illustrative rather than measured. The last row is deliberately low: which model is used matters far less to an assessment than where it runs and how it got there.
What a specialist subcontractor should be delivering
Precision Federal builds AI and data systems and delivers them into production inside federal agencies, working as a specialist subcontractor under the prime's contract, inside the prime's boundary and under the prime's direction. On a change of this kind, the security artifacts are part of the deliverable rather than something the prime assembles afterward.
What the first weeks produce. Inside two weeks, a written architecture and security description for the component: where it sits relative to the existing boundary, the complete data flow inventory including training data handling, the identity and access model expressed in terms of the system's existing mechanisms, the audit events it emits and where they go, the retention decision for inference records, and an explicit statement of what leaves the boundary. Alongside it, a control-by-control note on the controls the change touches, written in the language of the program's existing package so the ISSO can drop it in rather than translate it. Where a design choice would create a new interconnection or a new data store, we say so in that document and offer the alternative that does not.
What continues through delivery. Model provenance records produced by the pipeline with every build. Evaluation results attached to every model artifact. Deployment exclusively through the prime's accredited release path. A monitoring plan covering drift, low-confidence rate and human override rate, with thresholds and owners. And configuration documentation kept current as a condition of each milestone rather than as a closeout task.
What the prime keeps. The code, the models, the pipelines, the infrastructure definitions, the evaluation sets and every security artifact, under the prime's data rights posture as the government contract requires, transferred by a present written assignment rather than a work-for-hire recital. The customer relationship stays with the prime, and our engineers speak to the government through the channel the prime designates. We are equally comfortable named as a subcontractor with a defined scope or working behind the prime's brand.
How it is priced in shape. Fixed-price milestones tied to written acceptance criteria, with the security description as a milestone deliverable in its own right, or a committed team at agreed labor categories that maps into the prime's cost structure and the contract's rate schedule.
How to start. One email with a one-page brief: the system and its authorization posture, the component in question, what data it needs, the environment and release path, the contract instrument, and the date that matters. We return a scoped, priced statement of work and, in it, our reading of whether the change rides the existing authorization or reopens it.
Bottom line
An AI component inherits a system's authorization only when it is engineered to. Put inference inside the assessed boundary with no external call. Use the system's identity, its data services, its logs and its release pipeline, so the security narrative gains paragraphs rather than sections. Keep training outside production with a one-way path in, and treat model artifacts as signed release artifacts. Produce a provenance record naming model version, producing code, data snapshot, evaluation results, third-party origins and the approval. Write the data flows and the retention decision down before the assessor asks. Do those things and the change is configuration management. Skip them and the program discovers, at the worst point in the schedule, that it has built a new subsystem.
Frequently asked questions
Not if it is engineered to sit within the system that already holds one. Authorization attaches to a boundary, a set of information types, an assessed set of controls and an accepted residual risk. A component that runs inside the boundary, introduces no new information types, uses the system's existing identity, data services and audit path, and deploys through the accredited release pipeline is handled as configuration change management. One that adds an external interconnection, a separate datastore or its own user accounts is a new subsystem and will be assessed as one.
It can, but it becomes an external interconnection: an agreement, a documented data flow, a residual risk the authorizing official is being asked to accept, and usually a question about the service's own authorization posture. That is a legitimate design when it is chosen deliberately and started early. It becomes a problem when it is added late for capability reasons and discovered by an assessor, which is the most common cause of a reopened assessment on this class of change.
An architecture and security description covering boundary placement, the full data flow inventory including training data handling, the identity and access model in terms of the system's existing mechanisms, the audit events emitted and their destination, the retention decision for inference records, and an explicit statement of what leaves the boundary. Alongside that, a control-by-control note on the controls the change touches, written in the language of the program's existing package so it can be incorporated rather than translated.
Code can be read; a trained model cannot, so assurance comes from the record of how it was produced. That record is a build artifact naming the model version, the exact code and configuration by commit, the training data snapshot and its lineage, evaluation results on a frozen set, any third-party model or dataset with origin and license, and the approval. It supports the supply chain, configuration management and integrity controls, and it is what lets a program answer a question about a specific decision months later.
The ordinary service signals, plus four specific to this class of component: input distribution drift against the training baseline, output distribution change, rate of low-confidence results, and divergence between the component's output and the human's subsequent action. The last is the most useful single indicator, because a rising override rate signals that something has changed in the world and it costs no labeling effort. Write all four into the monitoring plan with thresholds and named owners.