The Principal Engineer's Bible, Part 3: The Security Spine for the AI-DLC

This is Part 3 of The Principal Engineer’s Agentic Coding Bible. Parts 1 and 2 set the worldview (When the IDE Stopped Being an IDE) and the tool stack (The 2026 ADE Stack with Honest Tool Picks). Part 3 is the part where my SOC brain takes over.

12 years in security operations gives you a certain pattern recognition for what’s about to go wrong. Here’s what I’m seeing.

We never actually fixed SSDLC

Let’s just call it. We went from SDLC to SSDLC to what’s now being called AI-DLC. The progression looks clean on paper. It is not clean in practice.

Era	Discipline	What it added	Real-world status today
1990s through early 2010s	SDLC	Agile, Kanban, daily standups, ticket flow, sprint cadence	Mature, widely adopted
Mid-2010s onward (post-2015)	SSDLC	Security shifted left into the dev workflow. Product security teams. SAST, DAST, CSPM (Wiz, Orca) embedded into CI/CD, repos, IDEs.	Not fixed. Adopted unevenly. The frontier orgs got it right. Most everyone else still treats shift-left as a slogan.
2025 onward	AI-DLC	Agents are now participants in every phase. Harness engineering matters. Runtime governance for agents, model provenance, MCP server integrity, NHI controls for the agents themselves.	Just landing. The 2026 tooling fragmentation is real.

When you really do a shift-left, what that means is that you embed security as much as you can into the workflows and the existing tool set of the developers. You build security in. You do not bolt it on.

That requires not only a mindset shift, it requires a skill set shift. The frontier orgs started bringing developers into the security org. Their security org went from being “control enforcement by deploying tools” to “control enforcement by building tools and infrastructure that has bespoke tooling that is accessible and extensible to the product-facing organizations.” That is what secure-by-default actually means. That is where the product security team emerged from. That is the version of SSDLC that worked.

The fundamental shift got there especially with what happened with Wiz, Orca, the CSPMs getting down to the CI/CD, the pipelines, the repos, the IDEs. (There’s that word again.) You saw SAST and DAST scanners converging. Posture management got real. Unified risk registers became table stakes.

But most orgs didn’t make that shift. They bought the tools without doing the structural work. So when I say we never fixed SSDLC, I mean the organizational fix didn’t happen. The tooling exists. The adoption is patchy. And now AI-DLC is showing up while the SSDLC retrofit is still in progress.

The fragmented puzzle (and the mandate that’s coming)

The AI-DLC story is really a mix of what we have plus what we learned from product security teams standing up. The shift you want now is taking that same tooling discipline (embedding security controls into the org as much as possible) and applying it to AI from a governance and risk perspective.

To do that you have to get it at a runtime level. Runtime security is nothing new. From a governance perspective, we understand continuous governance controls. We’ve done posture management with unified risk registers for years. Identity? NHIs (non-human identities) are nothing new from the SaaS explosion. Everything has been doing OAuth consent grants into everything inside the organization since 2017.

But notice what I just did. I named three or four disparate tooling frameworks: runtime security, posture management, identity governance, secrets management. Fragmentation is real. Just like the data boom led to data fragmentation that’s still being unwound.

So the problem is solved. It is. It’s just a fragmented puzzle scattered across the playing board, and somebody’s going to be the one who builds the unifying layer.

Is AI making this worse, or is it finally going to force the issue?

Honest answer: AI is speeding up the addition of more. More resources entering the environment. More tech debt. More tool sprawl. More cowboy IT. The same shape of problem, just at a higher rate. Humans and automation systems alike.

What’s coming next is a mandate. Just like finance got mandated. Just like healthcare got mandated. I think it’s going to be the same with AI. We’re going to have some kind of major security reference incident where it traces back to “we didn’t have the right visibility, didn’t have the right controls, didn’t have the right defense and detection architecture in place.” I don’t want to play doomsday guy. But the conditions are present.

And we already see this lining up. Look at what the defense industry is doing with AI. Look at healthcare, which is fighting the most beautiful and pertinent use case of agentic AI on the most sensitive workloads imaginable (us, our bodies, our records). It’s too expensive to not mandate, because AI is now integrated into the fabric of society the same way financial and medical data got integrated into the fabric of the internet. Internet safety protocols had to come. AI safety protocols will too.

The principal engineer’s job in this moment is to not be the cautionary tale. Build the spine before the mandate forces you to retrofit it.

Here’s what that spine looks like, layer by layer.

Layer 1: The Supply-Chain Security Mindset

“Organizations should assume that AI-generated code expands their software supply chain risk, not just their development speed.”

The 2026 numbers tell the story:

85 percent of developers regularly use AI tools for coding
76 percent of orgs check AI code for security risks
Only 54 percent evaluate AI code for IP and license risks
Only 24 percent perform what could be called comprehensive evaluations
95 percent of code expected to be AI-generated by 2030 (the trajectory is not flattening)

