The Enterprise AI Stack

Executive summary

The stack has a missing layer

Enterprise AI adoption is structurally ahead of enterprise AI governance. This is not a failure of intent. Most organisations made reasonable decisions with the tools available at the time; the governance infrastructure to manage those decisions has not yet caught up.

Closing that gap is not a matter of buying one more product. Modern AI security is a stack - model-native safety, AI gateways, data-security posture management, identity and access controls, and the security-operations functions that correlate it all. Each layer is real and worth having. This paper takes each seriously, and then asks a specific question none of them was designed to answer:

This is the domain of context governance, and it is worth defining precisely, because "context" carries a lot of weight in AI.

This paper is about one of those surfaces: the tool-and-action path, where an AI system reaches enterprise data and systems directly. It is the surface that has outrun every existing control, and the one an inline enforcement layer is positioned to hold. Three conclusions follow:

• The gap is architectural, not operational. Existing controls govern human users and known systems. The tool-and-action path is a non-human principal reaching runtime-assembled data over open interfaces. That is a different control surface, not a mis-set policy.
• Governance needs a third component. Written policy and an accountable committee describe governance; only an enforcement mechanism that runs inline, at the moment of interaction, performs it.
• This layer completes the stack; it does not replace it. It governs the tool-and-action surface, and it feeds evidence and signal - into your SIEM, your SOC, your audit record - that make the rest of the stack more effective.

Methodology: directional observations drawn from analysis of enterprise AI deployment patterns and structured interviews with technology, security and compliance leaders across financial services, professional services and technology. Where precise figures are not available, directional language is used deliberately. Regulatory statements reflect the position as at mid-2026 and are sourced in the References.

Ungoverned by default

Enterprise AI has followed the pattern of every prior wave of technology adoption: business units move faster than governance functions. Departments adopt tools that solve immediate problems; the productivity gains are visible, the governance risks diffuse and technically complex to articulate.

This is not recklessness. Organisations that adopted AI-assisted tools for legal review, financial analysis, code generation and customer operations were making reasonable decisions. The frameworks to govern them did not yet exist.

The sequencing problem is now visible. Enterprise deployments increasingly involve multiple concurrent AI systems, each independently connected to enterprise data, each governed by the policies of the vendor that built it. No unified inventory exists; no single policy layer spans the deployment. In our analysis, only a minority of organisations can produce a complete account of what data each AI system accessed, when, and on whose authority. In most cases the data was never captured - not withheld, simply never recorded at the moment of interaction.

Why restrictive policies fail

Bans on specific tools, blanket prohibitions and network-level blocking produce one consistent outcome: usage relocates to personal devices, consumer accounts and unmonitored networks. The data exposure continues; the audit trail does not. Several governance leaders described this directly - one blocked major AI services at the network level and watched usage shift to mobile within days; another discovered, by chance rather than monitoring, that a senior employee had been processing customer correspondence through a consumer assistant for months.

A programme built on the assumption that AI usage can be restricted will underinvest in the infrastructure required to govern usage that cannot be. The organisations most exposed are often those with a formal policy and no enforcement: the policy creates the appearance of governance while usage continues ungoverned.

The objective is not surveillance. It is safe enablement - employees using modern tools to do their work well, without unknowingly transmitting sensitive data to external models. Governance that depends on behavioural policing fails. Governance that operates at the architectural layer does not.

The governance triad

Three functions share accountability for AI governance:

• Cyber Security. Access control, threat modelling, monitoring. Sets technical risk tolerance.
• Data Protection / DPO. Classification, retention, lawful basis. Defines what data AI systems may process.
• Governance & Compliance. Policy frameworks, risk assessment, audit accountability. Documents governance decisions.

All three bear responsibility; none can operationalise policy without a mechanism that connects their decisions to model execution. The gap is not a collaboration deficit. It is an operational one.

The compliance horizon

The deadline moved, the work did not

The regulatory picture shifted in 2026, though not in the direction a casual reading suggests. In May 2026, EU lawmakers agreed the Digital Omnibus on AI, deferring the AI Act's high-risk obligations. "The EU delayed the AI Act" is half true and, for planning, dangerously imprecise. Some obligations moved; others are live now; and the part that takes longest to build - interaction-level audit evidence and data classification - does not get easier with time. Regulators have been explicit that the deferral is time to prepare, not permission to pause.

