Agentic AI for controlled environments

Controlled environments change the architecture of agentic AI. A workflow cannot assume a public model endpoint, vendor-hosted policy service, remote telemetry, online package registry, or unrestricted administrator access. Every dependency and update path becomes part of the boundary decision.

The governing question is not "Can the model run locally?" It is "Can the entire governed workflow operate, fail, update, and be investigated inside the required environment?"

What is a controlled environment?

A controlled environment is an information system or enclave with explicit rules for identity, data, connectivity, administration, software change, monitoring, and incident response. It may be cloud-based, on-premise, disconnected, classified, or operated by a nonfederal contractor handling CUI.

The same product can have different obligations across contracts and deployments. Treat the applicable contract, agency direction, system security plan, authorization boundary, and official standards as authoritative.

Which components must fit inside the boundary?

Component	Boundary question	Evidence to request
Identity	Which credential and directory establish the actor?	Federation or local identity design and revocation test
Models	Where do weights or endpoints execute?	Endpoint inventory, location and release manifest
Orchestration	Where are plans, queues and task state held?	Deployment diagram and failover behavior
Policy	Can every authorization decision occur locally?	Policy bundle, attribute sources and unavailable behavior
Approval	Can authorized reviewers act inside the enclave?	Reviewer roles, parameter binding and expiry tests
Tools	Which target systems can the agent reach?	Typed operation catalog and network path inventory
Audit	Where are decision records stored and verified?	Record format, retention, verifier and export procedure
Administration	Who can configure models, tools and policy?	Privileged-access model and change records
Updates	How do releases and model weights enter?	Transfer, validation, signing and rollback process
Support	What can the vendor observe or access?	Shared-responsibility and remote-access boundary

A hidden external dependency can invalidate the deployment claim even if the main application is installed locally.

What does CUI change for agentic systems?

NIST SP 800-171 Rev. 3 addresses protection of CUI in qualifying nonfederal systems and organizations. Agentic systems add special attention to how CUI enters prompts, retrieval, memory, model endpoints, tool arguments, outputs, logs and support processes.

Define the CUI boundary

Identify every component that processes, stores, transmits, or protects CUI. Include queues, caches, embeddings, vector stores, traces, backups, model-serving logs, test fixtures, support bundles and audit exports.

Prevent unapproved model routing

The runtime should select only model endpoints approved for the data class, purpose and environment. Fallback to a public endpoint during local capacity loss can create an unauthorized transfer.

Control tools as data paths

An agent can move CUI through email, storage, ticketing, browsers, APIs or generated documents. Tool authorization must evaluate destination, classification, purpose and reviewer authority before transmission.

Treat audit data as controlled when appropriate

Decision records may reference CUI, identities, missions, vulnerabilities or investigative facts. Apply classification, access, retention, media and export rules to the evidence store itself.

How should NIST SP 800-171 families shape the design?

The following is a design-oriented reading, not a complete requirement crosswalk.

Control family	Agentic-system focus
Access Control	Per-action authorization, least-privilege tools, controlled information flow
Audit and Accountability	Identity-linked decisions, tool effects, integrity verification, review and retention
Configuration Management	Versioned models, policies, prompts, adapters and approved baselines
Identification and Authentication	Human, service and agent identity, strong privileged access
Incident Response	Revoke agents and tools, preserve evidence, contain side effects
Media Protection	Controlled transfer of releases, weights and evidence in disconnected environments
Risk Assessment	Threats from tool use, model behavior, dependencies and affected parties
System and Communications Protection	Boundary enforcement, approved routes, cryptographic protection
System and Information Integrity	Change detection, flaw remediation, malicious input and dependency monitoring
Supply Chain Risk Management	Model, library, tool, data and update provenance

Use the official publication and assessment procedures for the actual requirement and evidence expectations.

What does CMMC change?

CMMC is not a product feature. It is a DoD assessment program applied through applicable contracting requirements. A vendor can supply software, documentation, control capabilities and evidence that support a contractor's program, but the contractor's environment, policies, people and practices remain part of the assessment.

Ask vendors to distinguish:

