.png)
Sometimes it feels like every new technology arrives with a pile of new security categories. With AI, we have an avalanche.
AI-SPM. AI gateways. AI firewalls. MCP gateways. Agent runtime controls. RAG security. AI DLP. Agentic red-teaming. Vector database security. Model scanning and governance. Prompt security. AI posture management. Just to name a few.
Some of these categories are useful. Some are old controls with new labels. Some are genuinely new enforcement points because AI workflows create new places where trust can fail.
The problem is when categories become a substitute for architecture. Product categories reflect how vendors package and sell capabilities. They do not necessarily reflect how an enterprise system is designed, where its trust changes state, or where security policy needs to be enforced.
If security teams end up evaluating controls by vendor definition instead of enterprise need, the conversation turns into “Do we need an AI firewall?” or “Do we need an MCP gateway?” before the organization has answered the more important question: which trust boundary are we trying to enforce, and what failure are we trying to prevent?
For CISOs, the job is not to collect every AI-labeled control and hope the combination adds up to security. The job is to understand where untrusted content crosses into trusted AI workflows, where authority is assigned, where identity is bound, and where model output is allowed to create enterprise consequence.
That is the point of a trust-boundary model. It moves the discussion away from product categories and toward the places where the system can actually fail.
In earlier pieces, I framed prompt injection, context poisoning, and agentic AI failures as boundary problems. A model may be exposed to malicious or low-trust content, but exposure alone is not always the damaging event. Harm occurs when that content gains authority it should not have: when it overrides instructions, corrupts knowledge, changes retrieval, persists into memory, or causes a tool to act.
To be useful, trust boundaries cannot stay conceptual. They have to map to controls people can understand, fund, operate, and govern.
The work is to understand which boundary each control helps enforce. Vendor categories will keep changing, but the architectural functions underneath them change much more slowly. The labels may be temporary. The enforcement points are not.
What Trust Boundaries Mean in AI
A trust boundary is the point where content, identity, authority, or action changes trust state.
In traditional architecture, we are used to drawing trust boundaries around networks, applications, identities, data stores, administrative privileges, endpoints, and third-party services. Those boundaries still matter. AI does not make them obsolete.
Traditional controls still matter because many of them enforce authority outside the model, which is exactly where AI failures need to be contained. But they must now be applied not only at network edges, login screens, and data stores, but also at the moments inside an AI workflow where trust changes state.
AI systems assemble instructions, user input, retrieved documents, tool results, memory, system guidance, and messages from other agents into a workflow that can produce both answers and actions. Content with very different levels of authority may appear together, even though it should not be treated as equally trustworthy.
In AI systems, the boundary is not only the network edge, the SaaS login, or the database permission. The boundary may be the moment a document becomes retrieved context. It may be the moment a user preference becomes durable memory. It may be the moment model output becomes a tool call. It may be the moment an agent acts with a credential that is broader than the user's actual authority.
For an executive architecture conversation, five AI trust boundaries provide a practical way to organize where control needs to hold.
The instruction boundary fails when lower-trust content is allowed to compete with or override higher-authority system, developer, or enterprise instructions.
The knowledge integrity boundary fails when compromised, stale, unauthorized, duplicated, or low-authority material is accepted as trusted enterprise knowledge.
The retrieval boundary fails when the AI system retrieves the wrong content, retrieves content the user is not authorized to access, or treats semantic relevance as if it were authority.
The memory and persistence boundary fails when temporary, personal, or low-authority content becomes durable memory and later influences answers or actions.
The tool invocation boundary fails when model output is allowed to trigger downstream action without sufficient authorization, validation, isolation, or approval.
Identity runs across all five boundaries. Security teams need to know not only who asked the question, but which application, workload, agent, tool, credential, delegated scope, and downstream system participated in the action. If those identities collapse into an over broad connector or generic privileged account, the enterprise loses control of the boundary even when the user experience appears seamless.
The product label is secondary. The architectural question is which trust boundary has to hold, and what failure the control is meant to prevent.
Contamination and Consequence
One reason AI security conversations get muddled is that they mix two different control objectives.
Some controls reduce the chance that bad content enters the workflow. These are contamination controls. Other controls limit what happens when bad content gets through. These are consequence controls.
Both matter. They are not substitutes.
Contamination controls reduce the likelihood that malicious, unauthorized, stale, or low-trust content will influence the workflow. Examples include source validation, permission-aware retrieval, context minimization, input inspection, data controls, and restrictions on what may be written to memory.
But no serious architecture should assume contamination controls will be perfect. Prompt injection and related influence attacks cannot currently be treated as a completely preventable input problem. Mitigations reduce risk; they do not eliminate it. (OWASP Gen AI Security Project)
That is why consequence controls matter.
Consequence controls limit what the system can do when the model is manipulated, confused, or simply wrong. They include least privilege, deterministic authorization, scoped credentials, constrained tool access, validation, isolation, approval requirements, transaction limits, and the ability to interrupt or terminate activity.
Their defining feature is that they do not depend on the model to recognize its own mistake. They enforce policy outside the model.
A prompt inspection tool may help detect an injection attempt. A retrieval control may reduce the likelihood that poisoned content enters the context. A memory control may prevent a bad statement from becoming durable. The decisive control is often downstream, at the point where model output is translated into enterprise action. The tool cannot send the email, delete the data, merge the code, move the money, expose the record, or call the internal API unless a deterministic policy says it can.
From Product Categories to Control Functions
Vendor categories can be unstable because vendors combine capabilities differently. Architectural control functions are more durable.
An “AI gateway,” “AI firewall,” “MCP gateway,” or “agent runtime control” is not useful merely because it belongs to a named category. It is useful when it creates visibility, preserves authority, or enforces policy at a trust boundary. The right question is not what the product is called, but what it can observe, what it can control, where it sits in the architecture, and what happens when it fails.
AI gateways create a centralized control point between applications and models or model providers. Depending on the implementation, they may govern model access, credentials, routing, data movement, usage, telemetry, and policy enforcement.
Some gateways enforce meaningful policy; others primarily route traffic and collect logs. The architecture question is whether the gateway can see and control the relevant flow, including the context and identity needed to make an enforceable decision. A control point that cannot enforce policy is an observation point.
AI inspection and guardrail layers classify, filter, redact, block, log, or route AI inputs and outputs according to policy. They may inspect prompts, retrieved content, responses, files, generated code, or tool-call arguments.
These controls can reduce contamination, detect known patterns, and interrupt obvious policy violations. They should not be treated as proof that malicious content cannot influence a model. Their architectural value depends on what they can inspect, where they are placed, and whether the policy decision is enforced or merely reported.
OWASP’s LLM Top 10 reinforces the same architectural point: prompt injection, sensitive information disclosure, improper output handling, excessive agency, and vector and embedding weaknesses are distinct risks, not problems a single inspection layer can eliminate. Inspection can reduce risk, but it should not become the architecture’s only answer to model influence or downstream agency. (OWASP Gen AI Security Project)
MCP (Model Context Protocol) and tool gateways mediate connections between AI applications and external tools, data sources, and workflows. Their architectural purpose is to prevent tool discovery and invocation from becoming uncontrolled enterprise authority.
A meaningful control point should govern which tools are approved, how credentials are issued and scoped, which identities are represented, what actions are permitted, where execution occurs, and what evidence is retained. Routing MCP traffic is not enough. A gateway that cannot enforce policy between the agent and the tool is a pass-through, not a security boundary.
Whether that function is bundled into a broader gateway or deployed separately is a packaging question. The architectural question is whether enforcement exists at the boundary between the agent and the tool.
Data and knowledge governance controls determine what may become trusted enterprise knowledge and how that knowledge is maintained over time. They govern source approval, ingestion and indexing integrity, modification rights, access-control metadata, provenance, and the knowledge lifecycle, including freshness, duplication, retention, and retirement. They should also protect against poisoned or manipulated source material and preserve permissions and provenance throughout the knowledge lifecycle.
Agent runtime and harness controls govern the execution and policy-enforcement logic around the model: how context is assembled, which instructions are applied, how enterprise knowledge is accessed, when memory is read or written, which tools are available, and what happens to model output.
In agentic architectures, the runtime is often a query-time enforcement point for knowledge access. It should preserve both user and agent identity, carry delegated authority where appropriate, ensure that source permissions and query scope are enforced, and make access decisions auditable.
Context admission should be governed jointly by runtime controls—whether embedded or external—and the application harness. Runtime controls determine whether returned content may proceed; the harness determines how approved content is used in context. Together, they should preserve provenance, scope, and authority from context assembly through enterprise action, rather than leave the model to decide what deserves trust.
Data protection, endpoint, network, and egress controls continue to limit where sensitive information can move, where AI components may run, and which systems or destinations AI workflows may reach. They may not understand instruction hierarchy or context-window authority, but they still provide essential containment.
The architectural requirement is placement. Sensitive data can now move through prompts, retrieval, embeddings, memory, generated files, tool arguments, logs, browsers, local agents, coding assistants, and external model services. Existing controls must be positioned to see those paths and enforce policy at the points where trust changes state.
Logging, monitoring, and detection provide evidence across the workflow. A useful AI investigation cannot rely only on final output. It needs traces across prompts, retrieved sources, model calls, memory writes, tool calls, identities, policy decisions, and downstream actions.
The trace should explain how an AI-generated action acquired its authority, not merely record what the model said.
Identity and AI Controls
Agentic AI turns identity ambiguity into an architectural risk. When software can interpret goals, retrieve information, select tools, and act across systems, the enterprise must preserve who initiated the activity, which agent acted, what authority was delegated, which credential was used, and what system accepted the action.
The dangerous pattern is not hard to recognize. A user asks a question, but the AI application retrieves data through a service account that can see far more than the user. An agent summarizes email, but the connected tool also has permission to send messages or delete them. A workflow acts on behalf of one employee, but it queries a document repository using a privileged identity that can access everyone's files. The user experience looks simple, but the authority chain underneath it is wrong.
In each failure, the agent’s effective authority became the union of everything it could reach. It should be the intersection: what the agent is allowed to do and what the requesting user is allowed to do. The union is how a connector quietly erases the user’s boundary.
OWASP's excessive agency guidance describes this class of issue in terms of excessive functionality, excessive permissions, and excessive autonomy. (OWASP Gen AI Security Project)
The CISO translation is simple: the model should not be the authorization layer. Authorization needs to be deterministic, enforceable, and logged, and it needs to survive a bad prompt, a poisoned document, or a compromised tool response.
The encouraging news: this does not require enterprises to wait for an entirely new identity stack. Standards work across the IETF, the OpenID Foundation, and NIST is moving quickly, and the direction is consistent even where the details are still unsettled. Give the agent its own workload identity, carry the user’s authority through scoped delegation, and preserve both in the audit trail. Cross-domain agent identity is not solved, but the core pattern is enforceable with what many enterprises already own.
A well-formed delegated credential can answer four questions: who delegated, which agent acted, against what system, with what permission. If a credential in your AI workflow cannot answer those, the boundary is not enforced. It is assumed.
For any high-consequence workflow, the identity model should have a plain-English answer: which agent performed which action, using whose authority, against which system, with what scope, and leaving what audit trail.
When the answer cannot be stated clearly, the identity boundary is not ready.
Architecture: Where Trust Changes State
The architecture diagram below maps the trust boundaries to the places where control has to hold. It is not meant to create another taxonomy. Its value is that it keeps the conversation anchored in architecture: a control earns its place when it preserves authority, enforces policy, or limits consequence at the point where trust changes state.
AI security will not be solved by chasing every new product category.
Vendors will continue to create categories because markets reward differentiation. Architects will continue to build systems from a smaller and more durable set of control functions: identity, authorization, isolation, validation, data governance, observability, and policy enforcement.
Don’t start with the product category. Start with the boundary.
When untrusted content enters, preserve authority. When enterprise knowledge is retrieved, preserve provenance and permission. When memory is written, preserve scope. When identity is delegated, preserve attribution and accountability. When output becomes action, enforce policy outside the model.
The higher the consequence, the less the enterprise can afford to rely on model judgment alone.
In AI systems, meaningful control is architectural: it is placed at the boundaries where trust changes state and where contamination can become enterprise consequence.
Keep exploring AI architecture.
Trust boundaries are one lens for thinking about how AI systems should be designed and secured. For a broader look at building and securing AI architecture in the enterprise, check out Noma’s AI Architecture Webinar.