• High-risk obligations, reset to December 2027. Under the May 2026 Digital Omnibus, stand-alone Annex III high-risk systems (employment, creditworthiness, essential services) are deferred from August 2026 to 2 December 2027; product-embedded Annex I systems to 2 August 2028. The risk-based architecture is unchanged; the deferral reflects unfinished standards, not a softened obligation.
• Live now. Prohibited practices have applied since February 2025 and general-purpose AI obligations since August 2025. Article 50 transparency duties remain effective August 2026; a prohibition on non-consensual intimate imagery and CSAM, with content-marking duties, applies from December 2026.
• Standards and direction. ISO/IEC 42001:2023, the first certifiable AI management-system standard, is increasingly written into procurement. The UK applies a sector-led, principles-based approach through existing regulators; US activity advances at federal and state level. The common thread is documented accountability and evidence of governance.

Across every jurisdiction the immediate challenge is identical: most organisations cannot produce a complete, interaction-level record of what data each AI system accessed, when, under which policy, and on whose authority. That evidence exists only if it was captured at the moment of the interaction. It cannot be reconstructed afterwards - which is precisely why the extra months are preparation time, not slack.

A pipeline, not a model

An enterprise AI system is not a model answering a question. It is a pipeline that reaches into live business systems - retrieving records, calling tools, taking actions - and every reach is a governance decision made at runtime, by a non-human principal, on data assembled for that moment.

Two distinct exposures live in that pipeline, and it is worth separating them, because they belong to different controls.

The first is internal to retrieval: a retrieval pipeline assembling a model's context from a vector store, where document-level access rights do not always follow the embeddings derived from those documents. This is a real and serious exposure - and it is the natural territory of data-security posture management and retrieval-integrity tooling. It is adjacent to, and complementary with, the control this paper is about.

The second is the tool-and-action path - and it is the one that has outrun every existing control. Here a model, increasingly an autonomous agent, increasingly acting over open interfaces such as the Model Context Protocol, reaches enterprise data and systems directly: querying a CRM, reading a mailbox, moving a record, executing a task. The governed question is no longer only what did the model see. It becomes what is this agent permitted to do, acting as whom, with what authority - and what evidence exists that it did so within policy.

From answering to acting

The first wave of enterprise AI read data and returned text. The wave now arriving takes actions: agents plan multi-step tasks and call tools - sending email, updating CRM records, executing code, moving money - across systems.

This breaks two assumptions the user-and-application controls rely on. An agent does not act with a single user's permissions; it acts with a service credential usually broader than any individual's. And a sequence of individually permissible steps can combine into an outcome no one approved. Governing the prompt is insufficient once the model can act on the world. The tool-and-action path needs its own controls:

• Action governance. Every tool call evaluated against policy before execution, scoped to the initiating user's authority - not the agent's standing credential.
• Agent identity. Each action attributable to a named human principal and a policy version, so an autonomous step is never an anonymous one.
• Chained-plan risk. Governance evaluates the plan, not only the prompt: permitted steps that together breach policy are caught before the chain completes.

The tool path as an attack surface

The same path that carries enterprise data to a model can be turned against the enterprise. The OWASP Top 10 for LLM Applications catalogues these risks in full; three of them transit the tool-and-context path an inline layer is positioned to address directly, and one belongs to a neighbouring control - a distinction worth making, because precision about which risks a layer addresses is itself a governance property.

• Direct injection. Instructions crafted to defeat a system prompt. Judged on the way in, before the model acts; filtering the output is too late.
• Indirect injection. Hidden instructions inside content a model retrieves through a governed tool call, inspected before they reach the model.
• Data exfiltration. Privileged content steered into an output or an outbound tool call, classified before delivery so it cannot be echoed past the perimeter.
• Retrieval poisoning. Adversarial material seeded into a vector store. A real risk, and one that lives in the integrity of the store itself, alongside DSPM and data-quality controls. An inline layer complements that work; it does not replace it.

Every layer is real. One seam is unheld.

AI security is not a product; it is a stack. A mature enterprise already runs several of its layers, and each does genuine work. The purpose of this section is not to displace any of them - it is to locate the one control point they were not built to hold.

