On 25 April 2026 an AI coding agent deleted a company's production database and its backups. It took 9 seconds and one API call. The company was PocketOS. The tool was Cursor running Claude. The agent was doing a routine staging task, found an account token in an unrelated file, and used it to delete a volume. That token was not scoped to staging; it could touch everything. The backups lived on the same volume, so they went with it. Recovery came from a three-month-old copy stored elsewhere. Nobody hacked anything. The agent did exactly what its credential allowed. Now the part most "Claude Code for DevOps" guides skip. Claude Code's own permission docs say a deny rule "isn't a security boundary around the program". Deny "Bash(terraform apply *)" and the same thing can still arrive as sh -c '...', a different path to the binary, or a variable. The docs say it plainly: argument patterns are fragile. So here is the setup I'd run on any machine that can reach real infrastructure, in order of what actually protects you: 1. The credential is the boundary. The session gets read-only cloud credentials: a ReadOnly / Viewer / Reader role, a separate AWS profile, gcloud configuration or az login. If the agent cannot authenticate a delete, no prompt injection, typo or "helpful fix" can delete anything. This is the PocketOS lesson in one line. 2. Plan yes, apply never. The agent writes Terraform and runs terraform plan. A human, or CI with its own identity, runs apply. Same for kubectl: get, describe and logs, yes; delete, no. 3. A PreToolUse hook as a tripwire. Claude Code passes every Bash command to the hook as JSON (tool_input.command). Exit code 2 blocks it, and your stderr message goes back to Claude. My hook normalises the command first, so sh -c wrappers and line breaks don't slip through, then blocks terraform apply/destroy, kubectl delete/drain, aws delete-/terminate-, gcloud/az delete, SQL DROP/TRUNCATE and rm -rf on / or home. It's attached: stdlib Python, tested on 12 cases. It's a tripwire, not a wall. Point 1 is the wall.

"The documents are 300 GB of PDFs, so the vector store is a few GB, right?" No. The PDF size tells you nothing. A scanned 40 MB contract can become 30 chunks, and a 2 MB text export can become 3,000. What sizes your index is chunk count, dimensions and bytes per dimension. That is multiplication, not a vendor conversation. The formula: chunks x dims x bytes per dim. Then the graph on top, then the replicas, then the re-embed you will eventually do. Worked example, ILLUSTRATIVE ExampleCo (made-up org, arithmetic plus flagged estimates, as of 2026-11-02): - Corpus: 2,000,000 docs x 25 chunks = 50,000,000 chunks, 1024 dims - Raw vectors fp32: 204.8 GB (about 190.7 GiB) - Raw vectors fp16: 102.4 GB - Raw vectors int8: 51.2 GB - Raw vectors binary: 6.4 GB - HNSW graph, M=16: about 6.8 GB (ESTIMATE, engine-specific) - RAM per replica, fp32 + graph: about 211.6 GB (ESTIMATE) - Two replicas for HA: about 423 GB (ESTIMATE) - Model migration, old + new index live: about 846 GB peak (ESTIMATE) - int8 + graph in RAM: about 58 GB, with 204.8 GB fp32 on NVMe for rescoring (ESTIMATE) - Chunk text store: about 100 GB on disk at 2 KB per chunk (ASSUMPTION) - Re-embed: 15 billion tokens, about 208 hours on one GPU at an assumed 20,000 tokens/s (about 2.2 days on four). Use your measured number. Four things people get wrong: First, chunk count is set by your chunking policy. Halve the chunk size and you double the index. A chunking change is a capacity change and should go through the same review as adding a node. Second, the embedding model sets the dimensions. Switching from a 768-dim model to a 1024-dim one is a 33 percent increase in vector RAM plus a full re-embed, and during the cutover you carry both indexes. Model choice is a capacity decision and a migration decision. Third, quantization is not free RAM. int8 or binary with fp32 rescoring can work well, or it can quietly drop the one chunk your auditor asks about. Measure recall on your own queries before you trust it.