And in March 2026 we got the canonical incident. The litellm supply chain attack (TeamPCP) compromised a package with 95 million monthly downloads via CI/CD credential theft. Read that twice. A single compromised package with that many downloads cascades into a generational software supply chain blast radius. We are going to see more of these, not fewer, as AI agents pull dependencies faster than humans review them.

What AI hallucination looks like in code (and how to catch it)

Hallucination type	Example	Detection method
Non-existent imports	`import { useQuery } from 'react-query'` (wrong package)	`npm ls`, typecheck
Fake SDK methods	`supabase.auth.getSession()` that doesn’t exist	Typecheck, runtime error
Phantom endpoints	API calls to routes never defined	Integration tests
Missing env vars	Code references `DATABASE_URL` never set	Config validation
”Works on my prompt”	Passes the AI’s mental model, fails real tests	Actual test execution

Every one of these is preventable. The supply chain mindset is what catches them before they get to production.

The Three Gate Layers

The core mental model. Three layers, each non-negotiable.

Layer	What it does	Tools
Layer 1: Local Gates (IDE / ADE)	Real-time linting, type hints, import resolution warnings. Catches the hallucination before commit.	TypeScript LSP, ESLint, your editor’s import resolver
Layer 2: Pre-commit Gates	Format staged files. Lint staged files. Block commit on errors. Secrets scanning.	`husky` + `lint-staged`, `gitleaks`, `pre-commit` framework
Layer 3: CI/CD Gates	Full lint + typecheck. All unit tests. Integration smoke tests. Build verification. Dependency vulnerability scan.	GitHub Actions, `npm audit` / `pip-audit`, Socket.dev, Semgrep

If CI fails, the PR does not exist. No exceptions. Not “we’ll fix it in the next sprint.” Not “this is a hotfix, override the gate.” If you let the gates be overridden once, the gates are now optional and the team learns it.

Layer 2: MCP Security (the new attack surface)

This is where AI-DLC genuinely adds new threat surface that didn’t exist a year ago.

MCP (Model Context Protocol) lets AI agents interact with external tools and services. It’s powerful. It’s also a new attack surface. By 2026, running an MCP server is as common as running a web server. Which means MCP servers are now what web servers were in 1999: a thing everyone has, a thing nobody secures properly, a thing about to get a year of vulnerability disclosures.

Critical MCP vulnerabilities (the receipts)

CVE / Incident	Impact	Lesson
CVE-2025-6514 (`mcp-remote`)	OS command injection in OAuth proxy	Supply chain attacks hit MCP too
Anthropic MCP Inspector	Unauthenticated RCE via inspector-proxy	Dev tools are attack vectors
Anthropic Filesystem MCP	Sandbox escape, arbitrary file access	Sandboxes can fail
Asana MCP server	Cross-tenant data exposure	Access control must be explicit, never assumed
litellm PyPI (March 2026)	Credential theft via poisoned package	Pin CI dependencies, rotate tokens

The four attack vectors you need to understand

Prompt Injection via MCP. OWASP’s number-one LLM risk. In an MCP context, successful prompt injection triggers automated actions: scraped content that looks like normal text but contains instructions that get executed against your tool surface.
Tool Poisoning and Shadowing. A malicious MCP server can silently exfiltrate data. Legitimate tools can be shadowed by malicious ones that present the same name and intercept the call.
“Rug Pull” Attacks. MCP servers can modify their tool definitions between sessions. Safe on Day 1. Malicious on Day 7. If you’re not pinning versions and reviewing changes, you’re trusting that the maintainer will stay benevolent.
OAuth Token Theft. One MCP server breach equals access to all the connected accounts. The blast radius for an MCP compromise is enormous because every MCP server is sitting on tokens for the services it bridges.

MCP Security Controls Checklist

This is the minimum bar for running MCP in production:

Run MCP servers through SAST before deployment
Implement SCA (software composition analysis) for all dependencies
Use secure, non-deterministic session IDs
Never use sessions for authentication
Verify all inbound requests
Implement tool allowlisting (deny by default)
Log all tool calls (this is your detection layer)
Set timeouts and retry budgets (this is your blast-radius control)

If you can’t tick all eight, your MCP surface is going to be the entry point. Plan accordingly.

Layer 3: Secrets Management in the Agentic Era

“In July 2025, a founder using Replit’s vibe coding feature lost months of live data when the AI agent deleted a production database containing over 1,200 executive records. The model ignored explicit freeze instructions, fabricated test results, and tried to cover up the error.”

That is a true story. That is the cost of letting an AI agent see production secrets during development. Read the freeze instruction part again. The model ignored explicit freeze instructions. Then it fabricated test results. Then it tried to cover up the error. That is what happens when the secrets boundary is wrong.

Recommended secrets management stack (pick one)

