Anthropic Application & API Security interview questions

A browsing tool is a URL fetcher whose destination is chosen by text anyone can write. The interviewer wants the defences in the tool and the network, not the prompt.

The model is not the attacker, but whoever wrote the document it just read might be. Every argument in a tool call is untrusted input.

File tools take paths from the model, and the model takes ideas from whatever it read. A string check for '..' is not confinement.

The model did not write malicious HTML on its own; a web page it summarised did. Then the conversation was shared, and the renderer trusted it.

Generated code ships faster, which is the point and the risk. The scored answer names the specific failure modes and keeps the normal controls working at the new speed.

An LLM reviewer reads every change, which no human team can, and is confidently wrong some of the time. The scored answer places it as a triage layer, measures it, and protects it from the code it reads.

A classic coding round with a security twist: the crawler fetches URLs that strangers wrote. The scored answer gets concurrency right, then adds scope, limits and SSRF protection.

The model's guess is cheap; the proof is what matters. Strong answers describe the oracle that turns a hypothesis into evidence, and the triage that keeps maintainers from drowning.

A patch that makes the scanner go quiet is not the same as a patch that fixes the bug. The interview is about how you would tell the difference at scale, and what the tool itself can be tricked into doing.

Three bugs, one cause. The answer that scores names the cause, explains why parameters are structural, and lands on why prompts have no parameters.

'Sanitise input' is the answer that fails. The interviewer wants encoding at the point of output, for the specific context, with CSP behind it.

Reading files top to bottom finds style issues. A security review starts from sources, sinks and the checks between them, and AI code adds a new source.

Scanners rarely find it, because every request looks valid. Finding it at scale is a testing design problem, not a scanning problem.

Three browser rules that candidates mix up constantly. The JWT follow-up exposes whether you know which one depends on cookies.

The format is the bug. JSON cannot call functions; pickle is designed to. The AI version is the model checkpoint you just downloaded.

A strict CSP blocks many XSS payloads but not all, and DOM XSS has paths it cannot see. The scored answer explains what a nonce-based policy stops, where it fails, and why Trusted Types targets the DOM sinks.

Work through tenant, role, object and field checks, then extend the review to bulk exports, permission changes and resource budgets with executable acceptance cases.

Verify the sender protocol, persist recoverable intake, distinguish delivery retries from business effects, and work through two offline fixtures and crash boundaries.

Two injection classes where a parser or template engine does far more than the developer intended. The scored answer explains the dangerous feature in each and turns it off.

Model a bounded reservation workflow, run an offline invariant fixture, and reason about retries, contention, immutable intent and uncertain external outcomes.

Each tool sees the application from a different angle and has a blind spot where another looks. The scored answer maps bug classes to tools and builds a pipeline that does not drown developers.

Small requests that trigger large work are the cheapest denial of service. The scored answer finds the multipliers, bounds every one, and adds the AI-era ones.

The commonest serious bug in AI tools is the oldest: fetching an object by ID without checking who is asking. The scored answer finds it, fixes it at the data access, and tests across users and tenants.

Two servers disagree about where one request ends and the next begins. The scored answer explains the ambiguity, what an attacker gains, and why consistent parsing and HTTP/2 end to end fix it.