We connected our APM to AWS DevOps Agent — then came the data-confidentiality problem: a layered-defense pattern

By Kiran Khambete and Krish Balaraman — AWS Enterprise Support

About this series

This series follows one composite financial-services SRE team as it turns its own AWS support-case history into action with the AI agents it already runs. The first four parts moved from understanding the data to evaluating and deploying an agent to preventing incidents at runtime and change time:

• Part 1 — Turning AWS Support Cases into Operational Intelligence with the Coding Agents You Already Have: treat closed-case history as a dataset and mine it for recurring, high-effort toil.
• Part 2 — Evaluating AI operations agents against your real support-case data: score that history against AWS DevOps Agent's capabilities, deploy it on the highest-effort category, and measure the before-and-after.
• Part 3 — Are we ready to open the lines? A custom SRE agent for the contact-center risks your pipeline can't catch: a scheduled custom agent that catches runtime failures nothing else triggers.
• Part 4 — It passed every check and still broke production: shift-left release readiness: catch change-time failures that pass every pipeline check, on the pull request, before merge.
• Part 5 (this article) — We connected our APM to AWS DevOps Agent, then came the data-confidentiality problem: the team built it — now the practical challenges begin. This part opens a new thread in the series: the implementation challenges and enhancements you hit once the agent is live in a regulated environment, starting with the first one this team ran into — feeding the managed agent real, sensitive telemetry.

Overview

By the end of Part 2, the team had done the hard part: they evaluated AWS DevOps Agent against their real case history and deployed it on their highest-effort category. It worked. So they did what any team does when a tool earns its keep — they tried to make it better, by feeding it the telemetry their engineers already trust: their existing application performance monitoring (APM) tool. Their APM is one they run and manage entirely themselves — it happens to sit on-premises, but it could just as easily run in their own cloud account; what matters is that they own and operate it (it is not a vendor-hosted SaaS), and it holds regulated data. That is where the first real implementation challenge showed up. (For the broader picture of wiring multiple observability tools into DevOps Agent, see the companion article, Agentic Observability for Enterprise Workloads: Leveraging AWS DevOps Agent for Multi-APM Integration — this part goes deep on the data-protection challenge that one raises.)

Connecting it turned out to be the easy part — AWS has a native, private answer for reach, and the team stood it up without much trouble (more on that briefly below). The question that actually stopped the rollout came after the connection worked: once a managed, AWS-hosted model can read our telemetry, how do we keep confidential data under our control — and who owns the sanitization? This article is about that one question. It gives architects and security reviewers a defensible answer, because the wrong framing — "nothing sensitive ever reaches AWS" — will not survive a security review, and the right one will.

The scenario

A regulated customer runs an APM tool that they operate and manage entirely themselves — on-premises or in their own cloud account, but not a vendor-hosted SaaS. They want the value of AWS DevOps Agent — automated, correlated incident investigation — but their telemetry contains sensitive data: PII, and often proprietary non-PII data such as internal hostnames, account or transaction identifiers, and secrets. Their requirement is a data sovereignty and egress-control one: confidential data must stay under their control, and any sanitization they rely on should be something they own and can audit.

Why the managed model changes the problem

With the managed AWS DevOps Agent, the reasoning model is AWS-hosted — it does not run in your environment. Per AWS DevOps Agent Security, "Data is stored in the region where your Agent Space is created, while inference processing may occur within your geography." The routing is geography-bounded — EU requests processed in the EU, US in the US, Australia in Australia, Japan in Japan, anything unlisted defaulting to the US — but still on AWS-managed infrastructure, not yours.

That has a direct consequence: if you want the managed agent to reason over your telemetry, that telemetry will be processed by an AWS-hosted model. You cannot both use the managed agent and guarantee the data never leaves your environment. So the honest goal is not "nothing reaches AWS" — it is controlling what sensitive data the managed agent ever sees, and doing the controlling in infrastructure you own.

Two things worth putting in front of a security reviewer early, both from the same page. First, AWS states the redaction expectation directly:

"AWS DevOps Agent does not filter PII information when summarizing data gathered during investigations, recommendation evaluations, or chat responses. It is recommended that PII data be redacted before storing in observability logs."

