Define the boundaries before connecting the model.
AI systems can access confidential knowledge and initiate actions through tools. Designing their boundaries is part of product architecture, not an optional checklist added after the interface is built.
Where may information go—and who may authorize an action?
Resolve identity, data movement, provider terms and tool authority as architectural decisions. “Private AI” is not a sufficient answer to any of them.
Draw the boundaries before connecting the model.
Identity & source systems
- Who is asking?
- Which information can that identity access?
- Which source is authoritative?
Application boundary
- Enforce retrieval permissions.
- Limit the context sent for inference.
- Treat returned content as data, not authority.
Approved inference boundary
- Permitted provider or hosting model.
- Approved region and retention terms.
- Explicit handling of logs and subprocessors, where relevant.
A proposed action crosses a separate boundary.
Tool credentials, allowed operations and human approval must follow the agreed authority model. A model response is not permission to make a consequential business change.
Follow the information. Every copy matters.
The original document is only the start. Requests, responses and operational traces can create other copies with different access and retention rules.
- At the source
What is collected, who may access it and which restrictions follow it?
Ask to inspectInformation inventory, source permissions and the agreed data-flow map.
- In the model request
What leaves the application boundary, to which service and under which terms?
Ask to inspectRequest contents, provider configuration, region and relevant contractual terms.
- In logs and traces
Could debugging create another copy of confidential information? Who can read it?
Ask to inspectLogging fields, redaction rules, access roles and retention configuration.
- Through retention and deletion
How long does each copy remain, and what does deletion actually cover?
Ask to inspectRetention schedule, deletion behavior and documented provider limitations.
Ask to inspect the actual architecture, current controls and operating policies, named incident and recovery ownership, and the scope of any independent audit. Confirm which deployment and time period the evidence covers.
The full argument for security and data boundaries
For CTO, CIO, CPO, COO
Begin with the permitted data flow
This is a proposed engagement approach: security requirements should shape the architecture before a model or integration is selected.
For example, one organization may permit an enterprise model API with specific retention terms. Another may require a particular region, and a third may prohibit external inference. Establish which requirements apply to the intended workflow and obtain the relevant stakeholders' agreement.
Make the boundaries inspectable
Map source data, identity, application permissions, model access, integration credentials and logs. Distinguish what a system may read, suggest, approve and write. Trace where information goes, which services process it and who can access it.
Define the permitted actions and failure behavior. Consequential writes may need human approval, bounded credentials and an audit record. Retrieval must respect the user's access rather than treating a shared index as permission to disclose everything in it.
Verify the deployment, contracts and operating plan
Review provider terms, region, retention, licensing and incident responsibilities for the selected configuration. Managed services and self-hosted components both require an explicit operating plan; neither deployment label establishes security by itself.
Agree who maintains dependencies, reviews access, investigates failures and authorizes changes. Determine which records are necessary, how they are protected and when they should be deleted.
Test the important failure cases
Use authorized and unauthorized personas, denied tool actions, stale access, missing dependencies and representative sensitive-data cases. Record the expected result and the evidence needed before production approval.
These are project review criteria. Any organizational assurance, certification or external audit must be established separately with its actual scope and evidence.
A sensible first step
When security requirements determine feasibility, resolve the data and authority boundaries in a decision and architecture engagement before expanding implementation.