Running AI Agents on Customer Data Without Leaving Your Boundary: Architecture Patterns

To run AI agents on customer data safely, keep the model, the tools and the data inside infrastructure you control or contractually cover. Give each agent least-privilege tool access, mask personal data before it reaches the model, require human approval for every write or activation, and log each action with the actor, model version and inputs hash. This article shows how, for a customer data platform (CDP).

Who this is for: CTOs, architects, CISOs, DPOs and marketing-operations leads in banks, healthcare, iGaming, government and other regulated sectors who are being asked to "add agents" to the stack. You will get an architecture, a risk table, the regulatory touchpoints and a 15-point checklist. This page belongs to the AI hub.

What "AI agent" means in this article

Anthropic separates workflows, in which LLMs and tools follow predefined code paths, from agents, in which LLMs "dynamically direct their own processes and tool usage" 1. Here, an agent is the second kind plus approvals: a tool-using LLM loop with approvals. The model proposes a step, a runtime executes a tool your code has exposed, the result returns to the model's context, and the loop repeats until the task ends or a gate stops it.

Three consequences follow.

• The model's context is a data path. Whatever a tool returns goes wherever the model runs.
• The tool list is the permission system. The agent can do what its tools allow, provided the tools enforce it.
• The approval gate is the deterministic control. Everything the model does is probabilistic, so anything that must not happen needs a rule outside the model.

Anthropic advises finding the simplest solution possible and notes that single LLM calls with retrieval are often enough 1. Much marketing-operations work (nightly QA, report summaries) is a workflow with an LLM step. Use a loop only where the path cannot be written down in advance.

The data-exposure problem with SaaS-hosted agents

Agents multiply the places where customer data is copied into model context. Five exposure paths matter in practice.

1. Context transfer. Everything a tool retrieves and places in a prompt leaves your environment if a third party hosts the model. Amperity's MCP documentation says tool results may contain PII and tells customers to confirm their AI client is approved to handle it 15.
2. Provider-side processing and retention. Contract-covered endpoints still process data. Microsoft's Azure documentation says prompts and completions are not shared with other customers or used to train foundation models, yet it also describes abuse monitoring: samples can be selected for review, with human review where flagged, unless the customer is approved for modified abuse monitoring 5. Read your plan's terms rather than assuming zero retention.
3. Processing location. On Azure, "Global" and "DataZone" deployment types may process prompts outside the resource's geography (within the zone for DataZone), while data at rest stays in the designated geography 5.
4. Injection-driven exfiltration. Simon Willison's "lethal trifecta" describes an agent that combines access to private data, exposure to untrusted content, and a way to communicate externally; such an agent can be tricked into leaking data 4. OWASP lists prompt injection first and excessive agency sixth in its 2025 top ten for LLM applications 23. Klaviyo's MCP documentation warns that tools reading user-generated content (profiles, events, reviews) return text the model could interpret as instructions, and tells users to review each tool call 12.
5. Connector bugs. Agent connectors are new code. Asana's MCP server launched on 1 May 2025; the company found a flaw on 4 June that could have exposed information from one customer's domain to other MCP users, and took the feature offline from 5 to 17 June; no indication of exploitation was reported 34.

