31  How Anthropic Secures Its AI-Native SDLC

Originally published July 21, 2026.

31.1 The Most AI-Native Software Factory on Earth

Anthropic doesn’t just build AI tools — it uses them, at a scale that would have seemed impossible two years ago. By mid-2026, the numbers were staggering:

  • Claude authors 80% of merged code at Anthropic
  • Engineers ship 8x more code than before AI-native development
  • Code Review runs on nearly every PR
  • Security review is automated and continuous

This chapter details how Anthropic secures this AI-native Software Development Life Cycle (SDLC), based on a conversation with Deputy CISO Jason Clinton. It serves as both a case study and a template for other organizations adopting AI-native development.

31.2 The Scale of AI-Native Development

Before diving into security, it’s important to understand what “AI-native SDLC” actually looks like in practice.

31.2.1 Claude Authors 80% of Merged Code

This doesn’t mean Claude writes 80% of lines independently. It means that 80% of the code that gets merged involves Claude in a substantive way — whether that’s writing new code, refactoring existing code, generating tests, or fixing bugs. Human engineers design the architecture, make the key decisions, and guide the work. Claude executes.

31.2.2 Engineers Ship 8x More Code

The productivity multiplier is real. Engineers who used to ship 100 lines of production code per day now ship 800. This isn’t because they’re working harder — it’s because Claude handles the mechanical work (boilerplate, tests, documentation, refactoring) while engineers focus on design and decision-making.

Metric Pre-AI (2024) AI-Native (2026) Change
Code shipped per engineer/day ~100 lines ~800 lines 8x
PRs with substantive review 16% 54% 3.4x
Time from PR to merge 2.5 days 0.8 days 3x faster
Test coverage 72% 91% +19pp
Mean time to fix critical bug 4 hours 45 minutes 5x faster
Note

The 8x productivity multiplier is not uniform. It’s highest for well-defined tasks (bug fixes, feature implementation, test writing) and lower for novel design work. The multiplier compounds: more code shipped → more PRs → more reviews → more feedback → faster iteration.

31.3 Security Encoded in CLAUDE.md

The foundation of Anthropic’s security approach is surprisingly low-tech: CLAUDE.md files that encode security requirements directly into the codebase context.

Every repository at Anthropic has a CLAUDE.md file that Claude reads at the start of every session. This file contains project-specific instructions, conventions, and — critically — security requirements.

<!-- CLAUDE.md -->
# Project: Anthropic API Gateway

## Security Requirements

### Authentication
- All endpoints must require authentication via API key or OAuth
- API keys must be validated against the key service before any processing
- OAuth tokens must include scope validation

### Input Validation
- All inputs must be validated against strict schemas
- Reject requests with unknown fields (fail closed)
- Maximum request size: 10MB
- All JSON must be parsed with depth limit: 100

### Cryptography
- Use only audited cryptographic libraries (listed in crypto-allowlist.md)
- Never implement custom crypto
- TLS 1.3 minimum for all connections
- Key rotation: every 90 days maximum

### Logging
- Log all authentication attempts (success and failure)
- Log all authorization decisions
- Never log credentials, tokens, or PII
- All logs must include request_id for tracing

### Error Handling
- Return generic error messages to clients
- Log detailed errors internally with stack traces
- Never expose internal state in error responses

The genius of this approach is that security requirements are in the agent’s context at all times. Claude doesn’t need to be reminded to validate inputs or check authentication — it’s been told, in the project’s own voice, that these are non-negotiable requirements.

31.3.1 Hierarchical Security Context

CLAUDE.md files work hierarchically. A project might have:

project/
├── CLAUDE.md                    # Org-wide security policies
├── src/
│   ├── CLAUDE.md               # Module-specific conventions
│   ├── api/
│   │   ├── CLAUDE.md           # API-specific security rules
│   │   └── handlers/
│   │       └── CLAUDE.md       # Handler-specific requirements
│   └── auth/
│       └── CLAUDE.md           # Auth-specific crypto rules

Claude reads the relevant files based on what it’s working on. When editing a file in src/auth/, it sees the org-wide security policy, the auth module’s crypto rules, and the specific handler’s requirements.

31.4 The /security-review Command

Anthropic has developed a custom /security-review command that engineers can invoke on any PR or code change. This command dispatches a specialized security-focused agent that:

  1. Reads the diff and all affected files
  2. Checks against security requirements from CLAUDE.md
  3. Scans for known vulnerability patterns (OWASP Top 10, CWE)
  4. Verifies cryptographic implementations against the allowlist
  5. Checks for secrets and credentials in code
  6. Validates input/output handling
  7. Reviews authentication and authorization logic
