Policies like a data sensitivity matrix tell people what they may send to Claude. Input controls make the answer automatic: technical measures that filter, mask, or block content before it becomes part of a prompt. They matter because prompts are assembled by software as often as by people — a retrieval pipeline that pulls the wrong document sends sensitive data to the model without any human deciding to.
Three layers, from cheapest to most thorough
Layer 1: access control on the data source. The most reliable filter is the one your systems already enforce. If your retrieval layer queries documents using the end user's permissions rather than a privileged service account, content the user cannot see never reaches the prompt. Most retrieval-augmented (RAG) leakage incidents are permission bugs wearing an AI costume.
Layer 2: field-level filtering at prompt assembly. Build prompts from explicit allowlists of fields, not from serialized whole records. A ticket-summarization service needs the ticket title, body, and status — it does not need the customer's email address, and if the field never enters the template, it cannot leak. This is a code-review rule as much as a technology: reject any pull request that passes an entire database row into a prompt template.
Layer 3: detection and masking on the assembled prompt. As a last line, scan outgoing prompt text for patterns that should not be there — credential formats, card-number patterns, national ID formats — and mask or block before sending. Deterministic scanners are fast and predictable; keep them in your own code path so the same gate applies whichever platform serves the request. On Amazon Bedrock you can additionally attach the platform's guardrail features (see Bedrock guardrails for PII); treat platform features as reinforcement for your own gate, not a replacement.
from anthropic import AnthropicBedrockMantle
import re
BLOCK = [re.compile(r"sk-ant-[A-Za-z0-9-]+"), # API keys
re.compile(r"\b\d{13,16}\b")] # card-like numbers
def guarded_prompt(text: str) -> str:
for pattern in BLOCK:
if pattern.search(text):
raise ValueError("blocked: sensitive pattern in prompt")
return text
client = AnthropicBedrockMantle(aws_region="us-east-1")
msg = client.messages.create(
model="anthropic.claude-sonnet-5", max_tokens=1024,
messages=[{"role": "user", "content": guarded_prompt(user_text)}])Fifteen lines will not catch everything — the point is architectural: every request passes one chokepoint you control, so tightening policy later means editing one function.
Segment workloads so controls can differ
Not every workload deserves the same strictness, and platform features help you separate them. On the Claude API and Claude Platform on AWS, workspaces let you separate projects and teams while keeping centralized billing and administration; API keys are scoped to a single workspace, so a key issued for the low-sensitivity marketing assistant physically cannot spend under the customer-data workspace. Anthropic documents a limit of 100 workspaces per organization, with per-workspace spend and rate limits settable below the organization's own. On Bedrock, Vertex AI, and Foundry, the equivalent segmentation is your cloud's native scoping — separate accounts or projects, IAM roles, and service accounts per workload (see least-privilege IAM).
What input controls cannot do
Be honest about limits. Pattern-based masking misses sensitive content that does not match a pattern — a paragraph describing a person's health condition contains no regex-able token. Free-form employee chat is the hardest surface: there, access control and training carry more weight than scanning. And input controls say nothing about what happens after the model responds; that is the job of output controls, the subject of the companion article.
Also remember that blocking data from prompts is separate from what the platform retains once data does arrive. Anthropic's stated default for the Claude API is deletion of inputs and outputs within 30 days, with zero-data-retention arrangements available contractually; on Bedrock and Google Cloud the cloud provider is the data processor and its policies apply. Input controls reduce what those policies ever have to cover — which is precisely their value.
Where to go next
Pair this with output controls and a PII redaction pipeline pattern, and see the platform overview for how each cloud scopes credentials.