Key takeaways

• The data risk in agentic AI is the tool call, not the prompt. An agent wired to tools pulls full customer records autonomously, at machine speed, based on inferred context rather than any human decision.
• Every existing control layer misses the tool call. Network controls see access, not content. Storage-layer protection scans data at rest. Model guardrails inspect prompts. None of them see what a tool returned into the model's context.
• Agent DLP sits inline at the gateway and responds in three ways. It allows a call through untouched, redacts sensitive values from the payload in place, or blocks the call entirely before the data reaches the model.
• Inspection is fast enough to run in the request path. Each call adds about one second at p50, under 1.5 seconds at p99, bounded and predictable regardless of payload size, and proportional to how many tool calls a task makes.
• Start in observe mode, enforce when you're ready. Out of the box, Agent DLP records what it would have done and changes nothing, turning what would otherwise be a months-long governance review into a deployment decision measured in days.

For years, the risk of a data leak has been tied to a person clicking something they shouldn't. Sensitive records sat behind access control, and extracting data meant a human with credentials and intent. AI agents quietly removed that assumption.

An agent wired to tools reads your databases, queries internal APIs, and decides independently what to do with the responses, all at machine speed. The interesting security question is no longer what did the model say? It's what did the model do, with whose data, and where did that data go? Bedrock Data’s Agent DLP doesn't just answer it, but also acts on it by redacting or blocking any tool call passing through the gateway that would leak sensitive data.

Agents act, they don't just talk

A chatbot that only generates text has a contained blast radius. An agent wired to tools does not. Give a model a tool that looks up a customer, and it can pull a full record (name, contact details, government identifiers, payment information) the moment it decides the conversation calls for it. This is now the default shape of enterprise AI: agents call tools, tools touch real systems, and the model chooses what to ask for.

The choice of which tool, with which inputs, and what to do with the result is made autonomously, based on whatever is in front of the model, including untrusted content the agent just read a moment earlier. This is the new control problem: agents compose data access across tools and sources in ways no static permission model was designed to anticipate.

Why existing controls sit at the wrong layer

Most data controls were built for a world of humans and services, not agents. Each of them misses the tool call:

• Network and access controls decide whether an agent's tool can reach a datastore. They cannot see that one particular call just returned hundreds of customer records into the model's context.
• Storage-layer data protection scans data at rest. It sees a read against a system, not the meaning of the call: which agent, acting for which user, asked for what, and what came back.
• Model-side guardrails inspect the prompt and the response. They do not sit between the tool and the data.

None of these can answer the questions a security team actually has about an agent. Which tools does it call? Are the tool calls to a sanctioned MCP? Is sensitive data being sent to an MCP when it shouldn’t be? Left unanswered, those questions harden into a familiar bind: either a slow rollout gated on manual, agent-by-agent review, or a broad rollout where the risk is simply unknown.

A live record, not a static map

The answer isn't a static map of what each agent could reach. It's a live record of what agents actually do with data on every call. And it's the ability to act on that in the moment, redacting a sensitive result or blocking a call that crosses a line. The organizations that adopt agents fastest are not the ones with the fewest security requirements. They are the ones who can watch each tool call as it happens, keep an account of it, and enforce a policy on the calls that warrant it. That turns an all-or-nothing bet into a graduated rollout measured in days rather than months.

The threat model

• Sensitive-data exposure. Data leaves through what an agent sends into a tool or what a tool returns.
• Injection that turns into data exposure. Content the agent reads can steer it into pulling sensitive data out through a tool, or pasting it into one. Agent DLP catches the data movement even when the model was tricked into it.
• Over-broad access. A powerful tool can return far more sensitive data than a task needs. Per-call inspection is where that surfaces and can be capped.
• No record of what agents did with data. Teams can't reconstruct which agent moved which sensitive data, for which user.

Why the gateway is the right place to stand

Every tool call an agent makes already passes through the gateway, and that gateway already sees the entire interaction. It receives the request, processes the response, and knows the relevant information for determining the caller. Agent DLP inspects and acts right there, on the gateway you already run and in the path your agents already take.

Where Agent DLP sits

Agent DLP observes each tool call at the gateway at two moments: as the request goes out to the tool, and as the result comes back. Both are inline: the gateway waits for Agent DLP's verdict before proceeding, so it can change or stop a call, not merely watch it.

Understanding what's in the payload

Deciding whether a call carries sensitive data combines two complementary approaches, because neither is enough alone. A machine-learning model reads the content the way a person would, recognizing sensitive information even when it's buried in messy, natural-language text like a support-ticket body. Alongside it, deterministic checks confirm the well-structured identifiers. These are the things that either are or aren't valid, like a payment card or a government ID. The model provides breadth; the deterministic layer provides certainty. Together they see both the obvious and the hidden, and Agent DLP builds a picture of exactly what sensitive data a given call would move.

Deciding what to do

