Bedrock Data's Agent DLP: Access Scope and Runtime Control

When a company gives an AI agent access to business data, teams usually begin with scope: which data should the agent be allowed to access, and under what permissions?

That is a familiar starting point, because it extends the way organizations already manage access for employees and service accounts.

Bedrock Data’s Agent DLP, announced on July 30, 2026, highlights a second control layer: monitoring and enforcing policy on the data exchanged after access has been granted.

This article uses the announcement to examine why agent governance should not stop at access provisioning.

A note on scope: this article is limited to access control and monitoring between AI agents and datastores. Choosing an identity platform or an authentication method, and evaluating whether to adopt any particular product, are outside its scope.

What Agent DLP Does at Runtime

According to Bedrock Data’s announcement, Agent DLP operates inline at the agent gateway. The company describes it as using the gateway’s own hooks rather than standing up a separate proxy alongside it.

Bedrock Data says Agent DLP provides native hooks for Amazon Bedrock AgentCore Gateway and LiteLLM.

The company says it inspects tool calls passing through the gateway in both directions, applying policy to the requests an agent sends to MCP (Model Context Protocol) tools and to the responses those tools return.

The announcement describes four verdicts a call can receive: blocked, modified, redacted, or observed. Each decision is logged with the target, the action, the data types involved, and the verdict.

The product page illustrates three of these with examples: a support agent’s call to retrieve customer information is blocked when the response contains a Social Security number and a card number; a response containing an email address and phone number comes back with those fields removed, and the agent continues with the rest; and lower-risk activity is recorded for later review without interrupting the agent.

These are illustrative product scenarios from Bedrock Data, not measured results from a customer deployment.

Chief Executive Bruno Kurtic is quoted in the announcement to the effect that governance at runtime is what turns AI from a risk conversation into a growth strategy. Because this is a vendor statement, it is best read as Bedrock Data’s product positioning rather than as independent evidence of outcomes.

What the Published Telemetry Measures

Alongside the announcement, Bedrock Data published what it describes as aggregate findings from anonymized telemetry across enterprise environments. The company describes the data as coming from technology, finance, and healthcare, covering more than 70 petabytes, nearly 180,000 datastores, and more than 540,000 identities.

Two of the published figures are relevant here.

Bedrock Data says that, in environments with registered OAuth applications and service accounts — the identity classes agents may use for authentication — the median application could reach 55 datastores. By comparison, the median employee could reach three to four.

It is worth being precise about what this does not say. It does not mean that the median deployed AI agent reached 55 datastores. It is a measure of the reachable scope of a class of identities that agents may use to authenticate.

The second figure is that, among all identities that could reach any data at all — human and non-human alike — 81% could also reach sensitive data.

Now the important caveats. These are company-reported figures based on Bedrock Data’s own telemetry. The materials reviewed for this article do not identify an independent third-party validation of these findings, and MIF did not verify the figures independently.

Beyond that, the announcement materials do not state how many companies were covered, over what observation period, how those environments were selected, or how sensitive data was classified.

Most importantly, these are access-posture figures describing potential reachability. They are not evidence that agents actually accessed 55 datastores, that data was exfiltrated as a result, or that Agent DLP prevented any of it.

Separating Reachability from Runtime Data Flow

With that distinction in place, the argument the announcement supports can be stated more carefully.

What the figures directly show is that non-human identities agents may use can have broad access across datastores.

What Agent DLP addresses is a different problem: within that access, which data any individual tool call actually sends and receives.

Bedrock Data itself presents these as two separate controls — understanding reachability, which it calls posture, and intervening during execution, which it calls runtime control.

This distinction matters in practice.

Identity and access management tells you what an identity is able to reach. A tool call at runtime tells you what a specific operation actually requested and what came back.

Because an agent can make a large number of tool calls in a short time, managing reachability and monitoring the data that actually moved need to be designed as separate controls.

Our View: Where Runtime Enforcement Sits in Permission Design

We treat AI decision-making as a sequence of stages — recognition, proposal, selection, approval, execution, and extended autonomy — and use that as the starting point for designing agent permissions.

Applied here, the point is this: permission to reach a resource and control over the data exchanged during a particular tool call are distinct concerns.

However carefully the entry point is designed — which datastores an identity is allowed to reach — that design alone does not tell you what data moved during execution. That is why a control that can detect what was sent and received at runtime, and stop it when necessary, is needed alongside the entry-point design.

That said, a product like Agent DLP should be placed precisely. It is not a system for managing tool execution permissions or authorization as a whole; it is a runtime control layer that applies policy to the data flowing through tool calls at the gateway. It is better read as complementing identity authentication, least-privilege grants, and per-tool authorization than as replacing them.

We apply the same principle — design on the assumption that AI will sometimes be wrong — to our own production process. We run automated checks first, then require human approval at the point where a value judgment is needed.

