What Claude Actually Is
Claude is not “an AI chatbot.” That label is technically accurate and operationally useless — like calling a SIEM “a database with alerts.” To use Claude effectively, you need to understand what it actually does, how it processes your input, and where its boundaries are.
This module gives you the operational mental model. Not a computer science lecture — the practical knowledge that determines whether Claude produces something useful or something confidently wrong.
Claude is a large language model built by Anthropic
Claude is built by Anthropic, a San Francisco-based AI safety company founded in 2021 by former OpenAI researchers. The name matters for one reason: Anthropic’s approach to safety and alignment directly affects how Claude behaves. Claude will refuse certain requests, add caveats to sensitive topics, and sometimes err on the side of caution in ways that other models do not. This is by design, not a bug.
What Claude does: Takes text input (your prompt), processes it through a neural network trained on a large corpus of text data, and generates text output (the response). It predicts the most likely next sequence of tokens based on the input, its training data, and its instruction tuning.
What this means operationally: Claude does not “know” things the way a human does. It has learned statistical patterns from training data. When it generates a KQL query, it is not looking up the KQL specification — it is generating tokens that are statistically likely to follow the pattern of correct KQL based on all the KQL it saw during training. This is why it can produce syntactically perfect KQL that references a table column that does not exist.
The model tiers: Haiku, Sonnet, Opus
Anthropic offers three model tiers. Choosing the right one for the task is the first decision that affects output quality.
Claude Haiku — The fastest and cheapest model. Best for: simple classification, quick summaries, formatting tasks, and high-volume processing where speed matters more than depth. In a security context: parsing structured log output, reformatting data, or answering straightforward factual questions. Haiku is the model you use when you need a quick answer and the task is not complex.
Claude Sonnet — The balanced model. Best for: most day-to-day work including writing, analysis, code generation, and multi-step reasoning. In a security context: writing KQL queries, drafting IR report sections, analysing sign-in log patterns, generating detection rule logic. Sonnet is the default choice for professional work. It handles complexity well without the cost or latency of Opus.
Claude Opus — The most capable model. Best for: complex reasoning, nuanced analysis, long-form writing, and tasks where quality matters more than speed. In a security context: reconstructing a complex attack timeline from multiple data sources, writing a comprehensive post-incident review, analysing a novel phishing technique, or generating a complete investigation playbook. Use Opus when the task requires deep thinking.
Practical guidance: Start with Sonnet for everything. Move to Haiku if you need speed on simple tasks. Move to Opus if Sonnet’s output is not deep enough. Most professional work sits comfortably in Sonnet.
KQL query generation: Sonnet. Investigation analysis: Sonnet (enable Extended Thinking for complex cases). IR report drafting: Sonnet or Opus. Policy generation: Sonnet. Bulk log parsing/formatting: Haiku. Complex multi-source attack timeline reconstruction: Opus. The cost difference between Sonnet and Opus matters at API scale but is invisible in claude.ai — choose based on output quality, not cost.
Try it yourself
Sonnet produces a solid, accurate explanation covering the proxy mechanism, session cookie theft, and key SigninLogs fields. Opus produces the same but adds nuance: edge cases in detection, the difference between interactive and non-interactive token replay, and specific CAE considerations. For most daily work, Sonnet's answer is sufficient. For investigation briefings or training material, Opus's depth is worth the wait.
Context windows — what Claude can hold in its head
The context window is the total amount of text Claude can process in a single conversation — your input plus its output combined. Think of it as working memory.
Current context windows (March 2026):
| Model | Context Window |
|---|---|
| Haiku 4.5 | 200,000 tokens (~150,000 words) |
| Sonnet 4.6 | 200,000 tokens (~150,000 words) |
| Opus 4.6 | 200,000 tokens (~150,000 words) |
200,000 tokens is roughly 150,000 words — equivalent to a 500-page book. In practice, this means you can paste an entire IR report, a 30-page policy document, or several thousand lines of log data into a single prompt and Claude can process it.
Why the context window matters for security work:
You can paste an entire set of sign-in logs (thousands of rows) and ask Claude to identify anomalies. You can upload a 50-page compliance framework and ask Claude to map your controls against it. You can provide a complete email thread (headers included) and ask Claude to analyse the authentication chain.
Where the context window fails: Even with 200K tokens, Claude’s attention degrades over very long inputs. Information in the middle of a very long document is processed less reliably than information at the beginning or end. This is called the “lost in the middle” problem. For critical analysis, place the most important content at the beginning or end of your prompt.
Token vs word: A token is roughly 0.75 words in English. “Authentication” is 3 tokens. “KQL” is 1 token. Code and technical content tend to use more tokens per word than prose. When working with large log datasets, expect roughly 1 token per word of log text.
Knowledge cutoff — what Claude knows and does not know
Claude’s training data has a cutoff date. It does not have access to information published after that date unless it uses web search.
Current knowledge cutoff: End of May 2025.
This means Claude reliably knows about: Microsoft security features released before June 2025, KQL syntax and functions available before June 2025, MITRE ATT&CK framework versions published before June 2025, and general cybersecurity concepts, attack techniques, and best practices established before that date.
This means Claude may NOT know about: new Defender features released after May 2025, KQL functions introduced in recent Sentinel updates, new CVEs and threat actor campaigns from the last year, or changes to Microsoft licensing and product naming.
Operational impact: When Claude generates a KQL query, verify the table and column names against your actual Sentinel environment. When Claude describes a Defender feature, check the current Microsoft documentation — the feature may have been renamed, moved, or deprecated. When Claude describes a threat actor’s TTPs, verify against current threat intelligence — the actor’s tooling may have evolved.
Web search: Claude can search the web in claude.ai when the feature is enabled. This partially compensates for the knowledge cutoff — but web search results are not guaranteed to be accurate or current. Treat web-augmented responses the same as any other source: verify before deploying.
What Claude can do well
Text generation and transformation. Claude excels at taking structured input and producing formatted output. Give it raw log data and ask for a timeline — it produces a clean, chronological narrative. Give it investigation notes and ask for an IR report section — it produces executive-readable prose. This is where Claude saves the most time in security operations.
Code generation. Claude writes KQL, PowerShell, Python, and most other languages competently. It handles KQL particularly well because KQL appeared extensively in its training data (Microsoft documentation, blog posts, community forums). For common query patterns (sign-in analysis, email investigation, device timeline), Claude produces working queries on the first attempt most of the time.
Analysis and pattern recognition. Given structured data (CSV, JSON, log output), Claude can identify patterns, anomalies, and correlations. It is not a replacement for a SIEM analytics engine, but it is effective for ad-hoc analysis — “look at these 50 sign-in events and tell me which ones are unusual.”
Summarisation and synthesis. Claude compresses long documents into structured summaries effectively. Give it a 30-page vendor security assessment and ask for a 1-page executive summary with the top 5 risks — the output is usable.
Structured document generation. Policies, procedures, checklists, playbooks, report templates. Claude produces well-structured documents that need human review for accuracy and organisational context, but the structure and coverage are typically 80-90% right on the first pass.
What Claude cannot do
Access your systems. Claude cannot query your Sentinel workspace, read your Defender alerts, or access your Entra ID logs. You must paste or upload the data. In claude.ai, you can upload files (CSV, JSON, images, PDFs). In the API, you send data programmatically. Either way: Claude processes what you give it, not what exists in your environment.
Remember across conversations. Each conversation starts fresh. Claude does not remember what you discussed yesterday (unless you use the memory feature in claude.ai, which stores limited context). For ongoing work, use Projects in claude.ai — they maintain context across conversations within the project.
Guarantee accuracy. Claude generates statistically probable output, not verified output. A KQL query that looks correct may reference a column that does not exist in your environment. An IR report section that reads well may contain a factual error about how a specific Defender feature works. Every Claude output in a security context must be verified before it affects a production system or an official report.
Perform real-time analysis. Claude processes the data you provide at the time you provide it. It does not monitor, alert, or respond to events. It is a tool you use during an investigation, not a tool that runs investigations for you.
Replace human judgment. Claude can generate a containment recommendation, but it cannot assess the business impact of disabling a VIP’s account during a board meeting. Claude can draft a risk assessment, but it cannot weigh the political dynamics of your organisation’s risk appetite. Judgment calls remain human decisions.
Claude does not say "I don't know" often enough. When it lacks information, it generates plausible output instead of admitting uncertainty. A human analyst who does not know the answer says "I need to check." Claude generates a confident-sounding answer that may be wrong. This asymmetry makes verification non-negotiable in security contexts — the output that reads most confidently may be the output most in need of checking.
Try it yourself
Claude may say "AADUserRiskEvents" (does not exist), "IdentityRiskEvents" (does not exist), or "AADRiskyUsers" (exists but is not the sign-in risk table). The actual table depends on your data connectors and may be "SigninLogs" with RiskLevelDuringSignIn, or "AADRiskyUsers" for user-level risk. The point: Claude generates a confident answer. The answer may be wrong. Check before deploying.
The safety model — Constitutional AI and RLHF
Claude’s behaviour is shaped by two training techniques that directly affect how it responds to security-related prompts.
Constitutional AI (CAI): Anthropic trains Claude against a set of principles (a “constitution”) that define what helpful, harmless, and honest responses look like. This means Claude will sometimes refuse to help with tasks it considers potentially harmful — even if your intent is legitimate. For example: asking Claude to “write a phishing email” for a security awareness training exercise may be refused or heavily caveated, because the model cannot verify your intent.
Reinforcement Learning from Human Feedback (RLHF): Human raters evaluated Claude’s responses during training and provided feedback on quality. This tuning makes Claude helpful and conversational, but it also introduces a tendency toward verbosity and hedging. Claude may add unnecessary caveats (“I should note that…”) or qualifications that a security professional does not need. Module F3 (Prompt Engineering) teaches you how to control this.
Practical impact for security work: Claude may refuse to generate realistic phishing emails, even for defensive testing. Claude may add extensive caveats to malware analysis output. Claude may decline to provide specific exploit details, even when discussing detection strategies. These are features, not bugs — but they require adjusted prompting techniques covered in Module F3.
Knowledge checks
Check your understanding
1. You ask Claude to write a KQL query that joins SigninLogs with a table called "UserRiskEvents." Claude produces a syntactically correct query. Is the query safe to deploy?
2. You need to analyse 2,000 rows of sign-in log data. Should you paste it into Claude or use a different approach?
3. Claude generates an IR report section that describes a Defender for Endpoint feature called "Automated Response Actions." You do not recognise the feature name. What do you do?
Key takeaways
Claude is a text prediction engine, not an expert system. It generates statistically probable output based on training data. This makes it fast and versatile, but it means every output needs human verification in security contexts.
Choose the right model tier. Sonnet for daily work. Opus for complex analysis. Haiku for simple, high-volume tasks.
The context window is your friend. 200K tokens means you can send substantial amounts of data in a single prompt. Use it — paste logs, upload documents, provide full context.
Knowledge cutoff matters. Verify feature names, table schemas, and product capabilities against current documentation. Claude’s training data stops at May 2025.
Safety constraints affect security prompts. Claude may refuse or caveat requests related to attack techniques, phishing, malware, and exploitation. Module F3 teaches prompting patterns that work within these constraints for legitimate defensive security work.