Understanding the payload is half the job. What Agent DLP does about it is driven by policy, and it has three responses:

• Allow: the call passes through untouched. The default.
• Redact: sensitive values are removed from the payload in place, so the tool, or the model, receives a scrubbed version while the rest of the content is preserved.
• Block: the call is stopped. Before the tool runs, that means it never executes, and the agent gets a clear, in-line signal it can reason about; on the way back, it means the sensitive result is withheld before it reaches the model.

Policy is targeted rather than blanket. Teams scope a rule by tool, agent, user, and type of sensitive data, so protection lands exactly where it's warranted and nowhere else. When several rules apply to one call, the strongest response wins, so a cautious rule is never quietly overridden by a permissive one.

Built to be safe to run

Two choices keep Agent DLP from becoming a risk of its own.

It fails open. This is a deliberate choice: if inspection can't complete, the call still proceeds. A control that can halt production is one that teams turn off, and one that's off protects nothing, so availability wins. The tradeoff is that a call slipping past a failed inspection goes uninspected; those failures are logged and alertable, not silent.

It observes before it enforces. Out of the box, with no policy configured, Agent DLP watches and records what it would have done, and changes nothing. Teams turn on redaction and blocking deliberately, once they've seen real traffic and understand what their agents actually do. That graduated path (watch, learn, then enforce the cases that warrant it) is the same thing that turns a months-long governance review into a deployment decision measured in days.

The audit trail that was missing

Every call (observed, redacted, or blocked) produces an activity record: what sensitive data was present, which tool and action were involved, and what Agent DLP decided. Each record is tied back to the specific agent that made the call, building a history of what each agent has done and a running summary of what it reaches.

That directly answers the forensic questions from earlier. For any agent, a team can see which tools it called, on whose behalf, and whether those calls carried sensitive data—the trail that simply didn't exist before.

Fast enough to sit inline

Inspection runs in the request path, so we measured it. A single inspection adds about one second (p50 ≈ 1.0 s, p99 under 1.5 s, measured warm). A call is inspected as it goes out and again as the result comes back, so a task that makes a handful of tool calls adds a few seconds of inspection in total, in proportion to how many calls it makes. It is a bounded, predictable cost, small relative to the time an agent's work already takes, and it buys a record of every call and the power to stop the ones that matter.

Agent DLP in action

The scenarios below show Agent DLP against a realistic customer-support setting: an agent with tools that read a body of customer records and support tickets, the kind of content that naturally carries names, contact details, government identifiers, payment information, and more woven through free text. Because the data is representative of what these agents touch in production, it exercises the full range of what Agent DLP looks for.

Observing what an agent touches

The agent answers an ordinary question that, along the way, pulls a customer record. Agent DLP changes nothing, but for the first time the team can see an agent handling sensitive data, and exactly which kinds.

Redacting sensitive fields in flight

Policy calls for identifiers and payment information to be stripped from what tools return. The agent still gets its answer; the sensitive values never reach the model in the clear.

Blocking a disallowed call

Policy blocks a particular action for a particular agent. The agent makes the call, receives a clear refusal it can reason about, and the action never runs.

Start watching, then start enforcing

The fastest way to adopt agents safely is to see them clearly first. Agent DLP starts in observe mode, building a record of what every agent actually does with data before you change anything. Once that picture is in hand, you turn on redaction and blocking for the cases that call for it, and tighten from there.

That is the shift worth making. As agents take on real work through tools, the tool call becomes the thing to govern, and the gateway is the one place to govern all of them at once. Get that right and agent security stops being the reason a rollout stalls, and becomes the reason it can move.

Want to find out how Agent DLP can enable you to observe and control your AI agents? Book a demo with us today.

FAQs

Does Agent DLP slow down my agents?

Each inspection adds about a second (p50 ≈ 1 s, p99 under 1.5 s, measured warm). Because every tool call is inspected on the way out and back, that cost scales with how many calls a task makes. It is bounded and predictable, and it is the price of catching sensitive data in the path instead of after the fact.

What happens if something in the inspection fails?

Agent DLP fails open. If any part of the check can't complete, the tool call still proceeds. Inspection is additive; it never becomes a new single point of failure.

Do I have to start blocking on day one?

No. With no policy configured, Agent DLP observes and records what it would have done, changing nothing. You turn on redaction and blocking when you're ready.

What sensitive data does it find?

Personal and contact information, government identifiers, and payment information woven through both structured fields and free text, with room to extend the categories and add vocabulary specific to your organization.

How targeted is policy?

Rules apply to specific tools, agents, users, and kinds of sensitive data, on the way out or on the way back. Where several rules apply, the strongest response wins, so a permissive rule can't quietly override a stricter one.

What does Agent DLP let me see?

Agent DLP gives you a live view of every tool call your agents make, an understanding of the data those calls carry, and policy-driven redaction and blocking when you're ready to enforce.