Second, on training use — a question this audience always asks:

"AWS does not use agent data, chat messages, or data from integrated data sources to train models or improve the product."

So AWS tells you to redact sensitive data before the agent's data sources hold it, and commits that what does flow is not used for training. This article shows how to implement the redaction recommendation for an APM source. (Note the exact scope: AWS recommends redacting before storing in observability logs; it does not endorse any specific gateway design below.)

Connectivity was the easy part

Reaching the APM privately is a solved problem, so this article does not dwell on it. If the APM (or an MCP server fronting it) is reachable from inside an AWS VPC, AWS DevOps Agent private connections route to it over Amazon VPC Lattice — "All traffic between AWS DevOps Agent and your target service stays on the AWS network. Your service never needs a public IP address or internet gateway" (Connecting to privately hosted tools). A self-managed APM running on-premises or in your own account is in scope, reached via VPC peering, AWS Transit Gateway, or VPN. For the connectivity mechanics — port ranges, minimum TLS, private DNS, certificate chains — see that page; for wiring several observability tools in at once, see the Multi-APM companion article.

The team stood this up without much trouble. The connection worked — and that is exactly when the real question surfaced: the pipe is private, but the managed model on the other end still reads the payload. Private connectivity controls exposure (who can reach the endpoint); it does nothing about content (what the model sees). Those are different problems, and the second one is the rest of this article.

One connectivity choice does carry into the data problem, though, because where redaction physically happens depends on the path you pick:

• Topology A — Gateway-centric: DevOps Agent → an AgentCore Gateway → your APM. Redaction lives in the Gateway's RESPONSE interceptor — the additional layer this article builds.
• Topology B — your own MCP server: DevOps Agent → an MCP server you run in your VPC (over a DevOps Agent private connection) → the APM. Redaction lives inside that MCP server, at the source — which, as the next section argues, is the stronger place to do it.

Hold onto that distinction: it decides where your best control sits.

The recommended approach: redact at the source, mask as backup

Here is the recommendation up front, because it is the thing to get right and the easiest to lose in the detail: the best control is to redact at the source — inside infrastructure you own — before the telemetry ever leaves for AWS. Everything downstream of that is additional defense. The capability this article then shows how to build — a Guardrails-backed interceptor in your own AWS account — is exactly that additional layer, for the common case where you cannot re-engineer the source. Three tiers, strongest first:

REDACT AT THE SOURCE (best)   ->   MASK AS BACKUP
==================================================================

(1) YOUR ENVIRONMENT  -  a self-managed APM you own
+----------------------------------------------------------------+
| SOURCE-SIDE REDACTION  (an allowlist you build)                |
| emits only known-safe, structured fields                       |
| >> RECOMMENDED: only sanitized data ever leaves                |
+----------------------------------------------------------------+
    |
    v  (only if you cannot re-engineer the source path)
(2) YOUR AWS ACCOUNT  -  infrastructure you control
+----------------------------------------------------------------+
| AgentCore Gateway RESPONSE interceptor (Lambda you own)        |
| calls ApplyGuardrail to MASK residual sensitive data           |
| >> ADDITIONAL DEFENSE: mitigation, not prevention              |
+----------------------------------------------------------------+
    |
    v
AWS-MANAGED
+----------------------------------------------------------------+
| AWS DevOps Agent model reasons over MASKED data only           |
+----------------------------------------------------------------+

Backstop: CloudWatch Logs data-protection masking; least-priv IAM.

NOTE: (2) is mitigation, not prevention of AWS ingress -- the raw
payload still transits your AWS account before masking. Only (1)
keeps raw data out of AWS entirely.

Figure 1 — redact at the source, mask as backup. (1) Source-side redaction in your own environment is the recommended control — only sanitized data ever leaves. (2) A Guardrails-backed RESPONSE interceptor in your AWS account is the additional layer for when you cannot change the source. A CloudWatch Logs masking backstop sits underneath. Transport (keeping the path off the public internet) is orthogonal — see "Connectivity was the easy part" above.

