Direct answer
Enforce the boundary below the agent, never inside it. The systems being called apply their own row-level and per-tenant rules, so a request for data the principal cannot see is refused regardless of what the agent asked. Retrieval is scoped per query, and what may leave the boundary is restricted separately.
AI data boundary
The enforced limit on which data an agent can retrieve and where that data may travel. It is applied by the systems holding the data and by egress controls, rather than by instructions given to the model.
The shared-account failure
The most common design gives the agent one service account with broad rights and trusts the application to restrict itself. It works on day one and means the underlying system cannot tell whose authority a request carries. The failure surfaces as a disclosure rather than an error: context assembled for one customer using another's data.
What to enforce, and where
Each control sits outside the model, so an agent exploring a space a human would not meets a refusal.
Identity per call
The request carries the principal it acts for, and permissions are applied to that principal.
Row and tenant scoping
Enforced in the data layer, so a query cannot cross a boundary even if it is malformed.
Scoped retrieval
Search indexes are filtered by permission at query time rather than after results return.
Field-level handling
Personal data is redacted or tokenised before it reaches a model where that is sufficient for the task.
Egress control
Where the agent may send data is restricted, so exfiltration has nowhere to go.
Recorded refusals
A refused read is logged, which is how a boundary demonstrates that it works.
Retrieval is where boundaries usually leak
A vector index built from documents across several permission domains will happily return a passage the requester cannot see, because similarity does not know about access. Filter at query time using the requester's permissions, or partition the index. Filtering after retrieval means the restricted content has already entered the context.
The Propose–Decide–Execute pattern
CodeDTX builds agentic systems on the Propose–Decide–Execute pattern: agents may only write proposals with evidence attached, a named human records an approval or rejection with a reason, and a separate execution layer carries out approved work and logs the artifact. No agent holds a write tool to the outside world.
- 01
Propose
The agent analyses live system state and drafts a change, with the evidence it relied on attached to the proposal.
- 02
Decide
A named human approves, edits, or rejects with a reason. Risk tier determines who is allowed to decide.
- 03
Execute
A separate execution layer performs approved work - merge, publish, call, write - and records the resulting artifact.
- 04
Audit
Actor, reason, evidence, artifact, tokens, and cost are retained for every run, so any decision can be reconstructed later.
The six layers we build and review against
- 1
Agent layer
Agent architecture, tool use, memory and context, multi-agent patterns, structured outputs, orchestration.
- 2
Integration layer
MCP servers, tool contracts, API and database adapters, authentication, permissions, legacy system access.
- 3
Knowledge layer
Retrieval and RAG, vector and search architecture, enterprise knowledge sources, data access controls.
- 4
Reliability layer
Evals, tracing, observability, cost and latency budgets, fallbacks, regression tests.
- 5
Safety layer
Guardrails, prompt-injection defense, PII and data boundaries, human-in-the-loop gates, audit trails.
- 6
Product layer
The application people actually use: interfaces, approval queues, and operational runbooks.
Frequently asked
Have a workflow that should become AI-enabled?
Tell us about the system it lives in. We reply from an engineering seat, not a sales deck.