• Model-native safety and guardrails. Every major AI vendor now ships content filtering and behavioural guardrails. Within their platform these have real value - reducing harmful generations, enforcing the vendor's own use policies. What they cannot be is your policy, applied consistently across vendors, producing evidence you own. A rule set in one vendor's console has no effect on another's model. Model-native safety is the inside of a boundary; it is not the boundary itself.
• AI gateways and LLM firewalls. These manage the connection - routing, rate-limiting, prompt logging, edge inspection - and are increasingly table stakes. Their vantage point is the traffic: the request and response as data in flight. What they are not positioned to do is classify a specific payload against your organisation's data policy and decide, for that payload, what a model may receive. The gateway governs the pipe; context governance governs the content moving through it. The two compose naturally.
• DSPM and DLP. Data-security posture management and data-loss prevention find, classify and label sensitive data at rest and in motion, and increasingly reach into vector stores and retrieval pipelines. This is essential, complementary work - indeed it is where the retrieval-poisoning and embedding-access exposures above are best addressed. What these tools do not do is act inline, at the moment of inference, on the assembled context an agent is about to receive or the action it is about to take.
• CASB and IAM. Cloud access security brokers and identity management govern who may reach which application - the foundation the whole stack stands on, and nothing here replaces it. But once an authorised user invokes an AI agent, a second question opens that identity controls were never designed to answer: the agent acts with a service credential broader than the user's own, and a chain of permitted steps can combine into an unapproved outcome. Governing the user is necessary; it does not govern the agent's authority in the moment.
• SIEM, SOC and EDR. Security operations correlate signal from across the estate - and are only as good as the signal they receive. Today the AI interaction layer is largely dark to them: most SIEMs have no feed describing what data an AI system accessed, under which policy, on whose authority. This is not a shortcoming of the SIEM. It is a missing sensor.

The seam. Every layer above is real, and a serious programme should have most of them. What none was built to hold is the point between assembled context and model inference, and between agent intent and action - inline, per payload, against the organisation's own data policy, producing the organisation's own evidence. That is a specific, nameable control point. It is not a gap in any of these tools; it is a layer the stack has not yet grown.

The frameworks say what; they do not perform it

The mature governance frameworks are necessary and worth adopting - and, by design, none is a runtime control.

Each answers a real question. None answers the operational one: at the moment of interaction, who decides what this model is allowed to see and do, and where is that decision recorded?

Three components. Most programmes have two.

Enterprise AI governance is not a single discipline. It has three separately necessary components:

• Governance policy. Establishes what is and is not permitted; which data categories AI systems may process; retention and accountability standards. The standard against which enforcement executes.
• Governance committee. Convenes Cyber Security, Data Protection, and Governance & Compliance under a named board sponsor. Reviews deployments, approves policy, records decisions - the named accountability regulators require.
• Operational enforcement. Connects policy to model execution, inline, at the moment of interaction. Classifies context, applies policy, logs every interaction, generates evidence. This is the component most programmes lack.

Why the evidence must be the organisation's own

Governance ultimately has to be demonstrable - to a regulator, an auditor, a board. That places one structural requirement on the evidence: an organisation must be able to produce and verify it independently of the systems being governed. This is not a claim that any vendor is untrustworthy; it is the same principle the audit profession settled long ago - evidence you can only obtain, and only validate, through the party being assessed is weaker than evidence you hold and can check yourself.

Applied here: the record of what each model was permitted to see and do should be sovereign enterprise data - portable, complete, and producible to a regulator without depending on any model vendor's cooperation. Vendor compliance portals have genuine value for operating a vendor's platform; they are the vendor's account of the vendor's own behaviour. A defensible position wants both: the vendor's controls and an independent, organisation-owned evidence trail across all of them.

The Boundary control plane

Boundary, from Boundary Control Ltd, is an implementation of this enforcement layer. It operates inline on the path between AI assistants and agents and the enterprise tools they reach - today, over the Model Context Protocol - classifying and governing enterprise data at the point of interaction, and taking a tamper-evident record of every decision.

It is deliberately one layer of the stack. It does not replace identity controls, a DSPM programme, an AI gateway, or model vendors' native safety features - it composes with them. Its job is the tool-and-action seam none of them holds, and to strengthen the rest by feeding them evidence and signal they do not otherwise have.

How it governs: Boundary applies the organisation's data policy field by field.

• Tier 1, pass-through. Lowest-sensitivity data passes through unmodified; the model receives full context.
• Tier 2, referenced. Data is delivered as resolvable numbered references; authorised users resolve them via portal under governed conditions.
• Tier 3, withheld. Highest-sensitivity data is withheld from the model entirely.

Tier boundaries are defined by organisation policy, not by Boundary defaults.