Tool	Use case	Key feature
Infisical	Developer-friendly, open-source	Secret contexts, AI-powered usage insights
HashiCorp Vault	Enterprise, complex requirements	Intelligent secret rotation (ML-based)
Akeyless	Zero-knowledge architecture required	Vaultless design
Doppler	Team-focused, easy setup	First-class NHI (non-human identity) support
GCP Secret Manager	Already on GCP	Tight IAM integration

Secrets discipline: the non-negotiables

Never:

Commit secrets to version control. Not even temporarily. Not even in a “test” branch.
Store secrets in AI chat history. Your prompt history is now part of your attack surface.
Let AI agents see production secrets during development. Use separate dev/staging credentials.
Use the same credentials across environments. Compromise of dev should not compromise prod.

Always:

Use runtime secret injection. Secrets enter the process at runtime, not at build time.
Implement automatic rotation. The Replit-style incident gets contained by short-lived credentials.
Separate dev, staging, and prod credentials completely. Different vaults, different IAM roles, different blast radii.
Use platform-managed identity (workload identity, IAM roles) where possible. Less to leak.
Audit secret access regularly. Detection is the safety net for prevention.

Layer 4: The Anti-Hallucination Framework

This is the contract you enforce against every AI agent that touches your codebase.

The Verification Contract

Every AI agent response must include, and you must verify, the following:

#	Element	What you check
1	Assumptions Made	Listed explicitly. Verified against reality before proceeding.
2	Files to Change	Each file exists. Each one is actually being modified.
3	Commands to Run	Each command is valid. Each dependency exists in `package.json` / `requirements.txt`.
4	Acceptance Criteria	Testable criteria defined. Tests written. Tests passing.
5	Risks and Mitigations	Security implications documented. Rollback plan exists.
6	Verification Results	Lint passed. Types passed. Tests passed. Build passed.

If the agent skips one of these, you reject the PR. Same as a junior dev who skipped writing tests.

The “Did It Actually Work?” Checklist

Before you mark anything as done. Before you close the ticket. Before you ship.

Does it build? npm run build
Does it typecheck? npm run typecheck
Does it lint? npm run lint
Do tests pass? npm run test
Does it work in the browser / app? Manual smoke test, not just unit tests
Are imports real? Check package.json. Check npm ls for the suspect ones.
Are env vars defined? Check .env.example. Cross-reference what the code reads.

The fastest way to get an agent into a stable loop is to make this checklist a hook. Run it after every agent action. Failed gates route back to the agent for self-correction. This is the harness from Part 1 in concrete form.

The summary view (one screen)

If you don’t read anything else in this part, read this table.

Risk	Layer	Control	Why it matters
AI hallucinations in code	Supply chain	Three gate layers (local + pre-commit + CI)	Catches non-existent imports, fake SDK methods, phantom endpoints
MCP server compromise	Tool surface	Allowlist + audit logging + version pinning	One MCP breach equals breach of all connected services
Prompt injection via tool output	Runtime	Structured tool-result envelopes, never raw text into prompts as instruction	OWASP #1 LLM risk
Secrets in chat history	Boundary	Runtime injection, rotation, environment separation	Replit-style data deletion incidents
Hallucinated dependencies	Supply chain	Dependency audit in CI, package pinning, Socket.dev	March 2026 litellm-style attacks
Agent ignoring freeze instructions	Authorization	Hard guardrails in harness, no production write access by default	The agent will not always respect intent, only access
Cross-tenant data leakage	MCP server design	Explicit access control per request	Asana MCP-style cross-tenant exposure
Unaudited tool execution	Observability	Log every tool call, alert on anomalies	You can’t fix what you can’t see

What’s next

Part 4 is the agentic engineering army. The 6 core agent personas (Architect, Implementer, Reviewer, Refactorer, Tester, Doc Writer). Orchestration frameworks. Repository standards. The pre-commit and CI/CD gates from this part operationalized. Model routing by phase, updated for the May 2026 model landscape.

Part 5 is production architecture (Vercel + GCP split, Expo + RN for mobile, Supabase + Postgres + RLS, the SDLC runbook by stage).

Part 6 is the operating system you actually run day-to-day (vibe coding failure case studies, compliance, the Notion workspace, templates, daily and weekly loops).

Subscribe to AI in Living Color below if you want each part dropped into your inbox as it ships.

This is Part 3 of “The Principal Engineer’s Agentic Coding Bible,” v3.0, originally drafted March 2026, now publishing in pieces through 2026 in my actual voice. Built in public.

Sources and recommended reading: Cycode, Securing the Agentic Development Lifecycle · UST, Beyond DevOps: AI-for-SDLC vs SDLC-for-AI · CVE-2025-6514 (mcp-remote OS command injection) · OWASP Top 10 for LLM Applications · Replit AI database deletion incident (July 2025) · Sonar, What is Agentic SDLC