# 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.

Canonical URL: https://marmation.com/approach/security-and-data/

## The decision

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.

## 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.

## Related reading

- [Private AI is not one architecture.](https://marmation.com/solutions/private-enterprise-ai/)
- [A reliable system is designed for more than the ideal case.](https://marmation.com/approach/engineering-quality/)
- [Build the capability. Keep control of what belongs to you.](https://marmation.com/approach/client-ownership/)