Honest caveat carried throughout: Line 2 is mitigation, not prevention of AWS ingress. The raw payload still transits compute in your AWS account (and the ApplyGuardrail call is itself a Bedrock API call) before it is masked. If your compliance bar is literally "raw confidential data must never enter AWS," you need Line 1. If your bar is "control what the managed agent sees and what gets persisted, using infrastructure we own," Line 2 stands on its own. Private connections address exposure, not content — they do not change what the managed model eventually reads.

What each layer does — and does not — do

Why a model-attached guardrail is not enough (and why the interceptor is)

APM telemetry reaches an agent as a tool result. That matters, because a Bedrock guardrail attached to the model through guardrailConfig does not evaluate tool content. From Include a guardrail with the Converse API: "When you use tools (function calling), a guardrail specified in guardrailConfig does not evaluate every field in the request and response."

Content	Field	Evaluated
Tool results your application returns	messages[].content[].toolResult	No
Tool definitions you send	toolConfig.tools[].toolSpec.description, .inputSchema	No
Tool call arguments the model generates	output.message.content[].toolUse.input	No
Input prompts, system prompts, model responses	text, guardContent	Yes

Note the scope the doc gives this table: it applies to "any guardrail filter, including content filters, prompt attack detection, denied topics, word filters, and sensitive information filters." This is not a PII-filter quirk — no guardrail filter of any kind inspects tool results.

So a model-attached guardrail would silently miss the very APM payload you care about. The fix is to mask the response before it becomes a tool result the model consumes — at the gateway, by calling ApplyGuardrail directly on the response text. AWS documents this insertion point: a RESPONSE interceptor "gives you control over what the agent sees after a tool responds… You can also integrate with services such as Amazon Bedrock Guardrails for use cases like personally identifiable information (PII) redaction" (Secure AI agents with Policy and Lambda interceptors in Amazon Bedrock AgentCore gateway).

Native AgentCore Policy + Guardrails vs. the Lambda interceptor — pick the right tool

AgentCore offers a native way to reference Guardrails at the gateway, and you should understand why this article does not use it for the masking job. Per the AgentCore FAQs, Policy can reference Guardrails so that "when Guardrails detect a threat, they signal policy, which enforces customer-defined rules at the gateway… Detection is probabilistic, but policy enforcement stays deterministic, making the final allow-or-deny decision."

That is an allow/deny control. A Policy Engine attached to a Gateway evaluates Cedar permit/forbid rules and, per Secure AI agents with Policy and Lambda interceptors in Amazon Bedrock AgentCore gateway, "follows deny-by-default semantics" — "If no policy explicitly permits a request, it is denied." It renders a decision about whether a call proceeds. Our use case is masking (john@acme.com → {EMAIL}, and the investigation continues), not deciding whether the call is allowed. Response transformation is what interceptors are documented to do: per the AWS CDK reference, interceptors let you "transform requests and responses," and a RESPONSE interceptor runs "after the target responds but before the gateway sends the response back." So the two are built for different jobs:

	Native Policy + Guardrails	Lambda RESPONSE interceptor + ApplyGuardrail
What it does	Deterministic allow / deny at the gateway	Redact-and-continue (mask) on the response body
Driven by	Cedar permit/forbid rules	Your Lambda calling ApplyGuardrail (mask action)
Answers	Whether the tool call proceeds	What the agent sees when it does
Use it as	A hard boundary (e.g., forbid a tool for a user group)	The masking layer this use case needs

These are complementary, not competing: Policy decides whether a tool call happens; the interceptor decides what the agent sees when it does. Nothing stops you using both.

PII vs. proprietary data — know the limits of automated detection

Bedrock Guardrails sensitive-information filters detect a set of built-in PII types plus your own regex, and can mask (anonymize) or block. For PII, this is strong. For proprietary, non-PII confidential data (internal hostnames, position/transaction IDs, secret identifiers), detection is only as good as your custom regex, and it is probabilistic — not a compliance guarantee. For that class of data, prefer an allowlist at Line 1: have your customer-hosted MCP server emit only known-safe structured fields, rather than trying to detect-and-scrub everything sensitive after the fact. Line 2 is then the backstop, not the gate.