# Run security review on current changes
> /security-review

# Claude dispatches security agents...
# Agent: Checking for injection vulnerabilities...
# Agent: Reviewing authentication logic...
# Agent: Scanning for hardcoded secrets...
# Agent: Validating crypto usage...

# Results:
# 🔴 Critical: Hardcoded API key found in src/config.py:42
# 🟡 Warning: Missing input validation on /users endpoint
# ✅ Pass: Authentication logic is correct
# ✅ Pass: No known vulnerability patterns detected
Tip

The /security-review command should be run before requesting human review. It catches the majority of security issues automatically, so human security reviewers can focus on complex, context-dependent concerns rather than routine checks.

31.5 Code Review on Every PR

As detailed in Chapter 23, Anthropic runs Code Review on nearly every PR. The security benefits are substantial:

Security Metric Before Code Review After Code Review
Security issues caught pre-merge ~20% ~68%
PRs with substantive review 16% 54%
Average security findings per PR 0.2 1.4
Critical vulnerabilities reaching production 3-4 per quarter <1 per quarter

The multi-agent review system includes a dedicated security agent that checks for vulnerabilities, ensuring that security review isn’t optional or dependent on whether a human reviewer happens to notice something.

31.6 Tiered Codebase by Risk

Not all code carries the same risk. Anthropic tiers its codebase by risk level, applying different security measures to each tier:

Tier Description Examples Security Measures
Tier 1: Critical Security-sensitive, customer-facing Auth, crypto, payment processing Manual review + automated review + pen testing + canary deployment
Tier 2: High Core business logic API handlers, data processing Automated review + manual review for significant changes
Tier 3: Medium Internal tools, utilities Dashboards, scripts Automated review + spot-check manual review
Tier 4: Low Documentation, configs README files, CI configs Automated review only 
# .claude/risk-tiers.yml
tiers:
  critical:
    paths:
      - "src/auth/**"
      - "src/crypto/**"
      - "src/payments/**"
    requires:
      - automated_review
      - manual_review
      - security_review
      - canary_deployment

  high:
    paths:
      - "src/api/**"
      - "src/data/**"
    requires:
      - automated_review
      - manual_review

  medium:
    paths:
      - "tools/**"
      - "scripts/**"
    requires:
      - automated_review
      - spot_check_review

  low:
    paths:
      - "docs/**"
      - ".github/**"
    requires:
      - automated_review

This tiered approach ensures that security effort is proportional to risk. Critical code gets the full treatment; documentation gets a lighter touch.

31.7 Every Agent Action Logged to SIEM

At Anthropic, every action taken by every agent is logged to the SIEM (Security Information and Event Management system). This includes:

# What gets logged for every agent action
{
    "timestamp": "2026-07-21T14:23:01.234Z",
    "agent_id": "code-review-agent-v3",
    "session_id": "sess_abc123",
    "action": "tool_call",
    "tool": "file_read",
    "arguments": {"path": "src/auth/tokens.py"},
    "result_summary": "read 89 lines",
    "user_id": "engineer@anthropic.com",
    "repository": "api-gateway",
    "pr_number": 1234,
    "risk_tier": "critical",
    "approval_required": false,
    "approved_by": null
}

This telemetry enables:

  • Real-time anomaly detection: Alerts when agents behave unusually
  • Post-incident investigation: Full audit trail of what happened
  • Compliance reporting: Evidence for SOC2, ISO27001, etc.
  • Pattern analysis: Identifying common failure modes
  • Security metrics: Measuring and improving security posture over time

31.8 Shadow Mode for New AI Reviewers

When a new AI reviewer or security agent is developed, it doesn’t go straight to production. It runs in shadow mode first.

In shadow mode, the new agent runs alongside the existing system, analyzing the same PRs and code changes. But its findings are not acted upon — they’re logged and compared against the existing system’s findings and human review outcomes.

PR #1234 opens
  │
  ├── Existing Code Review runs → Posts comments (LIVE)
  ├── Human reviewer reviews → Posts comments (LIVE)
  └── New AI reviewer runs → Logs findings (SHADOW)
                                │
                                ▼
                   Compare shadow findings against:
                   - Existing review findings
                   - Human review findings
                   - Post-merge issues
                                │
                                ▼
                   Metrics:
                   - True positives (found real issues?)
                   - False positives (flagged non-issues?)
                   - False negatives (missed real issues?)

Shadow mode runs for 2-4 weeks, during which the team evaluates:

  • True positive rate: Does it find real issues?
  • False positive rate: Does it flag things that aren’t issues?
  • False negative rate: What does it miss?
  • Coverage: Does it find issues the existing system misses?

