Why AI security starts at the architecture level
Confidential computing and zero-trust are design decisions, not afterthoughts.
Security has always had a timing problem in software projects. The architecture gets designed, the build gets scoped, and security considerations get added somewhere in the middle or more often, reviewed at the end. That pattern was always less than ideal. In AI-driven projects, it's a serious liability.
The reason is that AI applications introduce a different kind of attack surface from conventional software, and that surface is shaped by decisions made early in the project: how data flows between services, how model inference is structured, how agents are given access to systems, and how outputs are consumed downstream. By the time a security review happens at the end of a project, most of those decisions are already baked in. Retrofitting security controls onto an architecture that wasn't designed with them in mind is expensive, incomplete, and often requires rework that could have been avoided entirely.
Preemptive security, designing confidentiality, integrity, and trust into the architecture from the start is how well-run AI projects handle this. Two frameworks in particular are worth understanding in depth: confidential computing and zero-trust architecture. Neither is new, but both take on renewed relevance when applied to the specific characteristics of interconnected AI systems.
Before getting into the frameworks, it's worth being precise about what makes AI-driven applications different from a security standpoint.
The first issue is data exposure at inference time. A conventional application processes data in well-defined, relatively contained ways. An AI system, particularly one using large models or agents often requires sensitive data to be passed into inference pipelines where it's processed in ways that are harder to audit, harder to constrain, and harder to predict. That data may include customer records, internal financial information, proprietary operational data, or personal health information, depending on the application. The question of where that data goes, who can see it, and what happens to it during processing is often much less clear in AI systems than in conventional ones.
The second issue is the interconnected, multi-agent nature of modern AI architectures. An agent-based system might involve an orchestration layer calling several specialised models, which in turn call external APIs, write to databases, and trigger downstream workflows. Each one of those connections is a potential vector. In a tightly integrated system where agents have broad permissions to read and write across services, a compromise at any one point can propagate quickly. The blast radius of a security failure is larger than in more isolated systems.
The third issue is that AI systems are also susceptible to a class of attacks that conventional software isn't: prompt injection, data poisoning, adversarial inputs designed to manipulate model behaviour, and indirect prompt injection through content that a model retrieves and processes. These aren't hypothetical threats. They're already being exploited against production systems, and most security frameworks developed before the current wave of AI adoption don't address them adequately.
Most security thinking focuses on data at rest, encrypted in storage, and data in transit encrypted in transit. Confidential computing addresses the third state: data in use, while it's being processed.
The core idea is hardware-based isolation. Trusted Execution Environments (TEEs), available through technologies such as Intel TDX, AMD SEV, and ARM TrustZone, create isolated enclaves within a processor where code and data can be processed without being accessible to the host operating system, hypervisor, or cloud provider. Even a cloud infrastructure provider with physical access to the underlying hardware cannot read what's happening inside a confidential compute enclave.
For AI systems handling sensitive data, this matters in several concrete ways. An organisation running model inference on patient data, financial records, or proprietary business information can use confidential computing to ensure that data is only ever processed in a protected environment, not exposed to the broader cloud infrastructure during the inference step. The model weights themselves can also be protected, which matters for organisations that have invested significantly in training proprietary models and don't want those weights exposed even to infrastructure providers.
The practical challenge with confidential computing is that it adds complexity to the infrastructure design and has performance implications that need to be accounted for in the architecture. It's also not a universal solution: TEEs protect the compute environment, but they don't automatically address every other vector in the attack surface. The right way to think about confidential computing is as one layer of a broader security architecture, particularly relevant for the inference and data processing components of an AI system rather than as a standalone answer.
Zero-trust architecture starts from a different premise to the traditional network security model. The traditional model draws a perimeter firewall, VPN, network boundary, and assumes that anything inside the perimeter is trusted. Zero-trust assumes that no part of the network is inherently trusted, that credentials can be compromised, and that lateral movement inside a network is a realistic attack path that needs to be constrained.
In practice, zero-trust means enforcing identity verification and least-privilege access at every layer, not just at the entry point. Every service, agent, and user must authenticate before accessing any resource. Every connection is validated continuously, not just at session initiation. Access is scoped as narrowly as possible to what's actually needed for a given task, an agent that needs to read from one database does not get credentials that allow it to write to ten others.
For AI-driven projects, zero-trust is particularly well-suited to the multi-agent, interconnected architecture that most modern AI systems use. An orchestration layer that coordinates multiple agents, each calling different services, is exactly the kind of environment where broad, implicit permissions create serious risk. If one agent in that chain is compromised through prompt injection, a vulnerable dependency, or a misconfigured API, the damage it can do is determined largely by what permissions it holds. Under a zero-trust model, those permissions are minimal by design. The agent can only access what it needs for its specific function, and nothing more.
This also applies to the model itself. An AI system that can take actions on behalf of users, reading emails, writing to databases, calling external APIs should operate under the same least-privilege principle as any other service in the stack. Giving an agent broad access because it's convenient to configure is one of the more common security mistakes in current AI deployments.
Confidential computing and zero-trust address different parts of the same problem, and they work better together than either does in isolation.
Zero-trust controls who and what can access a system, and ensures that access is always the minimum necessary. Confidential computing protects what happens to the data once it's inside the processing environment. A system that implements zero-trust but not confidential computing has strong access controls but no guarantee of what happens to sensitive data during inference. A system that uses confidential computing but doesn't apply zero-trust principles has protected compute enclaves that are potentially reachable by too many services and agents with too many permissions.
The point of integration between them is at the architecture design stage. When you're deciding how agents will authenticate to services, what data they'll handle during inference, how outputs will flow downstream, and how the system will behave when a component is compromised — those decisions determine both the zero-trust policy and where confidential computing is warranted. Getting both right requires thinking about them together, during the design phase, rather than as separate security concerns addressed at different times.
The practical implication for project teams is that security architecture needs to be part of the initial design conversation, not a review checkpoint at the end. That means a few specific things.
During architecture design, the conversation should include explicit questions about data classification: what data will flow through the AI system, how sensitive it is, and what the implications of that data being exposed would be. The answers to those questions drive decisions about where confidential computing is warranted, how inference pipelines should be structured, and what audit and logging requirements apply. This isn't a separate security exercise, it's part of the same conversation as the functional architecture.
Permission design for agents and services should be done before implementation, not during. The common pattern of starting with broad permissions and tightening them later is the wrong approach for AI systems, because broad permissions tend to become load-bearing, services and agents build dependencies on them, and removing them later creates friction. Starting from least-privilege and expanding only when there's a specific, justified reason is far easier to do at the start than to retrofit.
Threat modelling, thinking through the specific attack vectors relevant to an AI system, including prompt injection, indirect injection through retrieved content, and model output manipulation should happen during design. This is particularly important for agentic systems where the attack surface is larger and less well-understood than in conventional software. There are now established frameworks for AI-specific threat modelling, and using them early in the project produces better outcomes than discovering the attack surface during a security review at the end.
None of this requires a team of security specialists embedded in every AI project. It requires security thinking to be part of the culture of how AI systems get designed treated as a design constraint from day one, in the same way that scalability or performance are. Teams that build that habit produce systems that are more secure and less expensive to maintain than those that treat security as a late-stage review.
If you're building or scaling an AI-driven application and want to think through the security architecture early, we're happy to have that conversation. Reach out to explore how these frameworks apply to your specific context.