What it covers, stated plainly: one policy across every assistant that connects through the layer, regardless of the underlying model or vendor. This is the layer's defining property: coverage is a function of routing, not of the model. The honest corollary: data that reaches a model outside that path is out of scope by construction. The clearest current instance is Microsoft 365 - an assistant retrieving data directly via the Graph API bypasses the layer today; this is a known limitation for large M365 estates and is being addressed. We name it because a layer precise about the seam it holds is worth more than one that implies it holds all of them.

Boundary as a signal source for your stack

An inline enforcement layer sees something no other control does: every AI-mediated data access and action, classified, with the policy decision attached. That makes it a natural sensor for the security stack you already run.

Boundary emits structured security events - a redaction enforced, a threat blocked, a tool call refused, a policy verdict - into the SIEM and SOC tooling an enterprise already operates. The AI interaction layer, previously dark to security operations, becomes a monitored surface: analysts correlate AI activity alongside the rest of the estate, and the governance committee's policy shows up as live signal rather than a document. Because the enforcement record and the audit evidence are the same substrate, what protects the enterprise in the moment also demonstrates its compliance after the fact.

This is the shape of a complementary layer: it does its own job at the seam, and it makes every adjacent tool - the SIEM, the SOC, the audit programme - more effective for having it there.

The governance maturity model

A vendor-neutral way to locate any organisation - measured not by the sophistication of its models, but by its ability to account for every interaction they perform.

• L0, Ungoverned. Usage occurring; no policy, no inventory, no record.
• L1, Policy. Written rules exist; nothing enforces them at the point of interaction.
• L2, Oversight. A committee, DPO classification and deployment review are in place; enforcement is manual or absent.
• L3, Application control. Access provisioned, use monitored, outputs reviewed. A necessary layer that every mature programme should have - and one that governs who uses AI, leaving what the AI is given, and permitted to do, still to be governed.
• L4, Context and action governance. Inline classification and policy enforcement on the assembled context and on tool calls, across every connected model, producing complete, sovereign evidence and feeding it to the wider stack.

Each level builds on the last; none makes the previous one redundant. The step most organisations have not yet taken is from oversight and application control to inline enforcement - the point at which policy stops describing governance and starts performing it.

Deployment

1. Phase 1, connect and discover (days 1-7). Integrate to existing AI endpoints; discover the AI environment; configure data connectors; establish baseline interaction data.
2. Phase 2, configure and baseline (days 8-30). Translate governance policy to enforcement rules; configure data-tier classification; generate initial audit records; review the anomaly baseline.
3. Phase 3, full governance (days 31-90). All enforcement functions active; continuous compliance reporting; real-time anomaly detection; governance reporting to the board.

An inline enforcement layer without a governance committee, a data-classification policy and named accountability is a technical tool in a governance vacuum. The layer completes the framework; it does not substitute for it.

Conclusion

The governed enterprise

A governance-ready AI environment is not defined by the sophistication of its models. It is defined by its ability to account for every interaction those models perform.

That accountability rests on three components working together: named organisational accountability with a committee and board sponsor; documented policy applied at the interaction level; and operational enforcement that executes that policy inline. The first two describe what governance requires. The third determines whether governance is real or aspirational.

None of this asks an organisation to dismantle the controls it already runs. It asks it to add the one layer the stack has not yet grown - the layer that governs what AI systems reach and do at the moment of interaction, and that feeds the evidence and signal the rest of the stack has been missing.

References and further reading

Sources

Dates reflect the position as at mid-2026; the EU timeline incorporates the May 2026 Digital Omnibus political agreement, which remained subject to formal adoption at the time of writing.

1. Regulation (EU) 2024/1689. The EU Artificial Intelligence Act. Risk-based obligations and a staggered application timeline.
2. Digital Omnibus on AI. Council and Parliament political agreement, May 2026. Defers Annex III high-risk obligations to 2 December 2027 and Annex I to 2 August 2028; adds the prohibition on non-consensual intimate imagery and CSAM.
3. ISO/IEC 42001:2023. Information technology, artificial intelligence, management system. The first certifiable AI management-system standard.
4. NIST AI Risk Management Framework (AI RMF 1.0). A voluntary framework structured around Govern, Map, Measure and Manage.
5. OWASP Top 10 for LLM Applications. The reference threat taxonomy for large-language-model systems.
6. UK AI regulation. The sector-led, principles-based approach administered through existing regulators.

This document is provided for information only and does not constitute legal advice.