The problem nobody talks about with enterprise AI agents
Your CFO asks an AI agent: “What did we spend on salaries last quarter?”
The agent calls your payroll API. The API returns every employee’s salary, bonus, and personal number. The agent summarizes it back as a clean total.
So far, so good — the CFO is allowed to see that data.
Now an intern asks the same agent the same question. The agent calls the same API. The API returns the same payload. The agent answers.
This is the silent failure mode of nearly every “enterprise AI agent” deployment in production today.
Why endpoint-level RBAC isn’t enough
Most integration platforms — including ours, until recently — secure API access at the endpoint level. Either you can call GET /payroll/employees or you can’t. That model worked fine when humans built UIs that filtered results client-side, and when the only callers were trusted backend services.
Agents break this model in two ways:
- Agents are general-purpose callers. They don’t know which fields to hide. They summarize whatever they receive.
- Agents act on behalf of many different users. A single agent profile may serve the CEO and the warehouse worker. Endpoint-level RBAC can’t distinguish between them once the request is authorized.
The result: agents become a confused-deputy problem at industrial scale. A user with no direct database access can extract any data the agent can reach, simply by asking the right question.
Where source-system RBAC falls short
The standard answer is “let the source system handle it.” Pass the user’s identity to the payroll system. Let the payroll system filter.
This works — when the source system supports it. In practice:
- Legacy systems often have a single service account with full access. There is no per-user delegation.
- Third-party SaaS APIs frequently lack row-level permissions. You either have admin scope or no scope.
- Custom internal APIs were built before AI agents existed. Nobody added a
filter_by_userparameter. - Aggregations leak. Even when row filtering exists, sums and averages over filtered data are often computed on the full set.
For a CISO, this means your data exposure surface is now defined by the weakest connector in your agent’s toolbox.
Defense in depth: policy-driven response filtering
We’ve added a new layer to Copyl’s Integration Platform: DataAccessPolicy. It sits between the source-system response and the agent, and applies declarative rules to what gets returned.
The model has three core ideas:
1. Policies are attached to integration actions, not agents.
A payroll endpoint has one policy. Every agent — every user — that touches that endpoint goes through the same evaluator. There’s no way for a misconfigured agent to bypass the rule.
2. Rules match on subject context, not endpoint.
The evaluator sees the full subject: user identity, roles, claims, agent profile, enterprise. A rule can say “if user role contains CEO, allow all rows” or “if user is Employee, return only rows where employeeId matches their ID.”
3. Push down when possible, post-filter as fallback.
If the source API supports filtering, the policy rewrites the request — ?employeeId=42 — so the sensitive data never leaves the source system. If pushdown isn’t supported, the response is filtered server-side before the agent sees it.
This last point matters for compliance. Filtering at query time is genuinely more secure than filtering after the fact. Post-filter is defense in depth, not a substitute for source-system controls.
What this looks like for a Sec/Compliance team
Three properties make this practical to govern:
Auditable. Every evaluation writes an audit record: which policy ran, which rule matched, how many rows came in, how many went out, how many fields were masked. You can answer the question “who saw payroll data last Tuesday, and what was filtered?” with a SQL query.
Versioned. Policies are draft → published → archived. Every change is a new version. You can diff versions, restore old ones, and prove what was active on a given date.
Testable before publish. Policies can run in dry-run mode — the filter is evaluated and logged, but the response is not modified. You can validate a policy against real traffic for two weeks before flipping it on. Publish requires a passing test or an explicit override.
For regulated industries (financial services, healthcare, public sector under NIS2/DORA in Europe), this turns “trust the agent” into “prove the agent.”
What it doesn’t solve
Honest disclosure of limits matters here:
- Source-system delegation is still better when available. Use it first. Policy filtering is for the cases where you can’t.
- Aggregations are tricky. A row filter that returns one employee’s salary, alongside a
total: 4,200,000field computed on all employees, leaks data. Our model detects aggregate fields and either errors, strips them, or requires an explicit opt-in. There’s no fully automatic answer here — it requires endpoint-by-endpoint thought. - Field masking is not encryption. Hashed personal numbers in a response are still PII for regulatory purposes. Masking reduces blast radius; it doesn’t eliminate the obligation.
- Policies are only as good as their rules. A wrong subject match will under- or over-permit. This is why we require test runs and audit visibility.
What this means in practice
If you’re running AI agents against any system that lacks row-level RBAC — most legacy ERPs, most payroll systems, most custom APIs built before 2024 — you have an exposure that endpoint-level access control cannot close.
The fix is structural, not a prompt-engineering trick. Tell the agent “only show this user their own data” in the system prompt and you have a policy that holds until the next jailbreak. Enforce it in the integration layer with a versioned, auditable policy and you have something a CISO can sign off on.
We’re rolling DataAccessPolicy out across Copyl’s marketplace agents now, starting with payroll, HR, and finance integrations. If you operate AI agents in a regulated environment and want to talk through where the exposure lives in your own stack, get in touch.
Copyl is a platform for building, deploying, and governing enterprise AI agents. Our Integration Platform (CIP) connects agents to business systems with end-to-end policy enforcement, audit logging, and version control.