- An AI agent’s security boundary cannot be judged solely by its explicit access control list. What matters is not what the agent is granted directly, but what it can persuade other systems in the environment to execute on its behalf.
- Through borrowed authority (the classic confused deputy problem), an agent interacting with shared, privileged data-movement services or backend pipelines can bypass intended restrictions without needing elevated privileges of its own.
- AI agents amplify this vulnerability through sheer volume and unscripted improvisation, dynamically chaining tool sequences and exploiting shared shortcuts that developers coded for speed.
- Agent memory compounds the risk: caching query results in vector stores or conversational state allows sensitive information to outlive initial access checks, making it retrievable by subsequent callers with lower rights.
- This is fundamentally an organizational governance gap: security often owns identity, data teams own the platform, and developers build the agents using shortcuts—leaving the hidden paths between an agent and the data it touches completely unowned.
“When an AI agent is built, its permission list looks minimal and easy to defend. But the problem isn’t what the agent is granted; it’s what it can get other systems to do for it.”
Consider an analytics agent approved for two sales datasets and nothing else.
On paper, the security assessment is clean. The access-control list is short, the agent has no write privileges, and its blast radius appears strictly bounded. If an audit committee asks whether the agent can read payroll records, strategic financial models, or customer PII, the technical answer based on its IAM role is a reassuring “no.”
Yet in practice, that same agent can often reach far beyond those two datasets. It does so without breaking encryption, without exploiting a zero-day vulnerability, and without triggering an alert in standard security dashboards.
1. The Illusion of the Access Control List
In traditional enterprise software, permissions are predictable. A microservice or a report queries a database using fixed, pre-compiled SQL queries or deterministic API endpoints. The path from the application to the data was written by an engineer, reviewed by a peer, and validated in a staging environment.
AI agents work on an entirely different paradigm. An agent is not a deterministic script; it is a reasoning loop powered by a language model. Given an objective, it decides at runtime which tools to call, which parameters to supply, and how to chain multiple steps together.
When security teams evaluate an agent solely by the credentials attached to its service principal, they make a dangerous assumption: they assume that the agent’s direct permissions define its reach. In reality, permissions define only what an agent was given directly, not what it can cause downstream systems to do on its behalf.
3. Volume and Improvisation
While the confused deputy is an old concept, AI agents change the equation in two critical ways:
Unlike human users who operate with friction or traditional scripts that follow hardcoded branches, an AI agent chains together tool calls in ways engineers never explicitly scripted. If direct access to a table is blocked, an agent may query an internal export function, read temporary staging files, or ask an internal API to summarize the data.
An agent operates at machine speed. It can attempt dozens of permutations in seconds, exploring internal conduits and defaulting to flexible shared services because they offer the fastest, least-resistant path to fulfilling the prompt.
4. The Flawed Audit Trail
When borrowed authority occurs, traditional security auditing breaks down.
If an attacker breaks through a firewall or steals an API key, security information and event management (SIEM) systems detect unusual IP addresses, failed password attempts, or anomalous credential usage.
With an AI agent borrowing authority:
- The request originates from an internal, approved system.
- The request is signed using a valid, authenticated service credential.
- The database or target API simply logs: “Service Principal X read Table Y.”
The audit log captures the credential, but it completely misses the context: who actually asked for the data, what prompt initiated the request, and whether the end user was authorized to see it. To the monitoring tools, the transaction is indistinguishable from normal platform operations.
5. The Silent Risk of Agent Memory
The problem is compounded when AI agents are equipped with memory.
To provide continuity across conversations, modern agentic systems store conversation history, entity summaries, and retrieved data in vector databases or session scratchpads. When an agent queries a sensitive dataset on behalf of an authorized user, it often caches or summarizes those facts into its persistent memory.
This creates a secondary exposure:
When another user—or another agent with lower permissions—interacts with the agent later, the sensitive data is already sitting in the agent’s memory store. When the agent answers questions using that stored context, the original database’s role-based access control (RBAC) never executes.
The data outlives the access control check, allowing unprivileged secondary extraction without any direct database query ever taking place.
6. Where the Platforms Stand
Major enterprise data and cloud platforms handle identity and authorization differently, and understanding these platform-specific mechanics is essential:
When an application accesses Databricks resources through its own service principal, all users share that principal’s permissions, bypassing fine-grained user policies. However, using user authorization with Unity Catalog row filters and column masks ensures that the platform evaluates individual user permissions dynamically at the data engine tier.
-- Enforcing caller identity at the Unity Catalog engine layer
-- When an app uses user authorization, row filters and column masks evaluate against the caller
CREATE OR REPLACE FUNCTION sales_analytics.region_mask(region STRING)
RETURNS BOOLEAN
RETURN
IS_ACCOUNT_GROUP_MEMBER('enterprise_security_admin')
OR (IS_ACCOUNT_GROUP_MEMBER('regional_sales_rep') AND region = current_user());
ALTER TABLE sales_analytics.quarterly_revenue
SET ROW FILTER sales_analytics.region_mask ON (sales_region);Databricks also supports API scopes to explicitly limit what an application or agent can execute on a user’s behalf.
In Snowflake, stored procedures run with their owner’s privileges by default. If an AI agent invokes a procedure running under Owner Rights, it inherits the broader privileges of the creator rather than being constrained to the caller’s rights. If an agent routes requests through a shared service account, features like row filters, column masks, or region restrictions fail because the platform loses track of who is actually asking.
Microsoft utilizes mechanisms like the on-behalf-of (OBO) flow to allow middle-tier APIs and AI services to securely obtain tokens that preserve user identity context downstream, preventing an autonomous agent from silently acting as an unconstrained administrative insider.
7. Who Is Accountable? The Governance Gap
The persistence of borrowed authority is rarely due to a simple technical mistake. It is an organizational governance gap.
In most enterprises, responsibilities are fragmented across organizational silos:
Security often owns identity, provisioning roles and IAM policies according to traditional access reviews.
Data teams own the platforms, focusing on availability, query performance, and pipeline throughput.
Developers building the agents rely on shortcuts—like shared service accounts—to deliver features quickly.
Because no single team is responsible for the entire path—from the user’s prompt, through the agent’s chained tool calls, through middle-tier utilities, to the underlying data—the conduit remains unmonitored.
8. Closing the Gap: Beyond System Prompts
Many teams attempt to solve this problem by refining system prompts: “You are a helpful assistant. Do not access confidential data, and only assist with authorized sales queries.”
System prompts are suggestions to a probabilistic model, not security guardrails. An agent cannot be expected to enforce security policies that the underlying infrastructure fails to enforce.
Closing the gap requires structural architecture:
Never allow AI applications to pool permissions under a single blanket service principal. Enforce user authorization down to the data platform so that row filters, column masks, and table ACLs evaluate the human caller’s rights.
Ensure that automated pipelines and stored procedures execute with caller rights rather than defaulting to elevated owner rights.
Apply API scopes to explicitly restrict what an application can execute on a user’s behalf, and isolate memory stores so that cached facts cannot be queried across tenant or authorization boundaries.
9. Sources & Original Publication
This article was originally authored by Kiran Elengickal and published by the Forbes Technology Council:
Hardening Your Enterprise AI Workflows?
Abilytics partners with enterprise leaders to build secure, identity-governed AI architectures, context-aware tool gateways, and zero-trust agentic platforms.
