Key takeaways

• AI agents create a new data exposure path. When an agent calls a tool, it can pull full customer records autonomously, at machine speed, based on context it inferred, not a human decision.
• Existing controls all operate at the wrong layer. Network controls see whether a tool can be reached; storage-layer protection scans data at rest; model guardrails inspect prompts. None of them see the tool call.
• The gateway is the only complete inspection point. Every tool call transits it, so one vantage point covers every datastore and API behind it. You instrument the choke point once, not every tool.
• Agent DLP responds inline with allow, redact, or block. Policy is scoped by tool, agent, user, and data type. When rules overlap, the strongest wins, so a permissive rule can never quietly override a stricter one.
• Observe first, then enforce. Agent DLP ships in observe mode and changes nothing until policy is configured, 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. The credential is the agent's.

The intent is inferred from context. And the data moves 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 answers that question by inspecting and constraining agent tool calls at the one place they all pass through: the gateway.

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. That is genuinely a 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? On whose behalf? Do those calls carry sensitive data? 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 flows out through what an agent sends into a tool, or through what a tool returns: a lookup that pulls a full record into the model's context, from where it can be echoed onward, logged, or folded into a reply.
• Prompt-injection-driven misuse. Content the agent reads can steer it into calling a tool it shouldn't, with inputs it shouldn't, a confused-deputy problem where the agent has legitimate access and is talked into misusing it.
• Over-broad access. An agent with a powerful tool and no per-call constraint can reach far more than any single task requires.
• No audit trail. When something goes wrong, most teams can't reconstruct which agent called which tool, for which user, and whether the call carried sensitive data.

Why the gateway is the right place to stand

A gateway is the one place every tool call transits. It sees the full request before the tool runs, the full result after, and it knows the caller's identity. That makes it the natural, and only complete, place to inspect and constrain agent behavior. One vantage point at the gateway sees every tool call, regardless of which datastore or API sits behind it. You instrument the choke point once, not every tool forever.

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. If any part of the inspection can't complete, the tool call still proceeds. A security layer that takes down production the first time something upstream hiccups is worse than no layer at all. Agent DLP is additive; it never becomes a new single point of failure.

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

Because inspection happens inline, it adds time to each tool call, so Agent DLP is designed to keep that cost small and predictable, rather than letting it grow with the size of the data. In testing, inspecting a call takes at most a few seconds, and it stays in that range regardless of payload size. Set against the several seconds an agent already spends reasoning and calling tools on a single turn, that's a governance layer agents don't meaningfully wait on.

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?

It inspects each call inline, so there is some cost, but in testing that's at most a few seconds per call and stays there regardless of payload size. Against the several seconds an agent already spends reasoning and calling tools on a turn, it isn't something users experience as a slowdown.

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.