When a hosted agent is the right answer. Not every task needs private inference. Hosted agents are reasonable when the data is aggregated or non-personal (Braze's MCP tools cover aggregated analytics, custom attributes and segments, and do not return data from user profiles 13), when you have read the vendor's business associate or data processing agreement, when volume is low, and when you cannot staff GPU operations. AWS lists Amazon Bedrock as HIPAA eligible, subject to a business associate agreement 67. The useful question is "what crosses which boundary, under which contract". For personal-data-heavy work in regulated industries, keeping inference and tool execution inside your boundary removes whole categories of review: transfer assessments, sub-processor changes and provider retention terms.

Seven architecture patterns for agents inside your boundary

"Inside your boundary" means the network and legal perimeter in which you hold the keys, logs and processors. Terms used here:

• On-premise: hardware you operate in your own or a colocation data centre.
• Private cloud: a single-tenant environment, often a VPC in your own AWS, Azure, GCP or OCI account.
• Self-hosted: you operate the software, wherever it runs.
• Customer-owned: you hold the keys, the data and operational control.
• Sovereign: deployment constrained to a jurisdiction and to operators under its law.

1. Place the model deliberately

Choose among three placements, per data class rather than per application.

• Private inference on your own GPUs with an open-weight model; see on-premise LLM deployment.
• A contract-covered endpoint in your cloud account, such as Bedrock with PrivateLink 7 or an Azure DataZone deployment 5.
• A public API under a data processing agreement, for non-personal data only.

Put a gateway in front of the endpoints that enforces which data classes may reach which model. Under GDPR Article 28 the processor must act on documented instructions, keep personnel under confidentiality, delete or return data at the end of the service and allow audits 23.

2. Expose data through least-privilege tool servers

Agents should reach customer data only through narrow tools, never through database credentials. OWASP's guidance on excessive agency names three root causes (excessive functionality, permissions and autonomy) and recommends minimal extensions, no open-ended tools such as shell or URL fetch, read-only scopes where possible, acting as the individual user, human approval for high-impact actions, and authorization enforced downstream rather than by the model 3. MCP's security guidance agrees on scopes: start minimal, elevate incrementally, avoid wildcards 9.

Vendors already do some of this. Salesforce ships separate standard servers for reads, mutations and deletes, disabled by default, with field-level security and sharing rules applied to every call 1011. Klaviyo offers a read-only=true option on its remote server 12. Mirror the pattern: one tool server per risk tier (read, draft, execute), each with its own credentials and approval policy. The protocol itself is covered in What Is MCP.

3. Minimize and mask personal data before the model sees it

GDPR Article 25 requires that, by default, only the personal data necessary for each specific purpose is processed, and names pseudonymization as an example measure 21. In an agent, that translates into six rules.

• Aggregate first. Tools return counts, distributions and segment IDs rather than rows.
• Mask at the tool layer. The model receives tokens such as cust_8f3a and [MASKED], never raw direct identifiers.
• Tokenize deterministically so the agent can join records without seeing values; re-identify only in the execution layer, after approval.
• Apply minimum group sizes to any slice.
• Exclude special-category and payment-card fields from agent-visible schemas.
• Redact free text (notes, transcripts), which carries incidental identifiers and injection payloads.

An instruction in the prompt to "ignore the email column" is not masking.

4. Gate every write and activation with approval

Write tools should produce a proposal (diff, affected audience count, channels, schedule), a named human approves it in a separate interface, and an execution service with its own credentials performs it. The MCP specification says there should always be a human in the loop with the ability to deny tool invocations 8. The pattern is visible across vendors: Tealium's Configuration MCP stages AI-generated changes as drafts and never publishes them, so a person publishes in the Tealium interface 14; Braze recommends not using auto-mode 13; Salesforce runs each MCP transaction as the authenticated user, so the audit trail shows that person's name 10. Add thresholds: larger or sensitive audiences need two approvers, approvals expire, and executions carry idempotency keys.

5. Record every action in an audit ledger

Log one record per agent action, written outside the agent's own permissions, with:

• actor: the human principal, the agent identity and the runtime;
• tool name and version, plus parameters and result stored as hashes with the payload in a protected store;
• model name and version, or the weights hash or endpoint version;
• prompt template version and the inputs hash, a hash of the exact context assembled for the call;
• policy version, approval ID, approver and outcome.

Make the ledger append-only (hash-chained or write-once storage) and hold pseudonymous references rather than raw personal data, so erasure requests do not break its integrity. It lets you answer a regulator, auditor or data subject later; see Explainable AI for Customer Decisions. PrivyCDP records every AI-assisted action in an append-only audit ledger; the pattern is implementable on any platform.

6. Evaluate and red-team before and after every change

Anthropic recommends extensive testing in sandboxed environments with appropriate guardrails, because agent autonomy brings higher costs and compounding errors 1. A working programme has five parts:

• Task golden sets with expected tool calls and outputs.
• An injection corpus: poisoned profile fields, event payloads, review text and tool descriptions, including the trifecta combination.
• Permission tests that attempt out-of-scope calls.
• Regression runs on any change of model, prompt or tool schema, and when a vendor server changes its tool descriptions. Invariant Labs describes "rug pull" attacks in which a server alters a tool description after approval 35.
• Shadow mode, where the agent proposes and humans act, plus tracked metrics: tool-call accuracy, false-approval rate, escaped errors.

7. Build a kill switch and drill it

A kill switch needs central revocation of agent tokens, a flag that disables each tool server, a freeze on the execution queue and scheduled runs, and a rollback path for recent approvals. The EU AI Act describes, for high-risk systems, a "stop" button or similar procedure that brings the system to a safe halt 27; it is a sensible target for any agent. Drill it quarterly and record the time to stop.

Agent tasks by risk and the controls each needs

The ceiling column is the point of the table: raising a task's autonomy is a decision with an owner, not a configuration change. The roadmap describes the sequence in which teams earn that trust.

The market reality: agent washing, cancellations and the MCP wave

Gartner predicted on 25 June 2025 that over 40% of agentic AI projects will be cancelled by the end of 2027 because of escalating costs, unclear business value or inadequate risk controls. It also described "agent washing", the rebranding of assistants, robotic process automation and chatbots without substantial agentic capability, and estimated that only about 130 of the thousands of agentic AI vendors are real 16. Its 2026 Hype Cycle for Agentic AI puts the technology at the Peak of Inflated Expectations: a 2026 Gartner CIO survey found 17% of organizations had deployed AI agents and more than 60% expected to within two years, while fully autonomous agents are not ready for most enterprise use cases 17.

Spending is real regardless: Salesforce reported Agentforce and Data 360 annual recurring revenue of nearly $3.9 billion for its quarter ended 31 July 2026, and widened its separate Agentforce ARR definition that quarter 18. Treat such figures as vendor-defined.

One caution applies to all of them. A vendor's MCP server inherits the user's permissions, which is good, but it does not decide where the model runs; the AI client the user connects does. Amperity says handling of data after it reaches the AI application is the customer's responsibility 37. An "agentic AI customer data platform" is only as private as the model placement you choose in pattern 1.

EU AI Act and GDPR Article 22 touchpoints

Dates and details are in the EU AI Act guide and the deadline tracker; a policy your team can adopt is in the AI governance policy template.

A 15-point controls checklist

1. Inventory every agent: owner, purpose, data classes, tools, model endpoint.
2. Classify data and decide, per class, which model endpoints may see it; enforce this at a gateway.
3. Place the model privately or on a contract-covered endpoint; read the agreement, abuse-monitoring and retention terms.
4. Expose data only through tool servers; no direct database credentials for agents.
5. Separate read, draft and execute tiers with separate credentials.
6. Grant least-privilege scopes, no wildcards, acting as the individual user where supported.
7. Use aggregate-first tools and minimum group sizes on slices.
8. Mask or tokenize direct identifiers, special-category and payment-card fields at the tool layer; redact free text.
9. Treat tool results as untrusted input. Never combine private data, untrusted content and an outbound channel in one agent without an approval step.
10. Require approval for every write and activation (diff, audience count, expiry); two approvers above a threshold.
11. Enforce consent and suppression in the execution layer, never by prompt.
12. Keep an append-only audit ledger with actor, model version, prompt version, inputs hash and approval ID.
13. Run an evaluation suite with an injection corpus on every model, prompt or tool change; use shadow mode before go-live.
14. Test the kill switch, token revocation and rollback each quarter.
15. Document the legal analysis per agent (legal basis, DPIA, Article 22, AI Act class, log retention) and review it quarterly.

---

If you are designing agents for a regulated stack, the PrivyCDP team can review your architecture against these patterns, covering model placement, tool scopes, approval gates and ledger fields, as part of a deployment qualification conversation. More on the AI layer is in the AI hub and on /cdp.