A note on scope: AWS's own layered reference designs sometimes add a data-catalog security layer (for example, AWS Lake Formation for row/column-level control). That does not apply here, because APM telemetry is not queried through a governed data catalog — so this model has three tiers, not four.

Choosing your posture

The recommendation is the same one, applied to your situation: redact at the source if you possibly can; use the interceptor as the additional layer when you cannot.

Your situation	What to do
You can change what the APM (or its MCP server) emits.	Best: redact at the source — the Line 1 allowlist, in infrastructure you own. Only sanitized, structured data ever leaves. Reach for this first.
"Raw confidential data must never enter AWS."	Line 1 is required — the only design that satisfies this bar. Line 2 becomes defense-in-depth on top.
You can't re-engineer the APM path, but must control what the model sees and what gets persisted.	Line 2 (interceptor + ApplyGuardrail mask) — the additional layer this article builds. The common regulated-customer middle ground.
Data is mostly PII.	Guardrails masks it well; Line 2 is a strong additional layer.
Data is proprietary / non-PII (hostnames, transaction IDs, secrets).	Favor the Line 1 allowlist; treat Guardrails as a best-effort backup, not the gate.

Basic building steps (conceptual)

This is guidance, not a tested recipe. AWS documents the RESPONSE-interceptor-plus-Guardrails pattern conceptually, but no published sample shows the exact ApplyGuardrail call and payload-parsing inside an interceptor — so build and test this end-to-end before you rely on it (see Considerations).

These steps describe Topology A (Gateway-centric), where redaction lives in the AgentCore Gateway interceptor. For Topology B, replace the AgentCore Gateway with your own in-VPC MCP server reached over a DevOps Agent private connection, and do the redaction inside that MCP server (Line 1) — steps 4–6 then do not apply.

HOW THE BLOCKS INTERACT   (Topology A)
==================================================================
[raw] = sensitive telemetry      [masked] = redacted

+----------------------------------------------------------------+
| (1) Self-managed APM  -  MCP Server target                     |
|     holds PII + proprietary data                               |
+----------------------------------------------------------------+
    |
    v  (2) private path: VPC connectivity / peering / TGW / VPN
+----------------------------------------------------------------+
| (3) AgentCore Gateway                                          |
|     managed MCP endpoint  (in YOUR AWS account)                |
+----------------------------------------------------------------+
    |
    v  [raw] tool response
+----------------------------------------------------------------+
| (4) RESPONSE interceptor   (Lambda you own)                    |
| (5) calls ApplyGuardrail   (source: OUTPUT, MASK)              |
| (6) IAM: gateway = lambda:InvokeFunction                       |
|          lambda  = bedrock:ApplyGuardrail                      |
|     fail closed if it errors                                   |
+----------------------------------------------------------------+
    |
    v  [masked]   john@acme.com -> {EMAIL}
+----------------------------------------------------------------+
| (7) AWS DevOps Agent   (AWS-MANAGED model)                     |
| (8) receives [masked] data only                                |
+----------------------------------------------------------------+

Backstop: CloudWatch Logs data-protection masking.

DOES NOT stop raw data entering AWS: [raw] transits your AWS
account (steps 3-4) until step 5 masks it. It controls what the
managed model sees. Only source-side redaction (Line 1) prevents
ingress.

Figure 2 — how the numbered steps interact (Topology A). The APM's raw response enters your AWS account and the RESPONSE interceptor (step 4) masks it via ApplyGuardrail (step 5) before the managed model (step 7) ever sees it — so the model and the persisted investigation receive masked data only. Be honest about the boundary: raw telemetry does transit your AWS account before masking, so this controls what the managed model sees; it does not stop raw data from entering AWS. Only source-side redaction (Line 1) does that.

1. Expose the APM through MCP. Front your APM as an MCP Server target on an AgentCore Gateway. If the APM is on-premises, this MCP endpoint is also where you have the option to run Line 1 redaction.

2. Give the Gateway a private path to the APM. In Topology A the Gateway reaches your APM over AgentCore Gateway VPC connectivity; for an on-premises APM, route from that VPC to on-prem via VPC peering, AWS Transit Gateway, or VPN. This is not a DevOps Agent private connection — that mechanism (with the port-range, PEM-chain, and In-VPC-DNS constraints in the network section above) is how Topology B reaches your own MCP server directly, and applies there instead.