For agent data access, the same principle applies: rather than requiring a person to review every operation, route only high-risk events or policy violations for human review.

Practical Caveats: Coverage, and the Numbers That Aren’t Published

The first thing to check is what the inspection actually covers.

Because Agent DLP is placed on tool calls that pass through the gateway, it does not automatically cover every agent communication in an organization. If there are tools connected directly to an API, paths that run through a different gateway, or other egress routes, whether those pass through the same inspection point needs to be confirmed separately.

This is an inference we draw from the published architecture, not something Bedrock Data states. It also is not specific to Agent DLP; it is a question worth asking whenever an inline control is introduced.

The second issue is detection performance.

The public materials reviewed for this article do not provide evaluation figures for detection accuracy, false-positive rates, or missed detections. Bedrock Data publishes a latency claim of under 10 milliseconds per call, but the materials do not include an independent performance evaluation.

Bedrock Data itself recommends starting in observe mode to learn what agents are touching, then tightening to redaction or blocking by data type.

A prudent rollout would therefore avoid applying broad automatic blocking from the outset, beginning in observe mode and tuning policy against representative traffic before expanding redaction or blocking.

A further question is where each control should be implemented.

Leaving this vague invites two opposite mistakes: assuming that installing the product is the end of the matter, or trying to handle everything with internal rules and never using the product’s capabilities.

Determining which datastores an identity can reach falls under identity and access management. Reviewing and responding to the resulting logs is an operational responsibility. What a product like Agent DLP covers is the layer in between: inspecting data flow and enforcing policy on it.

A Starting Template: Four Angles

The table below is a starting point for reviewing the design around agent data access.

It is one example. The values you enter and the granularity of the items should be adjusted to your own risk tolerance, the sensitivity of the data involved, and your regulatory environment. The control layers listed will also vary with the products you actually use.

Control area	Example question	Typical control layer
Identity and reachable scope	Which identity does the agent run as, and which tools and datastores can it reach? Is that the minimum the work requires?	Identity and access management, non-human identity management, tool permissions
Coverage of runtime control	Which tool calls pass through the gateway? Do direct connections or alternate routes bypass inspection?	Agent gateway, interceptors, connection design
Policy and enforcement outcomes	Which events are observed only, and which are redacted or blocked? Who approves exceptions, and who updates policy?	Runtime DLP or policy-enforcement layer, data classification, policy management
Monitoring and response	Which verdicts become alerts, and who reviews them? If an anomaly is detected, how will you stop the agent, revoke its credentials, or fall back to manual operation?	Logging and monitoring, incident response procedures, identity management

Separating these four keeps the entry-point permissions, inspection coverage, the verdicts themselves, and the after-the-fact response from blurring together.

There is no single correct configuration for every organization. Use the table as a starting point and adapt it to the nature of your operations and data.

Closing Thoughts

Deciding what an agent is permitted to access does not, by itself, complete the governance of data access.

The telemetry Bedrock Data published indicates that non-human identities agents may use can have broad access across datastores. But that research did not measure actual exfiltration counts, the rate of inappropriate tool calls, or Agent DLP’s preventive effect.

The practical lesson we draw from the announcement is to separate access-scope controls from controls that inspect runtime data flow.

If you are moving ahead with agent adoption, we would suggest confirming at least these four points:

• Which identity the agent uses and what it can reach
• Which tool calls pass through runtime inspection
• Which data and operations are allowed, logged, modified, or blocked
• Who reviews anomalies, and how the organization will stop the agent, revoke its credentials, and recover

Runtime DLP is one layer in this control stack, focused on inspecting data flow and enforcing policy at execution time. Ongoing governance also requires identity management, least privilege, tool authorization, monitoring, and incident response.

Sources and Verification

This article draws primarily on Bedrock Data’s official announcement, “Bedrock Data Launches Agent DLP, Runtime Data Loss Prevention Built for AI Agents,” published on July 30, 2026, and on the company’s Agent DLP product page. The information was reviewed as of August 2026.

Business Wire distributed the company release, and Yahoo Finance and other outlets republished it. Those versions are not independent product evaluations.

The figures cited here — more than 70 petabytes, nearly 180,000 datastores, more than 540,000 identities, the contrast between a median of 55 datastores and three to four, and the 81% share — were all published by Bedrock Data based on its own anonymized telemetry.

The materials reviewed for this article do not identify an independent third-party validation of the telemetry findings. MIF did not independently verify the figures.

The announcement materials do not state the number of companies covered, the observation period, how environments were selected, how sensitive data was classified, or evaluation figures for detection accuracy, false positives, or missed detections.

These figures also describe the possibility of an identity reaching data. They do not indicate the rate of actual exfiltration or inappropriate access by AI agents, nor Agent DLP’s preventive effect.

Product capabilities, supported gateways, deployment methods, and availability may change. If you are evaluating adoption, please check the latest official information from Bedrock Data, Amazon Bedrock AgentCore, and LiteLLM.