A Technical blog series on where sensitive data moves in an AI workflow, what decisions Protecto makes at each point, and what enterprises get from enforcing policy once instead of everywhere.
Contents
Introduction The Six Places Enterprise AI Touches Sensitive Data
Pattern 2 · API Gateway Integrate Once: Why AI Data Policy Belongs at the API Gateway, Not Inside Every Agent ← You are here
Pattern 3 · AI Gateway Every Team Is Calling an LLM. One Policy Should Govern All of It: Protecto at the AI Gateway
Pattern 4 · MCP Gateway Your Agents’ Tools See More Than Your Agents Do: Protecto as the MCP Gateway
Pattern 5 · Agent Gateway When One Agent Hands a Case to Another: Protecto as the Agent Gateway
Pattern 6 · RAG PipelineThe Archive That Answers Back: Protecto in the RAG Pipeline
PATTERN 2 · API GATEWAY
Integrate Once: Why AI Data Policy Belongs at the API Gateway, Not Inside Every Agent
Your organization has five AI agents today and will have eight by the end of the quarter. All of them pull from the same internal APIs, and every one of them receives the full customer record, because that’s what the API returns. You have two ways to fix that: build data filtering into every agent, or enforce it once, at the gateway they all pass through. This article walks through the second option, what decisions actually get made there, and why the math favors it.
Part of a series on the six places Protecto fits into an AI workflow. Each article stands alone: a real-world style use case, where Protecto sits, what changes, and what the business gets out of it.
The situation
Picture a company, insurance, banking, healthcare, SaaS, it doesn’t matter, that has spent the last year shipping AI agents. A support agent that answers customer questions. An analytics agent that summarizes trends for leadership. A collections agent that follows up on overdue accounts. All of them call the same two internal services: the Customer API and the Accounts API.
Those APIs were designed years ago for a handful of trusted applications, so they do what old internal APIs do: return everything. Name, email, phone, government ID, account balances, payment history, and the free-text notes where an agent once wrote “customer missed two payments after a job loss.”
When the callers were three reviewed applications, that risk was considered manageable. Now the callers are AI agents that put whatever they receive into prompts, memory, and logs, and the caller list grows monthly. The full-record-for-everyone design quietly became the company’s biggest data exposure. Nobody decided that; it accumulated.
The two ways to fix it
Option one: fix every agent. Each agent team adds its own filtering: decide which fields their agent needs, write the masking logic, maintain it. With five agents and two APIs, that’s ten filtering implementations owned by five teams. With eight agents, it’s sixteen. Every policy change is a coordinated multi-team code change. Every new agent repeats the work, and the one team that skips it reopens the hole. Security now depends on whichever team shipped most recently.
Option two: fix it once at the gateway. Every one of those API calls already passes through the same door: the API gateway that routes and authenticates requests. Attach Protecto there, and every response gets evaluated on its way to the caller, using rules the security team writes once. Agents don’t change. APIs don’t change. The gateway already knows who’s calling; Protecto applies the policy configured for that caller.
The rest of this article is about what those rules actually look like, because “applies the policy” is where most explanations stop, and it’s exactly where the interesting part starts.
The decisions, concretely
Take one customer record as it comes back from the Customer API:
Priya Sharma · priya.s@email.com · +1-415-555-0182 · SSN 543-88-1201 · Account #88-4392 · Balance: $8,240 overdue · Notes: "Missed two payments after a job loss. Requested hardship plan in March."
Now watch what three different agents receive when they request this same record through the gateway. This is policy-based masking and unmasking in action: not one setting, but a per-agent decision about every sensitive element.
The support agent is customer-facing and needs enough to hold a conversation, but has no business holding government IDs or full account numbers. Its policy allows some PII and masks the rest:
Priya Sharma · [EMAIL_a8f2] · phone ending 0182 · SSN [SSN_c419] · Account [ACCT_7d20] · Balance: $8,240 overdue · Notes: "Missed two payments after a job loss. Requested hardship plan in March."
The agent can greet the customer by name, confirm the last four digits of a phone number, and discuss the balance. If its conversation gets logged, or its prompt reaches an outside LLM, no ID or account number goes with it.
The analytics agent summarizes trends across thousands of customers. It needs patterns, not people, so its policy allows no PII at all:
[NAME_4b71] · [EMAIL_a8f2] · [PHONE_9e15] · SSN [SSN_c419] · Account [ACCT_7d20] · Balance: $8,240 overdue · Notes: "Missed two payments after a job loss. Requested hardship plan in March."
Notice two things. The placeholders are consistent: [ACCT_7d20] is the same placeholder the support agent saw, so if the analytics agent joins data across both APIs, the records still line up. And the business content survives: it can still report that hardship-plan requests are up 12 percent this quarter, without ever holding a name.
That consistency is a deliberate policy choice, not a universal default. Stable placeholders improve joins, but stability also increases linkability, so it’s scoped to where it’s needed, such as within a tenant or an approved workflow, rather than shared across every agent and environment.
The collections agent has to actually reach this customer, and you can’t dial a placeholder. This is where policy-based unmasking comes in. Its policy masks the record by default, but for the dialing task specifically, it permits revealing the real phone number and balance:
Priya Sharma · [EMAIL_a8f2] · +1-415-555-0182 · SSN [SSN_c419] · Account [ACCT_7d20] · Balance: $8,240 overdue · Notes: "Missed two payments after a job loss. Requested hardship plan in March."
Unmasking isn’t a privilege the agent owns. It is controlled by policies defined for the user and the task. Protecto applies the appropriate policy, ensuring that each agent receives only the level of access to sensitive data it needs. The same agent asking for the same record outside that task gets the masked version. And the SSN stays masked for everyone in this story, because no agent’s job requires it.
One record, three renderings, each one defensible. That’s the whole product idea: the question “what should this agent see?” gets a written answer per agent, per field, per purpose, and the gateway enforces it on every call.
What customers get
A product manager evaluating the two options is really comparing five things:
| Dimension | Filtering inside every agent | Protecto at the gateway |
| Integration work | Once per agent, forever | Once, at the gateway |
| Policy changes | Coordinated code change across teams | One rule change, applies to all callers instantly |
| New agent onboarding | Custom filtering built and reviewed each time | Assign it an agent class; it inherits policy on day one |
| Consistency | Each team masks differently; joined data stops lining up | Same placeholders everywhere; data stays connected across agents |
| Audit | “Check twelve codebases” | One place to answer “who can see what, and who unmasked what, when” |
The last two rows are the ones that surprise teams. Consistency sounds cosmetic until two agents mask the same account number differently and a cross-agent workflow silently breaks. And auditability is often what gets the project funded: when a regulator, a customer, or your own CISO asks “which AI systems can access government IDs?”, the answer is a policy lookup, not an investigation.
What this doesn’t do
Honesty helps here. The gateway sees what crosses the gateway. It doesn’t see what an agent does internally with data it legitimately received, what two agents pass directly to each other, or what flows through third-party tools. Those need their own enforcement points, and they’re covered in other articles in this series. Policy evaluation also adds a step to every request, which has a latency cost. And identity remains your infrastructure’s job: the gateway and identity system verify who’s calling; Protecto applies the rules configured for that verified caller. It doesn’t decide who your callers are.
When this pattern is the right one
Start here when the problem is many agents (or apps) sharing the same backend data and you want protection that doesn’t scale in cost with the number of callers. It builds on infrastructure you already run, and it can be one of the fastest integration patterns to deploy when your agents already share a gateway. It turns “every new agent is a security project” into “every new agent inherits the rules.”
Go deeper than the gateway when the risk is inside a single high-stakes agent, its prompts, memory, and logs, which calls for embedding protection in the agent’s own workflow instead.