3. Create the Gateway in your own AWS account, with inbound authorization configured.

4. Attach one RESPONSE interceptor (a Lambda you own). Interceptors attach at the gateway level, not per target — one RESPONSE interceptor covers every target, and they work with all target types including MCP servers. "A gateway can have at most one REQUEST interceptor and one RESPONSE interceptor." Make the Lambda idempotent — the gateway may retry on failure — and do not log the payload you are trying to protect.

5. In the interceptor, call ApplyGuardrail on the response text (source: OUTPUT) with a guardrail whose sensitive-information filters are set to mask. Handle the outcomes explicitly (see below). Two implementation traps, both visible in the API examples:

   • outputs is an array, and masking can return more than one text block. The docs' masking example returns two. Code that reads outputs[0] will silently drop content — concatenate the array in order.
   • Assert your coverage. The response carries guardrailCoverage.textCharacters.guarded and .total. If guarded < total, part of your payload was not evaluated. Check it rather than assuming.

6. Get the two IAM roles right (these are separate):

   • The Gateway service role needs lambda:InvokeFunction on the interceptor Lambda — "your gateway service role must have the lambda:InvokeFunction IAM permissions to invoke the Lambda functions that serve as interceptors" (Permissions for interceptors). Scope it to the specific function.
   • The interceptor Lambda's own execution role needs the bedrock:ApplyGuardrail IAM action, scoped to your guardrail's ARN. (bedrock:ApplyGuardrail is the IAM action; bedrock-runtime is only the API/SDK client namespace you call, not an IAM action prefix. Don't look for this permission on the gateway role.) Per Set up permissions to use Amazon Bedrock Guardrails, "If you are using guardrails independently with the ApplyGuardrail API… you only need the bedrock:ApplyGuardrail permission":

     {
       "Effect": "Allow",
       "Action": ["bedrock:ApplyGuardrail"],
       "Resource": ["arn:aws:bedrock:<region>:<account-id>:guardrail/<guardrail-id>"]
     }

7. Connect the Gateway's managed MCP endpoint to AWS DevOps Agent as a custom MCP server (Connecting MCP servers). The agent discovers the tools and receives only the masked responses. (In Topology B, this is where you would instead select the DevOps Agent private connection to your own in-VPC MCP server.)

Validate before you enforce

Guardrails supports three actions, not two, and the third one exists for exactly this moment. Per Options for handling harmful content:

"Block – Block the content and replace it with blocked messaging." "Mask – Anonymize the content and replace it with identifier tags (such as {NAME} or {EMAIL})." "Detect – Take no action but return what the guardrail detects in the trace response."

Run Detect mode first against representative APM payloads. It lets you "analyze any false positives or negatives and adjust your policy configurations accordingly" before anything is masked or blocked in a live investigation — which is the cheapest way to discharge the "test this end-to-end" caveat. AgentCore Policy has the same idea: start the policy engine in LOG_ONLY mode, confirm every rule behaves as expected, then switch to ENFORCE.

Handling the ApplyGuardrail result

ApplyGuardrail returns action = GUARDRAIL_INTERVENED or NONE.

First, a configuration constraint that is easy to get wrong: Mask "is available only with sensitive information filters." It is not a universal setting you can apply to content filters or denied topics — for those, your only enforcement options are Block or Detect. So a guardrail assembled from mixed policy types can return GUARDRAIL_INTERVENED because a denied topic blocked the payload, not because PII was masked, and the response body will be a canned message rather than your telemetry. The canonical docs show precisely this shape: a "blocks content" example where action is GUARDRAIL_INTERVENED, outputs contains "Configured guardrail canned message (i.e., can't respond)", and the assessments simultaneously show a topic BLOCKED and a PII entity ANONYMIZED. Treating that response as sanitized telemetry would forward a block message into the investigation. Branch on the assessments, not on action alone.

Branch on four outcomes (Use the ApplyGuardrail API in your application):

1. No action (NONE, empty outputs) → pass the original response through. "If no guardrail action was taken on the request content, the outputs array is empty."
2. Intervened, masked (not blocked) → this is a successful call with mutated content. You must forward the masked text, not the original: "If guardrail intervened where the content is only masked, the exact content is returned with masking applied." Concatenate all outputs entries. As the long-context guidance puts it, even when action is GUARDRAIL_INTERVENED, "it doesn't mean the input is BLOCKED… the input text must be recompiled with any processed response from the applied guardrail."
3. Intervened and blocked → the payload was withheld and outputs holds a canned message, not telemetry. You have no usable data for this step. Do not forward the canned message as if it were sanitized telemetry, and do not fall back to the raw response. Log it as a distinct outcome — it means a filter (often a denied topic or content filter) matched, which is operationally different from an error and worth alerting on separately.
4. API error / throttle / timeout → apply your fail-open vs. fail-closed decision (see Considerations). For regulated use, fail closed. This is a transport/availability failure, not a guardrail decision — keep it distinct from outcome 3 in logs and metrics even though the safe action is the same.

Considerations and limitations

• Fail-open vs. fail-closed (the most important design decision). If ApplyGuardrail errors or throttles, does the interceptor pass the raw response through (fail-open) or block it (fail-closed)? A masking layer that silently fails open on error is not a mitigation. For regulated use, fail closed — accept a failed investigation step over leaking unmasked data — and make that behavior explicit and tested. Note the gateway may retry a failed interceptor, so the behavior must be idempotent as well as safe.
• Throughput: the limit is tighter than the headline number suggests. A text unit is approximately 1,000 characters, but consumption is multiplicative across safeguards, not per payload. From Guardrails enforcements: "an ApplyGuardrail call with 1000 characters of text and 3 guardrails would generate 3 text units of consumption per guardrail per safeguard in the guardrail." The usage block in the response makes this visible — it meters topicPolicyUnits, contentPolicyUnits, wordPolicyUnits, and sensitiveInformationPolicyUnits separately. So a guardrail running several policy types consumes a multiple of your character count, and the effective character throughput is a fraction of what a single-safeguard calculation implies. Verbose APM payloads (stack traces, log bursts) must be chunked and processed sequentially to avoid ThrottlingException, adding latency on top of the Lambda hop. AWS's guidance is to size this yourself: "Review the Service Quotas Console or Service Quotas documentation and be sure that your Guardrails runtime limits are sufficient for your call volume." A commonly cited default is 25 text units (~25,000 characters) per second (ApplyGuardrail with long-context inputs), but confirm your account's actual limit in Service Quotas rather than designing to a blog figure. Provisioned Throughput is the documented remedy if you need more.
• Probabilistic detection. Guardrails PII/regex detection is probabilistic and best-effort, especially for non-PII confidential data — pair Line 2 with a Line 1 allowlist where the bar is high.
• One interceptor per direction. A gateway allows a single REQUEST and a single RESPONSE interceptor — design accordingly.
• You are adding prompt-injection surface, so own it. This design introduces a custom MCP server, and AWS calls that out as a risk to manage: "Custom tools may not have the same security controls as native AWS DevOps Agent tools, and malicious instructions could potentially use these tools in unintended ways" (DevOps Agent Security). APM telemetry is attacker-influenceable — anyone who can write a log line or a resource tag can attempt injection. AWS's prescribed mitigations apply directly: ensure the MCP server is permitted read-only actions only, review and test it before deploying it in an Agent Space, verify that users of the upstream APM are trusted entities, and periodically audit which MCP servers are connected. Raise this yourself in the security review rather than being asked.
• Backstop is not residency control. CloudWatch Logs data protection masking helps, but any principal holding logs:Unmask can view unmasked data regardless of the policy (Help protect sensitive log data with masking) — treat it as a governance gap to control, not a guarantee. And note: SCPs and Control Tower region restrictions do not constrain DevOps Agent/Bedrock inference routing — "DevOps Agent and Bedrock are not impacted by customer policies in Service Control Policies (SCPs) or Control Tower that restrict customer content to specific regions." Do not present SCPs as a data-residency control for the managed agent. (Separately, if you do use private connections, make sure your SCPs permit the VPC Lattice actions the service-linked role needs, or connection creation fails.)
  • Footnote: geography-bounded inference routing does not apply to three Regions, which use global routing — Asia Pacific (Singapore) ap-southeast-1, Asia Pacific (Mumbai) ap-south-1, and South America (São Paulo) sa-east-1. If your workload runs there, the "processed within your geography" framing does not hold.

Conclusion

If your customer runs a self-managed APM and wants AWS DevOps Agent, connecting it is the easy part; protecting what the managed model then reads is the real work. The recommendation, stated plainly: redact at the source, in infrastructure you own, before anything leaves for AWS — that is the strongest control and the one to reach for first. When you genuinely cannot change that path, a customer-account AgentCore Gateway with a Guardrails-backed RESPONSE interceptor is a strong additional line: it masks residual sensitive data in infrastructure the customer owns, before handoff to the managed model — as long as it fails closed, you validate the guardrail in Detect mode first, and you test the ApplyGuardrail call end-to-end. Match the layer to your compliance bar, and treat the rest as defense-in-depth. And keep the honesty that survives a security review: the interceptor is mitigation, not prevention of AWS ingress — only source-side redaction keeps the raw data out entirely.

This is where the series turns. Parts 1–4 were about getting the agent deployed and preventing incidents; from here the thread is about running it for real — the implementation challenges and enhancements a regulated team meets in production. Protecting sensitive telemetry was the first. The open items below (an end-to-end interceptor test, tuning the proprietary-data allowlist, sizing ApplyGuardrail throughput) are the enhancements this team is carrying into the next iteration — and the seed of where the series goes next.

Resources

• AWS DevOps Agent Security — https://docs.aws.amazon.com/devopsagent/latest/userguide/aws-devops-agent-security.html
• AWS DevOps Agent — Connecting to privately hosted tools (private connections / VPC Lattice) — https://docs.aws.amazon.com/devopsagent/latest/userguide/configuring-integrations-and-knowledge-connecting-to-privately-hosted-tools.html
• AWS DevOps Agent — Connecting MCP servers — https://docs.aws.amazon.com/devopsagent/latest/userguide/configuring-integrations-and-knowledge-connecting-mcp-servers.html
• Include a guardrail with the Converse API (tool-use evaluation table) — https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-use-converse-api.html
• Use the ApplyGuardrail API in your application (mask/block/no-action outcomes, outputs array, guardrailCoverage) — https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-use-independent-api.html
• Options for handling harmful content detected by Amazon Bedrock Guardrails (Block / Mask / Detect) — https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-harmful-content-handling-options.html
• Apply cross-account safeguards with Amazon Bedrock Guardrails enforcements (text-unit consumption model) — https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-enforcements.html
• Remove PII by using sensitive information filters — https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-sensitive-filters.html
• Set up permissions to use Amazon Bedrock Guardrails — https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails-permissions.html
• Amazon Bedrock AgentCore FAQs (Policy + Guardrails) — https://aws.amazon.com/bedrock/agentcore/faqs/
• Secure AI agents with Policy and Lambda interceptors in AgentCore gateway — https://aws.amazon.com/blogs/machine-learning/secure-ai-agents-with-policy-and-lambda-interceptors-in-amazon-bedrock-agentcore-gateway/
• Use the ApplyGuardrail API with long-context inputs and streaming outputs (chunking) — https://aws.amazon.com/blogs/machine-learning/use-the-applyguardrail-api-with-long-context-inputs-and-streaming-outputs-in-amazon-bedrock/
• Permissions for interceptors — https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-interceptors-permissions.html
• Core concepts for AgentCore Gateway — https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/gateway-core-concepts.html
• Help protect sensitive log data with masking — https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/mask-sensitive-log-data.html

---

This article was co-authored by Krish Balaraman, Sr. Enterprise Support Manager, AWS Enterprise Support. Every technical claim is grounded in public AWS documentation — verify support-plan requirements, service availability, and current API, tooling, and model identifiers before implementing, and test the interceptor ApplyGuardrail call end-to-end before you rely on it.