Document features often fail because the application treats an upload as harmless text. A file can contain sensitive information, prompt-injection attempts, stale policy, or content the current user is not allowed to see. The useful design work is deciding who may upload, how the file is classified, when it expires, and what evidence an answer must expose.
This lesson separates file lifecycle from model reasoning. Your server uploads approved content, stores only the needed file reference and metadata, sends it with a narrowly scoped request, and removes it according to a retention policy. A document answer remains a proposal until your application verifies its citations and permissions.
| Lifecycle point | Decision | Application evidence |
|---|---|---|
| Upload | Is this user allowed to submit this type of file? | Owner, content type, scan result, and product policy. |
| Reference | May this job use this file now? | Workspace record, purpose, expiration, and access check. |
| Analysis | What may Claude extract or answer? | A bounded task and a review threshold. |
| Deletion | When must the file become unavailable? | Retention policy, deletion record, and related job cleanup. |
A file ID is not an access-control system. Store tenant, owner, purpose, data classification, and expiration in your own database before the document can be selected for a model request. Re-check the authenticated user against that record each time.
Do not accept a browser-provided file ID as proof that the current user may use it.
Use an upload pipeline that can reject unsupported types, excessive size, malware signals, and files that do not belong to the current workflow. The exact scanning tools depend on your environment, but the control belongs before the model request.
Keep raw uploads, extracted text, and derived chunks under the same deletion and retention policy.
When you request an answer, state the purpose and require source references to the supplied document. A good assistant can say that the material does not support the requested conclusion. This protects users from polished guesses based on partial evidence.
External document content is untrusted instruction, even if the document looks official. Keep application rules outside the file content.
Lifecycle work is product work. Build an owner-visible status for uploaded files, schedule expiration, and make deletion propagate to any index, cache, or object store you created. Test deletion like you test an authorization change.
Review the current API retention and privacy documentation before committing to a workflow.
A document feature needs a lifecycle, not only an upload button. Decide who may upload, which workspace owns the file, where the file ID is recorded, when it may be reused, and when it must be deleted. The Files API can avoid sending the same supported file with every request, but it does not replace your product’s access and retention rules.
Build the feature around a document job: validate the upload, create or reference the file, run one bounded analysis, capture the source and result, and delete it according to policy. Treat a file ID as sensitive application data; it is not a public URL.
The upload belongs in a controlled server process after your application has authorized the document.
from anthropic import Anthropic
client = Anthropic()
with open("approved-policy.pdf", "rb") as document:
uploaded = client.beta.files.upload(
file=("approved-policy.pdf", document, "application/pdf"),
)
print(uploaded.id)Your application checks ownership before it creates a request that references a file.
file_record = {"id": "file_123", "tenant": "acme", "expires_on": "2026-08-01"}
def may_use_file(record: dict, tenant: str) -> bool:
return record["tenant"] == tenant
print(may_use_file(file_record, "acme"))
print(may_use_file(file_record, "other"))True
FalseThe SDK file operation returns an ID you can save with your own document record. Use the Files API beta only where it is available for your deployment.
from anthropic import Anthropic
client = Anthropic()
with open("policy.pdf", "rb") as policy_file:
uploaded = client.beta.files.upload(
file=("policy.pdf", policy_file, "application/pdf"),
)
print(uploaded.id)A small application rule prevents a file from being reused when its owner, retention date, or approval state is no longer valid.
from datetime import date
def may_use_file(owner_matches: bool, expires_on: date, today: date) -> bool:
return owner_matches and today <= expires_on
print(may_use_file(True, date(2026, 8, 1), date(2026, 7, 27)))
print(may_use_file(False, date(2026, 8, 1), date(2026, 7, 27)))True
FalseA lifecycle mapping exercise
0 of 2 completed
Yes when the current API and your own retention policy permit it, but re-authorize the new use and track its lifecycle.
No. You still need a scoped request, evidence or citations, and evaluation for supported versus unsupported claims.
Explore 500+ free tutorials across 20+ languages and frameworks.