How to Apply DLP Policies by Integrating Amazon Bedrock Guardrails with Claude Enterprise

Uses Claude Enterprise Inference hooks to route requests to the organization's decision server, applying custom rules (Stage-1) and Amazon Bedrock Guardrails (Stage-2) sequentially to block DLP violations
Korea-specific identifiers (resident registration numbers, business registration numbers) and internal security markings (Confidential) are not supported by Guardrails and are checked via custom rules, while PII and prompt attacks are detected by Guardrails
In a 5-turn conversation test, the body size increased from 736 bytes to 4,399 bytes, but incremental checks prevent cost and throughput quota reuse, with server processing times measured at 586–1,292 ms
The decision server is deployed in an isolated subnet based on AWS Fargate, applying a security group that allows only the Anthropic egress range (160.79.106.0/24) and Standard Webhooks signature verification

Architecture and Security Configuration

Uses an ALB as the internet entry point, blocking forged requests through X-Hook-Token header and HMAC-SHA256 signature verification
Bedrock calls are restricted to PrivateLink only, with endpoint policies allowing only ApplyGuardrail
In case of failure, a fail-closed policy blocks requests, and the circuit breaker begins automatic recovery checks after 10 minutes

If rejection conditions are met in Stage-1, Stage-2 is skipped to reduce cost and latency, and Guardrails results cannot be changed to allow
Limitations exist, including the inability to inspect original images in attachments, difficulty in handling obfuscation, and the possibility of bypassing criteria when distributed across multiple turns
Inference hooks configuration is currently only possible in claude.ai organization settings, with change history viewable via the Compliance API Activity Feed