AI security architecture becomes a serious concern when someone asks one of the most feared questions in a digital strategy meeting: “We already have the pilot working. Can we open it to the whole company tomorrow?”
The short answer is no. The longer answer begins when a convincing demonstration meets the disorder of the real world.
A pilot behaves well in a controlled room because everyone knows where its boundaries are. Production removes that comfort. Real users ask unexpected questions. Permissions differ. Documents become outdated. External services fail. Sooner or later, someone will deliberately test the seams.
This is the point where AI security stops being cybersecurity around a model and becomes architecture around uncertainty.
Unlike traditional deterministic software, where input A is expected to produce output B, Large Language Models are probabilistic and, by design, influenceable. A firewall may protect the entrance to the system, but it cannot decide what the model is allowed to retrieve, infer, reveal or execute.
A secure AI solution must therefore be built in layers, under a simple assumption: the model can be wrong, manipulated or given more authority than it should have. The objective is not to eliminate uncertainty. That would be an impossible promise. The objective is to contain its consequences.
Five architectural pillars provide the foundation for doing that in production.
Access Control Must Begin Before Retrieval
One of the most dangerous mistakes in a RAG architecture is to give the model a master key to the entire company knowledge base and then ask it politely not to open certain doors.
That is not security. That is a suggestion.
A system prompt may tell the model not to reveal confidential information, but it is not an authorisation boundary. If an employee asks, “What is the CEO’s salary?”, and the relevant payroll document has already entered the model’s context, the system has failed before the answer is generated. Even if the model refuses, sensitive information has reached a component that never needed to see it.
In an AI security architecture, access control must therefore be enforced at the retrieval layer.
Before a vector search returns any fragment, the system should verify the user’s identity, role, organisation and permissions. Security metadata must be attached to each document and preserved when that document is divided into smaller fragments. This allows the retrieval engine to exclude unauthorised information before it reaches the model.
This becomes particularly important in systems used by several departments, organisations or clients. Two users may submit exactly the same question and legitimately receive different answers because they are not authorised to access the same sources.
The architecture must also reflect permission changes. Removing access to a document in the original business system is not enough if an outdated copy remains available in the vector index.
The principle is simple. The model should never be asked to protect information that the user was never entitled to retrieve. Identity checks, permission aware retrieval, least privilege access and audit trails must work together before generation begins.
Traceability Must Reconstruct the Decision
Traditional logs can tell us that a request failed, that a service responded in 200 milliseconds or that a server returned an error. They can describe the health of the machinery. They cannot explain why an AI system produced a particular answer.
In a conventional application, the path from input to output is usually predictable. With AI, the same question can produce different results depending on the retrieved documents, the model version, the system instructions and the context available at that moment.
This changes what must be recorded.
Within an AI security architecture, a useful audit trail should connect the user request, the identity and permissions involved, the retrieved sources, the model and configuration used, the generated response and any action that followed. Without that chain, investigating an incorrect or harmful answer becomes an exercise in guesswork.
Think of it as a flight recorder. Its purpose is not to prevent every incident. Its purpose is to make the sequence understandable when something goes wrong.
However, recording everything without discipline creates another risk. Prompts and responses may contain personal, confidential or regulated information. An audit system can easily become a second repository of sensitive data if access, encryption and retention are not designed carefully.
Traceability must therefore be both complete enough to reconstruct an important decision and controlled enough not to create a new source of exposure. The question is not simply whether the system keeps logs. The question is whether those logs can explain what happened, to the right people, without revealing more than they should.
Protect Data in Both Directions
An AI security boundary has two doors. One controls what enters the model. The other controls what is allowed to leave it.
Before a request is sent to an external model, the system should examine the information it contains. Names, email addresses, customer identifiers, financial details and other sensitive elements may need to be removed, masked or replaced with controlled references.
For example, “John Smith” can become “PERSON 1” before the request leaves the trusted environment. If the original identity is still required later, the correspondence must remain inside that protected boundary. The external model receives enough context to complete the task, but not more information than the task genuinely requires.
Input protection must also look beyond personal data. Files, links and instructions can contain malicious content designed to alter the behaviour of the model or persuade it to ignore its rules.
The same discipline is required on the way out. A generated response may expose confidential information, reproduce a secret, contain unsafe code or attempt to trigger an action that the user is not authorised to perform. Output controls should therefore examine both the content of the response and the consequence of using it.
Data Loss Prevention is part of this defence, but it is not a magic filter. Detection systems can miss sensitive information or block legitimate content. Controls should reflect the risk of the action. Drafting an internal summary does not require the same level of inspection as modifying a customer record or executing code.
Security is not achieved by trusting the model to recognise every boundary. It is achieved by building those boundaries around it.
AI Agents Need a Controlled Environment
When an AI system only generates text, most failures remain informational. The moment it can use tools, query databases, read emails, call APIs or execute code, the risk becomes operational.
Connecting a model to these capabilities does not simply create a more intelligent assistant. It creates a software identity that can act across the organisation.
The danger does not always come from the user. A malicious instruction may be hidden inside a document, an email or a web page that the agent has been asked to analyse. If the model treats that content as an instruction rather than as data, it may attempt to access another system, reveal confidential information or perform an action nobody intended.
An attacker could, for example, ask the agent to summarise an internal administration page. If the service running the agent has unrestricted network access, the model may reach systems that the user could never access directly. This is one form of Server Side Request Forgery, but the architectural problem is broader. The agent has been given a larger field of action than its task requires.
Each agent should therefore operate with its own restricted identity, explicit permissions and a limited list of approved tools and destinations. Read access should be the default whenever modification is unnecessary. Code execution should take place inside a temporary environment with strict limits on network access, time, memory and available files.
Sensitive actions should also require validation outside the model. Sending a message, modifying a customer record or executing a financial operation should not depend solely on the model deciding that the request appears legitimate.
Every tool connected to an agent increases its reach. Good architecture ensures that an error remains contained instead of becoming an action across the company.
Test How the System Fails, Not Only How It Works
Traditional unit tests ask whether software produces the expected result. AI security testing must ask a more uncomfortable question: what happens when someone deliberately tries to pull the system in the wrong direction?
Prompt injection is one of the clearest examples. A user may directly ask the model to ignore its instructions, reveal confidential information or use a connected tool in an unauthorised way. The instruction may also be hidden inside a document, email or web page that the system retrieves and places in the model’s context. The OWASP Top 10 for LLM Applications provides a practical reference for risks such as prompt injection, sensitive information disclosure, improper output handling and excessive agency.
Testing only normal questions will never reveal these weaknesses. It is like evaluating a lock using only the correct key.
Red teaming introduces the behaviour of an attacker before a real attacker does. The objective is to discover whether the system can be persuaded to expose protected data, cross permission boundaries, reveal its internal instructions, generate dangerous content or misuse the tools connected to it.
This process should combine automated attack libraries with scenarios based on the organisation’s actual data, workflows and risks. A generic test may detect a common weakness, but it cannot anticipate every way a financial team, healthcare provider or industrial operator could be exposed.
The results must also be measurable. Teams should record which attacks succeeded, which controls stopped them, where legitimate requests were blocked and how the system behaved when it could not respond safely.
Red teaming is not a ceremony performed once before launch. Models change. Prompts change. Data changes. New tools are connected. Each significant modification can reopen a weakness that appeared to be closed.
The purpose is not to prove that the system is impossible to break. No serious security architecture can make that promise. The purpose is to understand how it fails, reduce the available paths of attack and detect abnormal behaviour before the consequences become operational.
AI Security Architecture Is What Allows AI to Scale
Security is often presented as the brake that slows innovation. In reality, a brake is what allows a vehicle to travel at speed because the driver knows it can still stop.
The same principle applies to AI.
Access control, traceability, data protection, isolation and red teaming are not obstacles added around the system after it has been built. They are the conditions that allow leadership to trust it beyond a controlled pilot.
A mature AI security architecture does not promise that the model will never make a mistake. It defines what the model may access, which actions it may perform, how its decisions can be reconstructed and how a failure will be contained when it occurs.
This is what separates a convincing demonstration from a production system. A demonstration shows what the technology can do when everything goes well. An architecture prepares for what happens when it does not.
The best moment to establish these boundaries is before the pilot becomes a dependency, before sensitive information begins to circulate and before employees create their own shortcuts around missing controls. Retrofitting security after adoption has already spread is slower, more expensive and considerably more disruptive.
Before asking whether an AI solution can be opened to the entire company tomorrow, organisations should ask a more useful question: would its architecture withstand a security audit today?
If the answer still depends on the model following instructions and behaving as expected, the organisation does not yet have a secure production system. It still has a pilot.
At Intech Heritage, we help organisations move beyond that fragile stage by designing AI systems with explicit boundaries, controlled access and evidence that can be examined when something goes wrong. The objective is not merely to deploy AI. It is to build an AI solution that deserves to be trusted.