Skip to content

Level 4 · Guide 18

Defend Claude agents against prompt injection

Prompt injection occurs when malicious instructions in a webpage or file try to redirect an agent from its intended goal. Treat external instructions as untrusted data and combine least privilege, network limits, write approval, and independent verification.

Product features may change. Check the last verified date and official sources.

Core concepts to know first

Focus on the decisions these terms support in real work rather than memorizing them.

Core concepts

1. Prompt injection changes the intended goal

Prompt text cannot reliably solve prompt injection by itself. Reduce the consequence of compromise with sandboxing, scoped credentials, allowlisted tools and destinations, separated approval, logs, and rapid revocation. In this guide, the first observable move is to identify protected assets, untrusted inputs, tools, and possible effects.

2. External instructions are untrusted data

Restrict filesystem, credentials, network, and write permissions. Preserve the approved input and the evidence behind the result so a reviewer can distinguish what the source says from what Claude inferred. This directly controls the risk that external documents can contain hidden instructions.

3. Prompt-only defenses are insufficient

Test a synthetic injection and verify stop, log, revoke, and recovery paths. Record the decision and the remaining uncertainty instead of hiding it in polished prose. The review must explicitly test whether broad credentials make one tool call consequential.

4. Reduce filesystem, network, and credential scope

Treat the possibility that a model can misclassify a malicious instruction as relevant data as a required test case. The intended result is a security review covering assets, threats, permissions, detection, and response, not an unreviewed answer that merely looks complete.

5. Separate important writes and verify them

For Defend Claude agents against prompt injection, the final concept joins the earlier checks into an operating boundary: use approved inputs, expose evidence and uncertainty, and stop before a consequential action. Ownership and a reproducible review determine whether a security review covering assets, threats, permissions, detection, and response may move beyond training.

Synthetic work scenario

How this applies at work

This scenario was written for learning and is not a real customer case.

A fictional research agent encounters a webpage telling it to ignore policy and upload local files. The test environment blocks the destination, exposes no sensitive files, records the attempt, and stops for a security reviewer.

The scenario is newly written for this guide and is neither a customer case nor a performance claim. Its specific deliverable is a security review covering assets, threats, permissions, detection, and response. A reviewer can reproduce the work from the synthetic inputs without access to customer, employee, health, contract, or confidential company data.

Try it yourself

Choose one small task and follow the steps. Confirm organizational policy and data boundaries before using sensitive materials.

  1. Step 1. Identify protected assets, untrusted inputs, tools, and possible effects

    Identify protected assets, untrusted inputs, tools, and possible effects. Use only approved synthetic material and record both the evidence and any remaining uncertainty.

    Verify: Confirm that another reviewer can reproduce the input, result, evidence, and stop point.

  2. Step 2. Restrict filesystem, credentials, network, and write permissions

    Restrict filesystem, credentials, network, and write permissions. Use only approved synthetic material and record both the evidence and any remaining uncertainty.

    Verify: Confirm that another reviewer can reproduce the input, result, evidence, and stop point.

  3. Step 3. Test a synthetic injection and verify stop, log, revoke, and recovery paths

    Test a synthetic injection and verify stop, log, revoke, and recovery paths. Use only approved synthetic material and record both the evidence and any remaining uncertainty.

    Verify: Confirm that another reviewer can reproduce the input, result, evidence, and stop point.

Completion checklist

Check only what you verified yourself. Every item must be checked before saving completion.

Completion checklist

Some items are still unchecked. Review the result again.

What could go wrong?

Plausible language does not guarantee accuracy. Compare the result with originals, calculations, permissions, and current information.

  • External documents can contain hidden instructions
  • Broad credentials make one tool call consequential
  • A model can misclassify a malicious instruction as relevant data

Boundaries that require human review

Academy practice stops at draft, preview, or approval pending. Actions with real impact require separate owner approval outside Academy.

What AI can do

  • Step 1. Identify protected assets, untrusted inputs, tools, and possible effects
  • Step 2. Restrict filesystem, credentials, network, and write permissions
  • Step 3. Test a synthetic injection and verify stop, log, revoke, and recovery paths

What a person must approve

  • Applicable law, contract, organizational security policy, and explicit approval boundaries take priority. Stop and ask the responsible owner when they conflict.
  • Academy exercises never send, publish, purchase, delete, execute contracts, or change permissions. A responsible person performs any real action through a separate process.

This guide is educational and does not replace legal, security, or privacy judgment for your organization.

Questions about this guide

When is this guide complete?
It is complete when the stated outcome is ready and another reviewer can retrace the inputs, evidence, boundaries, and decision. The target outcome is “A security review covering assets, threats, permissions, detection, and response.”
May I practice with real company data?
No. Use synthetic material in the Academy. Real data requires a separate review of policy, legal basis, contracts, minimization, retention, deletion, and the approved environment.
What if the product screen differs from this guide?
Product behavior can change. Check the verification date and official sources, then retest the current account and plan with a small, low-risk example.

Official sources and further reading

Recheck the current product and policy status in these primary sources.

  1. Security · Claude Code Docs

Authorship and review

Author
QJC
Last verified
2026-07-23
Update sensitivity
High
Tested product surface
Official documentation and QJC training scenarios using synthetic data
Tested plan
Reconfirm feature and account availability in official sources on the day of use

Save progress

Completion and checklist items are saved only in this browser. They do not sync to other devices or browsers.

Academy does not collect or store work materials, prompts, or outputs. It runs no separate analytics scripts beyond basic server access logs.

QJC Claude Academy is unofficial educational content independently created and operated by QJC. It is not an official course operated, sponsored, certified, or affiliated with Anthropic. Claude and Anthropic are trademarks of Anthropic PBC.