Most DR cost conversations are about the strategy: backup and restore, pilot light, warm standby, active-active. Everyone nods at the ladder. Cheaper rungs, slower recovery, done. Then someone adds "and we want guaranteed capacity in the DR region" and the ladder quietly collapses. Illustrative example (made-up rates, not any provider's price list, not a real client): ExampleCo protects 20 TB of data and 12 app nodes. Production compute is about $1,750/month at an assumed $0.20/hr per node. Monthly DR cost with rates I picked for illustration: - Backup and restore: ~$200 (cold copies plus some transfer) - Pilot light, no reserved capacity: ~$1,030 - Warm standby at 25% size, no reserved capacity: ~$1,470 - Active-active: ~$2,780 - Pilot light WITH 100% of prod compute reserved in the DR region: ~$2,780 Same bill as active-active, with the recovery time of pilot light. You are paying to hold seats you will probably never sit in. Capacity reservations bill whether or not you ever fail over. That is the point of them, and also the trap. Where the money actually goes: 1. Standing capacity (reservations or idle compute). Usually the biggest line. 2. A hot data replica: storage plus the always-on database replica. 3. Cross-region replication traffic. It scales with your daily change rate, not your data size, so measure the change rate. 4. Drills. Full-size compute for a few hours twice a year is cheap. Skipping them is not. What to do instead: - Tier workloads. Five services need a 15-minute RTO. Forty do not. Do not replicate everything at the top tier. - Replicate data, not compute. Compute can be rebuilt from IaC; data cannot. - Reserve only what the tier-1 failover needs, not 100% of prod. Size it from the tier list, not from fear. - Decide on purpose whether "capacity guaranteed" is worth the delta for each tier. Write the delta down. - Tag every DR resource so the standby bill shows up in showback as its own line. The model is attached: a small read-only Python script (stdlib only, rates in a config you edit). Run it with your own numbers. Review and test it before using the output in a business case. The figures above come from that script with placeholder rates, so verify against your provider's current pricing.

You upgraded the model on Tuesday. On Wednesday the agents started producing malformed tool calls. The rollback plan: put the old weights back. That plan restores one of at least six things that define what your users are actually talking to. A served model is a release, not a file: - the weights, and their exact quantization - the tokenizer and the chat template - the generation defaults (temperature, stop tokens, max length) - the inference engine version and its flags - the system prompts and tool schemas your apps send - the routing config in front of it (gateway alias, fallbacks) Change any one and behavior changes. The chat template is the sneaky one: a revision that ships a different template changes how tool calls are formatted with the same weights and a perfect checksum. An engine upgrade can shift outputs with zero model change. And if you serve by a mutable tag ("latest", or any tag a publisher can re-push), a restart can quietly pull a different artifact than yesterday's. Three things to do before the next upgrade: 1. Write a release manifest. One file per release: weights revision (a commit hash, not a tag), quantization, tokenizer and template hashes, engine image digest, flags, prompt pack version, gateway route. Diffing manifest N against N-1 is your change log and your rollback spec. 2. Do the rollback arithmetic. Illustrative, not measured, arithmetic as of 2026-10-27: a 70B-parameter model in 16-bit is roughly 140 GB of weights (parameters x 2 bytes). Loading that at 1 GB/s from local NVMe takes a couple of minutes. Pulling it over a 1 Gbit link at roughly 0.1 GB/s takes about 25 minutes. Your rollback time is set by storage and network, not by your deploy tool. If N-1 is not staged on the node, "rollback" is a half-hour outage with a polite name. 3. Route through an alias. Apps call "assistant-prod", never a model name. Flipping the alias is the rollback: seconds, as long as N-1 is still resident or staged. That costs GPU headroom. The honest on-prem tax of safe releases is that canary and shadow traffic need VRAM your capacity plan probably did not include.

A 4-vCPU Windows Server VM needs 8 core licenses to run under Azure Hybrid Benefit. Not 4. Eight. That one line from Microsoft's docs is where most hybrid-benefit savings quietly leak. Everyone knows AHB makes a Windows VM bill at the Linux compute rate. Far fewer people do the license math per VM instead of per vCPU. Here is the math, on an illustrative fleet I invented (call it ExampleCo, not a real company): - 40 VMs at 4 vCPU - 20 VMs at 8 vCPU - 6 VMs at 16 vCPU Total vCPU: 416. Core licenses needed: 576. The gap is 160 cores, and it comes entirely from the 40 small VMs: 40 x 8 = 320 licenses to cover 160 vCPU. The floor is per VM, so a fleet of small VMs is the most expensive way to hold the same number of cores. What the Microsoft Learn page says (checked 2026-10-26, always confirm against your own agreement and the Product Terms): 1. Minimum 8 core licenses per VM, Standard or Datacenter, with active Software Assurance or a qualifying subscription. 2. A processor license counts as 16 core licenses. 3. Workloads may only run under the benefit during the SA or subscription term. If it lapses, you renew, disable the benefit, or deprovision. Silence is not an option. 4. Standard licenses: on-prem OR Azure, with a one-time 180-day migration overlap. Datacenter VM licensing allows overlap during migration without the 180-day cap. 5. Windows Server AHB is managed per resource. The central scope-level assignment is SQL Server only. Three things worth doing this week: First, inventory. Pull every Windows VM from Azure Resource Graph and look at licenseType. Anything null is paying the full Windows rate. Whether you own the licenses to cover it is the second question, but you can't answer it without the list. Second, count licenses with the floor applied, per VM. Spreadsheets that multiply vCPU by VM count undercount. Third, before you merge small VMs to "fix" the floor, check HA, zone placement, app support and blast radius. Two 4-vCPU VMs becoming one 8-vCPU VM saves 8 licenses in the model and might cost you a resilience story in real life. The license math is an input, not the decision.