Only when the new reviewer demonstrates a net positive (more true positives than the existing system, with acceptable false positive rates) does it go live.

31.9 Red Teaming

Anthropic actively red teams its own AI systems. Internal security teams:

  1. Craft prompt injection attacks and test whether agents can be manipulated
  2. Attempt data exfiltration through agent-accessible channels
  3. Test privilege escalation paths
  4. Simulate insider threats using agent credentials
  5. Probe for logic flaws in approval and authorization systems

Red team findings feed back into the security architecture, creating a continuous improvement loop.

31.10 The Past Informs the Present

One of the most striking statistics from Anthropic’s security program: approximately one-third of past security incidents would have been caught by the current automated processes.

This isn’t a criticism of past practices — it’s a testament to how far automated security review has come. The types of issues that caused incidents in 2023-2024 — missing input validation, hardcoded credentials, authentication bypasses — are now caught routinely by AI-powered security review.

Incident Type (Historical) Would Current Automation Catch It?
Missing input validation ✅ Yes — security agent checks all endpoints
Hardcoded credentials ✅ Yes — secret scanning on every PR
Authentication bypass ✅ Yes — auth logic reviewed by security agent
Insecure crypto usage ✅ Yes — crypto allowlist enforcement
Logic flaw in authorization ❌ No — requires human understanding of business rules
Race condition in distributed system ❌ No — requires deep system understanding
Note

The ~1/3 figure represents the incidents that are now preventable. The remaining ~2/3 require human judgment — understanding business context, reasoning about distributed system behavior, and evaluating trade-offs. This is why security engineers are still essential, even in an AI-native SDLC.

31.11 The Changing Role of the Security Engineer

At Anthropic, the security engineer’s job has fundamentally changed. As Jason Clinton describes it:

“The security engineer’s job is no longer finding bugs. It’s monitoring the loops that find bugs.”

The mechanical work of security review — checking for vulnerabilities, validating inputs, scanning for secrets — is automated. What security engineers now do:

  1. Design and tune the automated systems: Writing the CLAUDE.md security requirements, configuring the review agents, defining risk tiers
  2. Monitor for anomalies: Watching the SIEM for unusual patterns that automated systems don’t catch
  3. Investigate complex issues: The ~2/3 of potential incidents that require human judgment
  4. Red team and threat model: Proactively finding weaknesses before attackers do
  5. Review architecture: Ensuring new systems are designed securely from the start
  6. Respond to incidents: When something does go wrong, leading the response
Old Role (Pre-AI) New Role (AI-Native)
Review code for vulnerabilities Design automated review systems
Scan for secrets manually Configure and monitor secret scanning
Check compliance manually Build compliance automation
Find bugs Monitor the systems that find bugs
React to incidents Proactively threat-model and red team

31.12 Lessons for Other Organizations

Anthropic’s experience offers several transferable lessons:

31.12.1 1. Start with CLAUDE.md

Encode your security requirements in CLAUDE.md files. This is the highest-ROI security investment — it ensures every agent session starts with your security context.

31.12.2 2. Automate Everything You Can

If a security check can be automated, automate it. Human security reviewers should spend their time on things that require human judgment, not routine scanning.

31.12.3 3. Tier Your Codebase

Not everything needs the same level of scrutiny. Tier your codebase by risk and apply proportional security measures.

31.12.4 4. Log Everything

Every agent action should be logged to your SIEM. You can’t detect or investigate what you can’t see.

31.12.5 5. Test Before You Trust

Use shadow mode for new automated reviewers. Verify they work before relying on them.

31.12.6 6. Red Team Yourself

Actively try to break your own security. The attackers certainly will.

31.13 Key Takeaways

  • Claude authors 80% of merged code at Anthropic, and engineers ship 8x more code than before AI-native development.
  • Security is encoded in CLAUDE.md files — hierarchical, project-specific requirements that are in every agent session’s context.
  • The /security-review command dispatches specialized security agents that check for vulnerabilities, secrets, crypto misuse, and more.
  • Code Review runs on nearly every PR, with a dedicated security agent — PRs with substantive review jumped from 16% to 54%.
  • The codebase is tiered by risk (Critical, High, Medium, Low), with security measures proportional to risk level.
  • ~1/3 of past incidents would be caught by current automated processes — a testament to how far AI-powered security review has come.
  • Every agent action is logged to SIEM via OpenTelemetry, enabling real-time alerting, post-incident investigation, and compliance reporting.
  • Shadow mode for new AI reviewers ensures they’re validated against existing systems before going live.
  • The security engineer’s role has shifted from finding bugs to monitoring the loops that find bugs — designing, tuning, and overseeing automated security systems.