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
Can we rely on instructing the model not to reveal certain data?
No. That is a request rather than a control, it fails silently, and it cannot be demonstrated. Anything the model can retrieve should be assumed reachable, so the restriction has to prevent retrieval rather than discourage disclosure.
Does personal data have to be redacted before reaching a model?
It depends on the task and your obligations. Where the work does not need the identifier, removing or tokenising it reduces exposure at no cost to quality. Where it genuinely does, the controls are contractual and architectural rather than a matter of redaction.
How do we prove a boundary holds?
Attempt a violation and show the refusal, then show it in the log. That is far stronger evidence than a description of the design, and it is what an auditor tends to ask for.
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.