An Approved Tool Call Can Still Be an Unauthorized Data Transfer

AI agent data exfiltration controls need to inspect what an agent sends through a tool, not only whether the tool itself is allowed. A legitimate connector can become an unintended data-egress path when sensitive information appears inside otherwise valid tool arguments.

A customer-support agent can read an internal customer record.

It is also allowed to create tickets in an external support platform.

A customer reports a recurring account problem, so the agent prepares a ticket.

The description includes the relevant technical history.

It also includes the customer’s account number, an internal fraud-risk note and an employee comment that was never intended to leave the company.

The ticket is created successfully.

The connector was approved.

The agent was authenticated.

The tool call was permitted.

The data transfer was not.

Tool authorization does not answer the payload question

Agent security discussions often begin with tool access.

Can the agent send email?

Can it update a CRM record?

Can it call an external API?

Can it create a support case?

Those are necessary controls.

But once a tool is available, the agent still has to construct the arguments that will be sent through it.

A tool such as:

create_support_ticket(customer, subject, description)

may be entirely legitimate.

The risk can sit inside description.

The same field could contain:

• a short troubleshooting summary;
• an internal customer identifier;
• a fraud score;
• an API credential copied from a diagnostic log;
• an employee-only note;
• an entire retrieved customer record.

Tool permission is not payload permission.

The security decision therefore cannot end when the tool name matches an allowlist.

Approved tools can still become exfiltration paths

OWASP’s 2026 Top 10 for Agentic Applications treats misuse of legitimate tools as a security problem. Its Tool Misuse and Exploitation category covers cases where an agent operates within authorized privileges but applies a legitimate tool unsafely, including data exfiltration. 

Its Agentic Top 10 describes scenarios in which approved capabilities can be used to disclose sensitive information and recommends per-tool controls that include data scope and egress allowlists, not merely functional permission.

An enterprise may legitimately allow an agent to use a support-ticket connector while still restricting what information can leave through it.

That moves the control from simple tool eligibility toward the content of the proposed transfer.

The relevant control sits inside the tool call

The useful inspection point is after the agent has assembled a proposed invocation but before the external action executes.

At that moment, the system knows:

• which tool the agent selected;
• the destination;
• the arguments;
• the current task;
• the user or agent identity;
• potentially, the classification or provenance of data included in those arguments.

The OpenAI Agents SDK supports tool input guardrails that run before a function tool executes and can reject the proposed invocation based on its arguments.

That makes the tool boundary a practical place to ask:

Is create_support_ticket permitted?

and then:

Is this particular invocation permitted with these arguments?

The second question is where payload-level policy becomes enforceable.

Data classification needs to survive into agent execution

Payload inspection becomes much harder if sensitive information loses its classification when it enters model context.

Suppose the internal customer system distinguishes:

customer-visible history

from:

internal fraud analysis

and:

restricted employee notes.

The agent retrieves all three because they are relevant to diagnosing the case.

If those records arrive in context as undifferentiated text, the tool-control layer may understand the words without knowing what may leave the organisation.

A stronger design preserves enough metadata to distinguish the categories.

The agent may be allowed to reason over restricted information internally while being prohibited from transmitting it to an external support platform.

Data the agent may see

is not necessarily the same as

data the agent may send.

That distinction has to survive long enough for the execution layer to enforce it.

Connector policy can constrain where data flows

Enterprise platforms already express some of these boundaries at connector level.

Microsoft Copilot Studio data policies classify connectors into Business, Non-business and Blocked groups and can prevent data sharing across incompatible groups. Microsoft explicitly positions these policies as protection against malicious or accidental data exfiltration. 

That provides a coarse-grained answer to:

Which systems may exchange information?

Agent execution can require a finer question:

Which data may cross that permitted route?

Two approved business connectors do not automatically make every field transferable between them.

A customer name may be appropriate.

A full fraud-investigation note may not be.

Destination matters as much as the tool name

The same connector can reach destinations with very different risk.

An email tool might send to:

• an internal employee;
• an approved customer domain;
• a personal email address;
• an unknown external recipient.

A storage connector might write to:

• a controlled internal workspace;
• a shared project folder;
• a public link;
• an externally owned tenant.

Payload authorization may therefore need to combine:

tool

destination

data classification

task context

A permitted combination might be:

support-ticket tool + approved vendor tenant + customer-visible diagnostic data

The same tool with restricted fraud-analysis content may require a different decision.

Redaction is sometimes better than blocking

A payload violation does not always require terminating the task.

Return to the customer-support case.

The agent proposes:

Customer reports intermittent authentication failures. Internal fraud score: high. Account number: 48192037. Engineering suspects token-refresh regression.

The external provider may only need:

Customer reports intermittent authentication failures. Engineering suspects token-refresh regression.

The policy therefore has several possible outcomes:

allow

remove or transform prohibited fields

request human approval

redirect to an approved destination

block the call

The right response depends on the data and the business process.

The key is that the choice happens before the sensitive payload leaves the boundary.

Human approval does not replace payload inspection

A workflow may already require approval before a consequential tool runs.

That is useful, but an approval prompt can still be too coarse.

Consider:

Allow agent to create support ticket?

A reviewer may reasonably click Approve because creating the ticket is exactly what the agent is supposed to do.

The material security information sits inside the arguments.

OpenAI’s tool-control model illustrates why the controls can remain separate: a tool can require human approval while input guardrails inspect the invocation before execution.

For higher-risk transfers, the approval surface can expose:

• destination;
• sensitive fields detected;
• proposed transformations;
• reason the data is required.

Approval then applies to the actual transfer rather than merely the name of the tool.

The audit record should capture what crossed the boundary

Logging only:

tool = create_support_ticket

does not explain the security event.

The more useful record is:

tool used → destination → data classes present → fields removed → fields transmitted → policy decision → approver if required

That matters during incident response.

If restricted customer information appears in an external system, investigators need to know whether:

• the policy failed to identify it;
• the agent transformed it incorrectly;
• an override allowed it;
• the destination was misclassified;
• or the arguments were never inspected.

The tool call is only the envelope.

The payload is the security event.

Agent least privilege has to include data movement

Traditional least privilege asks whether a principal has the minimum permissions needed to perform a task.

Agentic systems add another problem because separate legitimate permissions can be combined at runtime.

An agent may legitimately possess:

read access to sensitive data

and:

write access to an external system

without having authority to:

send the sensitive data to that external system.

Least privilege for an agent therefore has to govern permitted combinations of information and action, not only permissions considered independently.

The execution-boundary question becomes:

May this agent send this data, to this destination, through this tool, for this task?

An approved tool call can still be the wrong data transfer.

Security controls need to inspect both.