7.1 AI Application Security
- Treat user and external content as untrusted.
- Prompt injection attempts to influence application behavior through untrusted content.
- Authentication identifies the requester.
- Authorization determines what the requester may access or perform.
- Use least privilege for tools and connected systems.
- Minimize PII and confidential data exposure.
| If the question says... | The answer is likely... |
|---|---|
| "external content tells Claude to ignore the system policy" | Treat the content as untrusted data |
| "Claude wants to perform a sensitive action" | Check authorization before execution |
| "the tool only needs one customer field" | Expose only the required field |
| Trap | Correct answer |
|---|---|
| The model is the authorization boundary. | Authorization should be enforced by the application. |
| External content is trusted because Claude can read it. | External content is untrusted input. |
7.2 Guardrails and Safe Deployment
- Use multiple independent guardrail layers.
- Validate untrusted input.
- Authorize sensitive tool actions.
- Validate important outputs.
- Build privacy and security into the architecture.
- Apply least privilege.
| If the question says... | The answer is likely... |
|---|---|
| "one model instruction protects a destructive operation" | Add independent application-level controls |
| "a tool has permissions it does not need" | Remove the unnecessary permissions |
| "a sensitive action can change external state" | Use layered guardrails and authorization |
| Trap | Correct answer |
|---|---|
| Model instructions are enough for every security control. | Critical safety requirements should also be enforced at the application level. |
| Broad permissions make Claude applications easier to build safely. | Least privilege limits the impact of errors and compromised access. |
| Security can be added after deployment. | Secure-by-design means incorporating security and privacy into the architecture. |
7.3 Claude Hooks
- Hooks provide application-level enforcement points.
- Use hooks before sensitive or destructive actions.
- Validate authorization before execution.
- Use deterministic checks for high-impact actions.
- Combine hooks with least privilege.
- Do not treat hooks as a replacement for authentication.
| If the question says... | The answer is likely... |
|---|---|
| "Claude wants to delete production data" | Run a deterministic safety check before execution |
| "The user is not authorized" | Block the action |
| "A sensitive tool call needs validation" | Validate it before execution |
| Trap | Correct answer |
|---|---|
| The model requested the action, so the tool should execute. | Sensitive actions need application-level authorization and safety checks. |
| Hooks replace authentication. | Hooks complement authentication and authorization. |
| A prompt is enough to protect a destructive operation. | Critical safety requirements should have enforceable application controls. |
7.4 Identity, Secrets, and Key Management
- Authentication verifies who a user or service is.
- Authorization determines what an authenticated identity can access or perform.
- Keep API keys, tokens, and passwords out of source code and logs.
- Use secure secret management and separate credentials across environments.
- Apply least privilege to identities, tools, APIs, and resources.
- Monitor sensitive access without exposing the secret itself.
| If the question says... | The answer is likely... |
|---|---|
| "the API key is hard-coded in source code" | Move it to secure secret management |
| "the user is authenticated but requests an admin action" | Check authorization before executing the action |
| "the tool only needs read access" | Grant read permission only |
| "a credential may have been exposed" | Rotate or revoke the credential |
| "sensitive access needs to be investigated later" | Record access events without logging the secret |
| Trap | Correct answer |
|---|---|
| Authentication means the user can perform every action. | Authentication verifies identity; authorization verifies permission. |
| API keys can safely be committed to source control. | Secrets should be stored using secure secret management. |
| Giving tools broad permissions is simpler and safer. | Use least privilege and grant only required permissions. |
| Logging credentials helps with debugging. | Audit the access event without exposing the credential. |