Trust boundaries
AI Integration Security Architecture
Design AI integration security across data and control paths, with explicit identities, approved resources and evidence for every trust boundary.
An AI integration security architecture should show who can read data, who can change decisions and who can execute actions at every boundary. A diagram containing a model, a vector database and an API gateway is incomplete unless it also identifies the identities, policies, credentials and administrative paths that govern those components.
This guide is for security architects and IT directors reviewing an enterprise integration before production. It focuses on the system's trust boundaries and operating responsibilities. Detailed model-output checks belong in guardrails implementation; the architecture must establish the surrounding conditions that prevent a correct-looking model response from acquiring unintended authority.
Separate the data path from the control path
The data path carries requests, retrieved records, model inputs, proposals and destination responses. The control path changes the policies and configuration governing that data: identity assignments, connector destinations, model versions, retrieval indexes, prompt releases and logging settings. A strong runtime design can be undermined by a weak administrative path that changes one of those dependencies without review.
Document who can modify each control and how the change reaches production. A person who can edit a retrieval-index address may be able to redirect sensitive context even without direct access to the source system. A person who can broaden a tool's scope may change the effective authority of the assistant without touching model code. Treat these as security-relevant changes.
NIST SP 800-207 describes zero trust around resource access rather than implicit trust based on network location. It is a technical reference, not a Saudi compliance certificate. In this integration, translate that principle into explicit identity and policy decisions at the resources that matter.
Build a trust-boundary register that names the evidence
| Boundary | Security decision | Evidence and owner |
|---|---|---|
| User to application | Authenticated requester, permitted task and session conditions. | Identity configuration and access tests; application owner. |
| Application to source | Authorised record population and minimum fields. | Source permission decision; data and system owners. |
| Application to model | Approved data exposure, endpoint and provider settings. | Configured route and data-flow approval; platform owner. |
| Planner to executor | Allowed action, current authority and approved payload. | Policy decision and action contract; integration owner. |
| Executor to destination | Restricted credential, endpoint and operation. | Destination permissions and receipt; system owner. |
| Operations to control plane | Who may alter policy, routing or production configuration. | Change record and deployed version; security and release owners. |
| Runtime to evidence store | Minimum necessary logging, integrity and restricted access. | Event schema and access review; operations owner. |
For each row, state what happens when the required decision cannot be made. A protected write should not proceed because a policy service is unavailable. A nonessential explanation feature might be degraded without exposing additional data. The fallback needs an explicit rationale based on the operation's consequence.
Worked example: production retrieval points at a shared test index
Consider an illustrative account-reconciliation assistant. Production requests should retrieve context from a restricted production index. During a release, a configuration value is copied from a test environment and points to a shared test index containing unrelated sample records and copied documents. Authentication succeeds, the model responds normally and the interface looks healthy.
The failure is a configuration trust-boundary breach. A prompt telling the model to use only authorised data cannot repair the fact that the wrong source was selected. Network connectivity and model availability are not adequate acceptance evidence. The release must prove the identity, environment, dataset and policy association of the configured retrieval resource.
One proposed control is an environment-bound connector manifest: production deployment accepts only approved resource identifiers, allowed endpoints and policy versions for that application. The deployment system checks the manifest, and runtime checks prevent an unexpected route. A negative test deliberately substitutes the test resource and demonstrates that the deployment or request is rejected before context reaches the model.
The recovery plan disables the affected retrieval path, preserves the relevant evidence and identifies which requests used the wrong resource. It does not assume that changing the configuration back erases data already exposed in answers or logs. The incident owner must assess those downstream copies through the organisation's response process.
Keep credentials outside the model's authority
Models should propose bounded operations rather than receive reusable destination credentials. A controlled executor obtains the authority required for the specific operation through the organisation's supported identity mechanism. Prefer narrowly scoped credentials or workload identities where supported, with clear ownership, rotation and revocation.
Do not allow free-form model text to choose arbitrary endpoints, credential names or privileged execution modes. Validate the action against an approved catalogue. Separate permission to read a record from permission to change it and from permission to administer the connector. Integration access control develops the resource and delegation policy in detail.
Review error and support paths as well as the normal path. A debugging mode that prints request headers can expose secrets even if the primary application stores them correctly. OWASP's secure cloud architecture guidance discusses controlling logged data and sensitive headers. Make the deployed logging configuration part of the security review.
Constrain network destinations and untrusted content separately
Document outbound routes for model inference, retrieval, tools, telemetry and package or configuration retrieval. An approved model endpoint does not imply approval for every external tool destination. Restrict outbound traffic according to the task and validate destinations in the executor, including redirect behaviour where relevant.
Retrieved documents, emails and tool responses can contain instructions aimed at the assistant. They should not be allowed to redefine policy, install tools or change the approved destination catalogue. Content filtering may provide signals, but the architecture must preserve the separation between untrusted content and control-plane authority.
Review attachments and links as data with their own handling rules. A document-processing component may need file-type and size limits, isolation and a supported parser. The network controls for that component should match its job; access to an internal source should not imply unrestricted access to every internal service.
Protect the artifacts that change system behaviour
Track versions of application code, prompts, model selection, retrieval configuration, tool schemas and policy bundles in the release evidence. Identify which artifacts can change independently and which combinations were tested together. A prompt is not executable application code, but changing it can change the actions the model proposes and therefore deserves an appropriate review path.
Review third-party components according to their privileges and data exposure. An embedding library, document parser, connector package and model endpoint create different dependencies. Keep a component inventory with version, owner, update route and the effect of removal. An integration that cannot operate without an unowned component has an operational security gap.
Require a clear route from reviewed artifact to deployed configuration. The exact signing, build and deployment mechanism depends on the environment, but the acceptance question is concrete: can the team show that the running service uses the intended versions and that unauthorised changes are detected or prevented?
Connect privacy, location and evidence to the architecture
Mark personal and sensitive information on the actual data flows. Source documents, embeddings, prompts, cached answers, support tickets and backups can have different locations and access paths. PDPL integration compliance addresses purpose and processing responsibilities, while data residency provides the location-and-transfer evidence map. Hosting one component locally does not settle the complete flow.
Design audit logging to show actor, policy, proposal, approval, execution and outcome without storing every sensitive payload. Protect the audit store from the same identities that can change the application, where practical, and document administrative exceptions. Evidence should survive an incident without becoming an unnecessary second repository of confidential records.
Determine the applicable regulatory and contractual requirements for the entity, sector and data. NIST and OWASP are useful technical references; their use alone does not demonstrate fulfilment of a Saudi regulator's binding requirements. The architecture review should identify the applicable obligations and the evidence used to satisfy each one.
Accept the architecture through failure exercises
Ask the team to demonstrate a revoked user, an unavailable policy decision, a forbidden destination, a substituted retrieval index and an uncertain destination outcome. Verify the resulting behaviour and the evidence available to operations. These exercises test whether the diagram's boundaries exist in the deployed system.
Define who can disable a tool, isolate a connector and restore a known configuration. Test whether those actions preserve the remaining authorised service and whether operators can distinguish blocked requests from committed actions. Recovery should be designed before broad production permissions are issued.
For AI integration and delivery with OpenForAI, prepare the current architecture, identity flows, proposed tools and a masked example of sensitive data movement. Enquire about an AI integration security architecture review with the system owners identified, so that trust boundaries and release evidence can become an agreed delivery scope.
FAQ
Your questions, answered.
What is the difference between AI guardrails and security architecture?
Guardrails implement specific checks on inputs, proposals or actions. Security architecture defines the wider identities, trust boundaries, credentials, network routes, administrative controls and evidence paths within which those checks operate. Both are needed. A well-filtered model response does not compensate for a connector pointing at the wrong data source or holding excessive destination permissions.
Why should prompts and connector configuration appear in a security review?
They can change what the system reads, proposes and executes without an obvious application-code change. Identify who may alter them, how changes are reviewed and which tested versions reach production. Treat routing and permission changes according to their consequences. A production service should be able to demonstrate its actual configuration, not just its intended design.
Does a private network make an AI integration trustworthy?
Network isolation can reduce exposure, but it does not establish the authority of every user, service or retrieved document inside that network. Apply explicit identity, resource and action controls at relevant boundaries. Review administrative access and outbound routes as well. The trust decision should follow the task and resource, not location alone.
Should a model receive credentials for the systems it uses?
Prefer a controlled executor that holds or obtains the required authority outside the model-visible context. The model proposes a bounded operation, while the executor verifies permission and supplies the destination connection. This reduces the risk of credentials appearing in prompts or outputs and makes revocation and action restrictions easier to enforce and audit.
How can we test that production cannot use a test retrieval index?
Bind approved resource identifiers and policy context to the production configuration, then deliberately substitute the test resource in a controlled negative test. Verify rejection before data reaches the model. Also check deployment permissions and runtime routing. A healthy connection or valid service credential alone cannot establish that the selected resource belongs to the intended environment.
Does using NIST or OWASP demonstrate Saudi regulatory compliance?
They are technical references that can support a security design, not automatic evidence of compliance with every Saudi requirement. Determine the obligations that apply to the entity, sector and data flows, then map them to implemented controls and retained evidence. Keep binding obligations, contractual commitments and voluntary engineering practices distinguishable in the review.