• the product's built-in controls;
• controls configured for the customer;
• inherited infrastructure controls;
• customer-owned procedures;
• evidence available from the exact release;
• items outside the product boundary.

Avoid "CMMC compliant software" as a standalone claim. The meaningful question is how the product affects the scoped environment and assessment objectives.

Where does FedRAMP fit?

FedRAMP provides a standardized authorization approach for cloud services used by the federal government. It is not a generic security badge for all software, and it does not describe an offline enclave.

For a cloud deployment, determine whether the relevant cloud service and complete service offering fall within an authorization path acceptable to the agency. For on-premise or disconnected deployment, identify the applicable agency authorization and control framework instead of forcing the architecture into cloud vocabulary.

Trunnion public materials describe alignment goals and deployment patterns. They do not claim that every product, configuration or customer environment holds a FedRAMP authorization.

What does an air-gapped architecture require?

An air-gapped deployment has no runtime route to external networks. The complete operating stack must be local.

In-boundary models

Model weights, inference services, routing and evaluation data remain inside. Hardware capacity and task-specific model selection become deployment responsibilities.

In-boundary governance

Policy decisions, approval state, identity validation, audit commitment and verification cannot depend on vendor cloud services.

Controlled updates

Software, policies and model weights enter through an authorized transfer process. Validate signatures, provenance, malware checks, compatibility, rollback and media handling before installation.

Local observability and support

Monitoring and evidence stay in the enclave. Support procedures must specify what can be exported, who approves it, how it is sanitized, and how the transfer is recorded.

Capacity-aware behavior

The system should not silently switch to an external provider when local inference or storage is constrained. Define queueing, degradation and stop conditions.

How should human authority work in a controlled environment?

Reviewer identity should come from the environment's approved identity and access processes. The approval service needs local authorization, current revocation, parameter binding, expiry and audit.

Consider shift coverage, two-person rules, separation of duties, incident overrides, unavailable reviewers and operational tempo. Approval architecture must work during the conditions for which the system is procured, not only during a staffed demonstration.

How do you manage models and updates?

Each release package should identify model weights or endpoints, evaluation results, policy bundle, tool adapters, schema versions, dependencies, signatures and compatibility constraints.

For disconnected transfer:

1. Build the release from controlled source.
2. Produce a signed manifest and hashes.
3. Scan and review in a staging environment.
4. Transfer through approved media and custody.
5. Verify signatures and hashes inside the boundary.
6. Install through change control.
7. Run release-specific evaluation and negative tests.
8. Retain evidence and rollback or recover-forward steps.

The update path is part of the system security posture. An air gap with an informal transfer process moves risk rather than removing it.

What should the audit package contain?

A controlled deployment needs enough evidence to reconstruct a consequential action without exporting sensitive raw data casually.

Include identity, task, data references, model and policy versions, approval, typed tool operation, target, result, state verification and tamper-evident linkage. Apply authorization and classification to audit searches and exports.

Test edited, deleted, reordered and truncated records. Also test completeness at the actual side-effect boundaries. A valid chain cannot reveal an event that was never written.

What should a buyer put in the evaluation plan?

1. Define the intended environment and data classes.
2. Inventory every external dependency and administrator path.
3. Run the workflow with external connectivity blocked where disconnection is required.
4. Verify identity, revocation and reviewer authority locally.
5. Attempt unapproved model and tool routes.
6. Test cross-tenant and cross-classification access.
7. Interrupt model, policy, queue, tool and audit dependencies.
8. Install a signed update through the intended transfer process.
9. Export and independently verify a bounded evidence package.
10. Document customer, vendor and infrastructure responsibilities.

The result should be a gap list tied to owners and release criteria, not a generic assurance score.

What is Trunnion's federal delivery boundary?

Trunnion AI owns its product technology. DAF is delivered to federal customers exclusively through Viceroy NM, a separate Duskbridge operating company. Other federal software work follows the acquisition route established for the specific opportunity. This page remains Trunnion product architecture and diligence guidance, not a Viceroy capability statement and not a claim of contract eligibility or authorization.

Exact controls, providers, deployment options, assessment status and availability vary by release, configuration, customer environment and written scope.