DEV Community: Harshit Luthra

How to bypass corporate MDM and AI gateways on Claude Code

Harshit Luthra — Mon, 18 May 2026 16:59:08 +0000

Originally published at harshit.cloud on 2026-05-08.

If you're reading this, there's roughly an 80% chance your company rolled out an MDM last quarter, your network team wedged Claude API traffic through an AI gateway around the same time, and now Claude Code boots with MCPs you didn't pick while forwarding your prompts somewhere you haven't audited. /mcp shows three servers nothing in your repo touches. env | grep ANTHROPIC returns a base URL on a domain you've never seen. The experience got worse and nobody asked you.

This post covers both leashes. The MDM one is fixable in 12 lines of zsh. The AI gateway one depends on how deep your network team went.

what's an MDM, in three sentences

MDM stands for Mobile Device Management. Jamf, Kandji, Intune, Workspace ONE, whichever agent enrolled your laptop on day one. It owns parts of /Library, can write files there as root with the system-immutable flag set, and re-pushes them on a schedule, which is why a plain rm doesn't survive. For Claude Code, the relevant directory is /Library/Application Support/ClaudeCode/.

the managed-settings situation

The two files doing the work are /Library/Application Support/ClaudeCode/managed-settings.json and /Library/Application Support/ClaudeCode/managed-mcp.json. Claude Code reads them on startup, treats them as the highest-priority settings layer, and merges them over whatever you have in ~/.claude/settings.json. Anything IT puts in there wins: forced MCPs, forced skills, allowed and denied permission lists, and the env block that can set ANTHROPIC_BASE_URL. That last one is how the AI gateway routing gets wired into Claude Code in the first place.

why `rm` doesn't work

First instinct fails, and not in a way that's obvious:

sudo rm "/Library/Application Support/ClaudeCode/managed-settings.json"
# rm: managed-settings.json: Operation not permitted

Root isn't enough. The MDM agent sets the file's system-immutable flag with chflags schg after writing it. That flag blocks deletion even by root until it's cleared. The macOS chflags(1) man page is the receipt. schg is the "system immutable" flag, and the file "may not be changed, moved, or deleted" while it's set.

Confirm it on your own machine:

ls -lO "/Library/Application Support/ClaudeCode/managed-settings.json"
# -rw-r--r--  1 root  wheel  schg  482 May 14 09:11 managed-settings.json

schg in column five is the marker.

The detail that matters: managed-settings.json is the same config layer your ~/.claude/settings.json uses. The IT copy just lives under /Library, is owned by root, and has the schg flag set. The merge logic doesn't know which file came from a human.

the cleanup script

One thing worth flagging before you run this. On macOS, the schg flag is normally clearable by root for files outside SIP-protected paths — and /Library/Application Support/ClaudeCode/ is not SIP-protected. So sudo chflags noschg works as written. If your MDM also writes its config into a SIP-protected location (rare for application config, more common for system extensions), you'd need Recovery Mode Terminal to clear those, which is a different conversation. The script's 2>/dev/null will silently swallow that failure, so if reruns don't seem to take, that's where to look.

Save this as /usr/local/sbin/claudecode-cleanup.sh, make it executable, run with sudo:

#!/bin/zsh
FILES=(
  "/Library/Application Support/ClaudeCode/managed-settings.json"
  "/Library/Application Support/ClaudeCode/managed-mcp.json"
)
for f in "${FILES[@]}"; do
  # Clear immutable flag if file exists, then remove
  [ -e "$f" ] && /usr/bin/chflags noschg "$f" 2>/dev/null
  /bin/rm -f "$f"
done

sudo chmod 755 /usr/local/sbin/claudecode-cleanup.sh
sudo /usr/local/sbin/claudecode-cleanup.sh

Two lines do the real work. chflags noschg clears the immutable bit. rm -f removes the file. The 2>/dev/null swallows the noise on a clean machine where the file isn't there.

Restart Claude Code. /mcp should be back to whatever you actually installed, and /permissions should be whatever's in ~/.claude/settings.json instead of whatever IT decided you needed.

the launchd arms race

I'd love to tell you this is permanent. It isn't.

MDM agents sync on a schedule. Every 15 minutes, every hour, on login, depending on profile. When they sync, they notice the file is gone, put it back, and re-apply the schg flag. You'll watch managed-mcp.json reappear like a horror-movie villain you keep stabbing.

A few options, in increasing order of trouble you're inviting:

Run the script on a launchd LaunchAgent that fires at login. Once per session. Low impact, low effectiveness, but if your MDM only syncs at login this is enough.
Run it on a launchd timer with a 60-second interval. Now you're in an arms race with the sync schedule. Works until someone in IT notices a config-drift alert for your hostname.
Block the MDM agent's outbound DNS. Effective, loud, and the kind of thing that gets your laptop wiped on the next compliance audit.

I run the first one. The MDM gets its login telemetry, my dev environment isn't broken for the hour or so between syncs, nobody opens a ticket. Pick the option that matches how much you actually want to fight this.

Minimal ~/Library/LaunchAgents/cloud.harshit.claudecode-cleanup.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>Label</key><string>cloud.harshit.claudecode-cleanup</string>
  <key>ProgramArguments</key>
  <array>
    <string>/usr/bin/sudo</string>
    <string>-n</string>
    <string>/usr/local/sbin/claudecode-cleanup.sh</string>
  </array>
  <key>RunAtLoad</key><true/>
</dict>
</plist>

sudo -n only works if you've added a NOPASSWD line for that exact script in /etc/sudoers.d/claudecode-cleanup. Which the MDM might rewrite. The arms race goes deeper than you think.

the AI gateway angle

The other leash sits at the network layer. Companies route Claude API traffic through a gateway (Cloudflare AI Gateway, Portkey, LiteLLM, internal proxies) so they can log prompts, strip PII, enforce per-user quotas, or quietly downgrade Opus calls to Haiku when the monthly bill spikes. Claude Code respects ANTHROPIC_BASE_URL and will talk to whatever endpoint it points at, as long as your OAuth token or API key authenticates there.

Two routing patterns to recognize:

The env block in managed-settings.json. IT sets ANTHROPIC_BASE_URL=https://ai-gw.corp.example.com/v1 inside the env section of the managed file. Claude Code reads it on startup. Same fix as the MCP file. The cleanup script above already kills this.
System proxy plus a corporate root CA. Your laptop has a "Corporate Root CA" in keychain, and either an https.proxy setting or transparent network interception routes api.anthropic.com traffic through the gateway. Deleting managed-settings.json does nothing here. The interception lives below the application layer.

To tell which one you have, run this in a fresh shell:

env | grep -i anthropic
# If you see ANTHROPIC_BASE_URL, it's the env block.

curl -v https://api.anthropic.com/v1/messages 2>&1 | grep -iE 'issuer|subject|server certificate'
# If the cert chain is signed by your corporate CA, it's transparent interception.

bypassing the gateway

For the env-block case, the cleanup script already does the work. Restart your shell after running it:

unset ANTHROPIC_BASE_URL
env | grep -i anthropic
# (empty)

For the transparent-proxy case, your options shrink:

Personal hotspot for sensitive sessions. Burns mobile data, leaves no trail through the gateway. Most realistic option for an individual contributor.
WireGuard or Tailscale out to a personal node. Works if your MDM profile allows it. Many block third-party VPNs through com.apple.systempolicy.kernel-extension-policy.
Personal device for personal work. Boring answer. The one that holds up in HR if it ever comes up.

What doesn't work: removing the corporate root CA from keychain. It's pinned by an MDM payload and gets re-added on next sync, same pattern as managed-settings.json.

should you actually do this

Worth saying out loud: both leashes exist because someone at your company had a reason. Compliance, data residency, an incident from six months ago whose postmortem nobody can find.

If the forced MCP is internal-secrets-lookup and the gateway logs prompts to a SOC pipeline, your team probably wants you using it. If the MCP is corporate-docs-mcp pointed at a 404 and the gateway downgrades Opus to Haiku because someone misread an invoice, you're deleting dead weight.

The script doesn't know which. Ask before you script. Most MDM platforms support per-user opt-out scopes, and one polite Slack message to IT beats a launchd plist.

what these scripts don't do

The cleanup clears two files. It does not:

Stop the MDM agent.
Touch ~/.claude/settings.json. Your settings stay yours.
Handle /Library/Application Support/ClaudeCode/managed-permissions.json if your MDM uses one. Add it to the FILES array.
Survive a reboot or a sync. The agent re-pushes on next check-in.
Defeat a transparent proxy with a pinned corporate CA. Use the hotspot.

If you wanted a permanent escape from corporate IT, you wouldn't be reading a blog about chflags.

Lazy SRE's guide to secure systems, part 5: the dev laptop is the perimeter

Harshit Luthra — Mon, 18 May 2026 16:58:52 +0000

Originally published at harshit.cloud on 2026-05-03.

In June 2024, Mandiant published the writeup for the Snowflake mass-extortion campaign. Ticketmaster, Santander, AT&T, LendingTree, Advance Auto Parts — roughly 165 Snowflake tenants in total had data extracted from their warehouses. The defining detail wasn't sophistication. It was the laptop.

Mandiant traced the entry point to infostealer malware (Lumma, RedLine, Vidar variants) running on contractor and developer machines. Their report described the affected devices as personal systems also used for gaming and downloading pirated software. The infostealer harvested every credential the browser had ever saved, including the Snowflake login that didn't have MFA enforced. The attackers walked through the front door of a Fortune 500's data warehouse.

This is part 5. Earlier parts covered npm (Part 1), GitHub Actions (Part 2), the unsexy infrastructure list (Part 3), and DNS auth records (Part 4). Part 5 is about the laptop. The piece of hardware on an engineer's desk that has every SSH key, AWS profile, kubeconfig, GitHub PAT, Slack token, and Stripe key they have ever used to do their job.

The thesis from Part 1 stands. Future You at 3am will not run an EDR scan after every browser extension install. The config that prevents the extension from being installed in the first place is the one that runs while you sleep: the MDM that whitelists, the disk encryption that protects what gets stolen, the hardware MFA that survives the keylogger.

MDM is the table you set first

Mobile Device Management is the thing every small startup skips and every enterprise has. The bad-faith reason is that it's expensive and annoying. The honest reason in 2026 is that the free options have caught up.

For a 15-person Apple-heavy team, the lazy stack is Apple Business Manager (free, Apple-only) plus Fleet (OSS, free under 300 endpoints on the self-hosted path, generous free tier on Fleet's cloud). Apple Business Manager assigns a Mac to your organization at first boot, before the user creates a personal Apple ID on it. Fleet runs the osquery agent on every machine and lets you push configuration profiles (the same plist payloads Jamf would push) plus query inventory in SQL syntax.

The lazy default config profile, in plain English:

Require FileVault. Escrow the recovery key to MDM. If the laptop walks, the disk is encrypted; if the user forgets the password, you can recover.
Require auto-lock at five minutes idle, password to wake. Not a screensaver.
Block unsigned package installs, restrict the Mac App Store to managed Apple IDs only.
Require macOS updates within fourteen days of release. The fourteen days lets you skip a known-bad point release; longer than fourteen is negligence.
Block AirDrop on the corporate Wi-Fi, restrict USB external storage to read-only (or block entirely if your workflow doesn't need it).
Install osquery via MDM, enrolled to your Fleet server.

For Linux and Windows in the mix, Fleet covers both with the same osquery agent and the same query syntax. The MDM-config-profile half is Windows Intune (free with Microsoft 365 Business Premium) or Workspace ONE's free tier. Either way, the stack is "Fleet for inventory and detections + a platform-specific MDM for enforcement."

The lazy fix for the most common gap: a weekly cron that runs one Fleet query, "every laptop without FileVault enabled," and posts a Slack alert with the user's name. The conversation that follows is "we found your machine, can you enable it today" — not a six-month audit.

hardware keys, one-time spend

YubiKey 5 NFC is $50. Buy two per engineer: one for the desk, one for the bag. Total for 15 engineers: $1,500, one-time, capital expense, deductible.

What it gets you:

WebAuthn / FIDO2 for SSO login (Google, Okta, GitHub, Cloudflare, AWS): a keylogger can record every keystroke and still never get the second factor.
SSH key storage in hardware. ssh-keygen -t ed25519-sk -O resident writes the key into the YubiKey. The private key never exists on disk.
PIV smartcard for VPN auth, code signing (gpg --card-edit).
TOTP fallback for the SaaS that hasn't shipped WebAuthn yet.

The free alternative for the SaaS that doesn't support hardware keys is passkeys. Passkeys are WebAuthn under the hood, also phishing-resistant, built into iOS, macOS, Android, Windows Hello, Chrome, and Safari. Free. The catch is sync: if the engineer's iCloud is compromised, so is the passkey. Hardware keys aren't synced; they are a physical token. The lazy answer is both: passkeys for low-risk auth, YubiKeys for the keys that gate production.

Cost: $1,500 one-time for 15 engineers. The cheapest line item in this post for what it gets you.

EDR is where the budget goes

Endpoint Detection and Response is the part of this stack that costs real money. For OSS-only, the answer is osquery + Wazuh, which works but requires writing detections by hand. For a 15-person team with one platform engineer, "write your own EDR detections" is not a project anyone will finish.

The honest 2026 small-team answer is Microsoft Defender for Business at $3/user/month. It ships in Microsoft 365 Business Premium (also useful if you're on M365 anyway), has acceptable macOS coverage, and includes managed detections written by Microsoft's security team. Cost for 15 engineers: $540/year. CrowdStrike Falcon Go is $60/endpoint/year if you want best-in-class detection at small-team scale; same math, $900/year for 15.

Fig. 2 — three configurations. Pick the middle bar unless you have a reason.

The lazy stance: Defender for Business if you're on Microsoft 365 already. Falcon Go if you're not on M365 and want managed detection without the OSS-engineer overhead. osquery + Wazuh only if you have a security engineer with bandwidth to maintain the detections, which most 15-person startups don't. Pretending otherwise is how you end up with a fancy SIEM nobody reads.

the password manager and browser hygiene argument

1Password Business at ~$8/user/month. Bitwarden Teams at $4. Apple Passwords (or 1Password Families) if you're Mac-only and don't need shared vaults. Pick one and stop arguing about it on the team's #tools channel.

The point of the password manager isn't strong passwords. The point is:

One place for credentials, audited.
Shared vaults for vendor logins, instead of "share the password in Slack DM" hygiene.
Breach notifications when a saved password appears in a public breach corpus.
Masked email aliases (1Password feature, Apple's Hide My Email equivalent): every signup gets a separate alias, every spam list is contained.

Browser hygiene matters because the Snowflake infostealer harvested credentials from browser local storage. Specifically:

Enforce browser auto-updates via MDM. Both Chrome and Edge expose policy keys for this; Firefox via policies.json.
Block sync of work browser profiles to personal Google/Apple accounts. The "I signed into Chrome with my personal account and now all my work bookmarks are in someone else's cloud" leak is real.
Block "developer mode" extension installs. Force extensions to come from the Chrome Web Store; force the Web Store to honor the org's allowlist via the ExtensionInstallAllowlist policy.
Disable browser password saving entirely. Everything routes through the password manager.

Total: $1,440/year for 15 engineers on 1Password Business. $720 on Bitwarden Teams. $0 on Apple Passwords if it covers your needs. Pick a line and walk it.

the personal device problem

The Snowflake breach was about contractors using personal Macs for work. The lazy answer at a 15-person startup might surprise: corp-issue every contractor a laptop. Yes, including the four-hour-a-week consultant.

A refurbished MacBook Air with 16GB RAM is roughly $700 from Apple's Certified Refurbished store. The cost of a Snowflake-scale breach starts at $370K (the reported AT&T ransom) and ends in the customer-churn and legal-exposure column. The break-even point on hardware-for-contractors is under three serious incidents, ever.

Fig. 3 — same laptop, different enrollment. The right panel is the one where Mandiant doesn't write your name down.

What "no work on personal devices" actually requires:

Contract clause: hardware is issued, personal-device use for work is prohibited.
MDM enrollment at first boot via Apple Business Manager (or Windows Autopilot).
Disabled iCloud personal sign-in; only managed Apple IDs.
Wipe via MDM on offboarding, before reissue.
No "I can just SSH from home for ten minutes" escape hatch. The escape hatch is what the contractor will use the day they get phished.

This is the section of the post that gets the most pushback. The pushback is right about cost and wrong about risk. Run the math at your scale; it runs the same direction every time.

the receipts

For 15 engineers, the first-year laptop security budget:

YubiKey 5 × 30 keys (two per engineer): $1,500, one-time.
Fleet (OSS self-hosted on a small VPS): $240/year.
Microsoft Defender for Business: $540/year. Substitute Falcon Go at $900 if not on M365, or osquery+Wazuh at $0 if you have a security engineer.
1Password Business: $1,440/year. Or Bitwarden Teams at $720. Or Apple Passwords at $0.
Refurbished corp laptops for non-employee contractors: ~$700 per, as needed.

Total recurring: roughly $1,020–$2,220/year for 15 engineers, depending on the EDR and password-manager line. Add the one-time YubiKey spend and the first year lands at $2,520–$3,720. Call it $14–$21 per engineer per month.

What it catches: every infostealer that hits a managed laptop (Defender flags it), every credential that lives in the browser (replaced by the password manager), every login that doesn't have phishing-resistant MFA (the YubiKey is required), every personal device touching production (blocked by the no-BYOD policy).

What it doesn't catch: a determined adversary with physical access and unlimited time. A laptop in a hotel room with no FileVault is owned. A laptop with FileVault and a YubiKey left in the USB-A port overnight is owned slower. Neither situation is what this stack is built for; it is built for the infostealer that landed on the contractor's personal Mac.

If you do one thing this week, buy two YubiKeys for yourself, enroll them on GitHub, Google, and Okta, and turn off SMS-based MFA on each. Total cost: $100, one hour. Then do the rest of the team next quarter.

Lazy SRE's guide to secure systems, part 4: the four DNS records

Harshit Luthra — Mon, 18 May 2026 16:58:36 +0000

Originally published at harshit.cloud on 2026-04-26.

In February 2024, Guardio Labs published a writeup of a campaign called SubdoMailing. Five million phishing emails a day, sent through subdomains owned by MSN, eBay, VMware, NYC.gov, UNICEF, and McAfee. Every single email passed SPF and DKIM. Every one of them passed DMARC.

The attack didn't break those protocols. It used them. Each victim domain had an include: line in its SPF record pointing at a contractor's domain that had been allowed to expire. The attackers re-registered the orphan, inherited the trust, started sending. Some of the broken include: chains had been broken for over a year — Guardio dated the operation back to at least late 2022. Nobody had thought to read their own SPF record again after writing it.

This is part 4. Earlier parts covered npm (Part 1), GitHub Actions (Part 2), and identity, network, and audit logs (Part 3). Part 4 is four DNS records and two monitors. One afternoon to write them, three weeks for DMARC to ramp safely. Zero ongoing cost. Closes the entire phishing-impersonation class and the entire rogue-certificate class at the same time.

Future You at 3am will not investigate an SPF chain when finance forwards a wire-transfer email. The records that run in their place will.

SPF, and the include trap

SPF stands for Sender Policy Framework. The record lives in DNS as a TXT entry on your apex domain. It declares which IP addresses or domains are allowed to send email on your behalf. The receiving mail server checks the sending IP against the list. The check passes or it fails. That is the entire protocol.

The record itself:

yourorg.com TXT "v=spf1 include:_spf.google.com include:mailgun.org -all"

v=spf1 is the version marker. include: delegates to another domain's SPF record, which expands at lookup time to that vendor's actual IP allowlist. -all says anything not listed is hard-fail.

That last token matters. -all (hard-fail) tells receivers to reject anything not on the list. ~all (soft-fail) tells them to mark it suspicious but maybe deliver anyway. ?all (neutral) tells them you have no opinion. Every getting-started guide ever written defaults to ~all "to be safe." The major receivers have said for years that they treat ~all and -all the same in scoring. The lazy answer is -all. The only reason to use ~all is during a migration when you can't yet enumerate every legitimate sender.

The SPF spec has a ten-DNS-lookup limit. Every include: counts, recursively. If you chain five SaaS senders (Google + Mailgun + Postmark + SendGrid + Stripe), each one's include: expands into its own record, which may include another, and you can blow the limit without realizing. When you blow the limit, the record evaluates as permerror, and many receivers treat that as "no SPF," which means anyone can spoof you. Tools like dmarcian.com/spf-survey count the lookups for free. Audit yours.

The SubdoMailing failure mode is what happens when one include: points at a contractor whose domain you don't control. The contractor goes out of business. The registration expires. Someone buys the lapsed domain. They publish their own SPF allowlist. Your domain now declares that the buyer is an authorized sender for you. Every email they send passes SPF. The fix is to audit your include: chain quarterly: does every domain in it still belong to someone you trust? Most teams have never done this once.

DKIM, in DNS

DKIM (DomainKeys Identified Mail) is a cryptographic signature on every outbound email. The signing key is a public/private keypair. The private key lives in your mail server (Google Workspace, Microsoft 365, Postmark, your own Postfix, whatever). The public key lives in DNS, under a selector subdomain.

selector1._domainkey.yourorg.com TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

The selector (selector1 here) is so you can rotate keys. Publish a new selector, switch the mail server to sign with the new private key, leave the old selector live for a week so in-flight emails still verify, then retire it. Most providers handle this rotation for you once the original selector is configured.

Two things go wrong in practice. First, key length. RSA-1024 was the standard a decade ago and is now considered weak; RSA-2048 is the current default. Some old DKIM records still publish 1024-bit keys, and many major receivers now fail or ignore 1024-bit signatures. Audit with dig TXT selector1._domainkey.yourorg.com. Second, third parties signing on your behalf without your knowledge. If finance connects a new SaaS tool that sends email as noreply@yourorg.com and nobody sets up DKIM for that path, that vendor's emails will fail DKIM alignment. Receivers see a domain with DKIM mostly working and one path failing, which is often enough to flag the whole domain in spam filters.

Most providers (Google Workspace, Microsoft 365, Postmark, Mailgun, SendGrid) make DKIM publishing a checklist item in their onboarding. If a vendor doesn't, that is a signal about the vendor's sophistication, not yours.

DMARC, the part that does the work

DMARC (Domain-based Message Authentication, Reporting & Conformance) is the policy layer on top of SPF and DKIM. It tells receivers what to do when SPF and DKIM checks fail, and it tells you, via aggregate reports, what's happening to your domain in the wild.

A minimal DMARC record:

_dmarc.yourorg.com TXT "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@yourorg.com; pct=100; adkim=s; aspf=s"

The fields that matter:

p=reject: policy for emails that fail both SPF and DKIM on the apex. Three values, none (just report), quarantine (deliver to spam), reject (drop). The end state is reject. The path is none → quarantine → reject.
sp=reject: same policy for subdomains. This is the SubdoMailing detail every public DMARC how-to forgets. A domain with p=reject but sp=none is wide open for subdomain abuse. Set both.
rua=mailto:: where aggregate reports get sent. Free DMARC report parsers (Postmark, dmarcian, EasyDMARC) accept these and render them as human-readable summaries.
pct=100: fraction of failing mail to apply the policy to. Start at 25% during the ramp, end at 100%.
adkim=s and aspf=s: strict alignment. The From-address domain must match the DKIM signing domain (and SPF return path) exactly. The default is relaxed, which lets subdomains substitute. Strict is what you want unless something is breaking.

The ramp from p=none to p=reject is what takes three weeks. The risk is breaking a legitimate sender path you didn't know existed. Week one, publish p=none; pct=100. Receive DMARC aggregate reports for seven days. Identify every IP and From: domain that sent on your behalf. There will be three or four you didn't expect: a newsletter platform finance signed up for, an HR tool, a calendar invite system. Onboard each into SPF and DKIM. Week two, move to p=quarantine; pct=25, watch reports for new failures. Week three, p=reject; pct=100. Done.

Fig. 2 — BEC losses by year, U.S. only. The 2024 number exceeded ransomware.

Most small teams stop at p=quarantine and never finish the ramp. The difference between quarantine and reject is whether the attacker's spoofed wire-transfer email lands in the CFO's spam folder or never enters the mail system at all. Spam is where employees go to recover legitimate mail that was filtered too aggressively, which means they go there to fish out emails they want to trust. Reject is the answer.

CAA, two lines to gate cert issuance

CAA (Certification Authority Authorization) is a DNS record that names which Certificate Authorities are allowed to issue TLS certificates for your domain. Without one, any publicly trusted CA in the world can issue a cert for your domain to anyone who passes that CA's domain-validation challenge. With one, only the CAs you've named can.

yourorg.com CAA 0 issue "letsencrypt.org"
yourorg.com CAA 0 issuewild "letsencrypt.org"
yourorg.com CAA 0 iodef "mailto:security@yourorg.com"

issue restricts standard certificates. issuewild restricts wildcard certificates. iodef is where notifications are sent when an unauthorized CA tries to issue. If you use multiple CAs (one for ACM in AWS, one for Let's Encrypt in your edge, one for Cloudflare-managed certs), list them all:

yourorg.com CAA 0 issue "letsencrypt.org"
yourorg.com CAA 0 issue "amazon.com"
yourorg.com CAA 0 issue "digicert.com"

CAA cannot prevent a misbehaving CA from issuing anyway. But CAs are required by the CA/Browser Forum baseline requirements to honor CAA at issuance time. They mostly do. When they don't, the misissuance ends in a Mozilla CA-incident bug report and eventual CA distrust. CAA exists so that legitimate misissuance is detected (because the CA you named never issued the cert and the issuing CA broke the rule) and accidental misissuance is structurally impossible. Both buy you something.

Cost: three DNS lines. Effort: ten minutes. Catches a class of attack (man-in-the-middle via misissued cert) that most teams have no other defense against.

the monitors

Two streams pay back the four records.

First, certificate transparency log monitoring. Every publicly trusted CA is required to log every certificate they issue to public append-only logs. crt.sh is a free queryable index. The certstream Python library streams new entries in real time, also free. Cloudflare offers free CT monitoring for any domain on its DNS. Whatever you pick, the workflow is: cert is issued for *.yourorg.com → log entry appears within seconds → your monitor pages a Slack channel → you check whether you issued it. If you didn't, that is an incident, not a notification.

Fig. 3 — the whole afternoon, sketched. Plus what runs after.

Second, DMARC aggregate report parsing. The rua= address in your DMARC record receives daily XML reports from every receiver. Reading the XML raw is unpleasant. The free tiers of Postmark, dmarcian, and EasyDMARC all accept the report stream and render it as "here are the IPs that sent as you this week, here are the ones that failed alignment, here are the new ones since last week." The new-sender alerts are where you find out that someone in marketing has connected a SaaS tool that's now sending emails as you, failing alignment, and getting your domain reputation downgraded.

A weekly fifteen-minute review of both monitors is what good looks like at a 25-person team. The cost is fifteen minutes a week. The product is "we'd have noticed if someone issued a cert for our login subdomain on Tuesday."

the receipts

Four DNS records. Two monitors. One afternoon for the records, three weeks for the DMARC ramp, fifteen minutes a week for the reviews. Cost: zero, unless you upgrade past the free tier of a DMARC parser at $15–$50 a month, which is the only thing on the list that's not free.

What this catches: every attempt to send email impersonating your domain from outside your authorized sender list, every attempt to issue a TLS cert for your domain from an unauthorized CA. The FBI's 2024 IC3 report attributed $2.77B in U.S. business email compromise losses to roughly 21,000 incidents — a $129K average. The fraction of those that would have been caught by a domain publishing p=reject; sp=reject with an honest SPF audit is enormous.

What it doesn't catch: phishing from a lookalike domain (yourorg-corp.com, yourorg-support.com, yourorg.co). Lookalike-domain defense needs a paid monitoring service at the tier that matters, and there's no free version that works at small-team scale. Skip it until you have a budget line for security. Note it in the runbook.

If you do one thing this week, publish _dmarc.yourorg.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@yourorg.com" and point the address at a Postmark free-tier DMARC inbox. Read the first report in seven days. The list of senders you didn't know about is the answer to "why has this been skipped for two years."

Lazy SRE's guide to secure systems, part 3: the unsexy list

Harshit Luthra — Mon, 18 May 2026 16:58:21 +0000

Originally published at harshit.cloud on 2026-04-19.

I have a calendar reminder that fires on the first of every month. It says "rotate the PAT." I have hit "snooze for 1 week" seventeen times in a row. The PAT in question is a ghp_ token with read-write access to four private repos and permission to push tags, and the last time I rotated it was October 2024. If anyone has phished my GitHub session in the past fifteen months, they have had a year's head start on me.

This is part 3. Part 1 was npm. Part 2 was GitHub Actions. This part is the unsexy list: the controls that don't fit a single attacker narrative, that protect against many different classes of incident in small ways. Identity, network access, default credentials, attestation, the audit log you'll need when the rest of the series missed what you needed it to catch.

The thesis from Part 1 stands. Future You at 3am will not rotate the PAT. The config that makes the rotation unnecessary (short-lived expiry, fine-grained scope, SSO enforcement, audit streaming) is the one that runs while you sleep.

the PAT you forgot is in four places

Personal-access tokens hide in more places than I want to think about. Mine, when I went through them this weekend:

~/.netrc (the one git falls back to when no credential helper is set)
~/.zshrc, exported as GH_TOKEN because some script three years ago needed it
Mac Keychain, two duplicates, one expired in 2023 but the dialogue still surfaces it
A .env in a repo I haven't pushed to since last summer, committed in plaintext to the staging branch (git log -S 'ghp_' finds these surprisingly often)
One CI secret in a repo whose workflow file I deleted six months ago; the workflow went, the secret did not

That's five, not four, which is on-brand for this section.

The fix isn't "rotate them all." It's "make the next leak useless." Three configs at the org level do the work.

First, require expiration on all PATs. GitHub org settings → Personal access tokens → Require an expiration date; set the org max to 90 days (GitHub's platform ceiling is 366, but 90 is the right org default). Tokens issued before the setting keep working until their original expiry, so old tokens die naturally as they age out. No big-bang migration.

Second, enforce SSO on the org. A leaked PAT without an active SSO session can't reach SSO-protected repos. Most SaaS git-hosted orgs should have this on already; if yours doesn't, that is the highest-yield ten minutes in this post.

Third, stream the GitHub audit log somewhere SQL-shaped, with two-year retention. The default is six months. You will want eighteen months of history exactly when you need eighteen months of history. The question "did this token get used last week?" should be a query, not a support ticket.

The thing that took me longest to learn is that fine-grained PATs (github_pat_ prefix, not ghp_) let you scope a token to one repo with read-only contents and nothing else. The default scope (full account) is what turns a leaked PAT into a domain compromise. To stop typing ghp_ into shells entirely:

# ~/.gitconfig
[credential]
  helper = !gh auth git-credential
[url "https://github.com/"]
  insteadOf = git@github.com:

gh auth login once, and git push works for the rest of your career. The PAT now lives in one place: gh's keyring entry, scoped to your machine, rotated by gh whenever it likes.

identity is the perimeter

SSO + MFA + SCIM is the only thing on the unsexy list that competes with the PAT story for "worst yield from neglect." A single phished password without these is a domain admin compromise. With them, the same phish gets the attacker a soup of session cookies that expire in eight hours and an MFA prompt they can't satisfy.

The three configs, in rough order of cost:

MFA, mandatory, no exceptions. Including the founder, including the contractor, including the on-call rotation. The exception list is the attack list.
SSO for every system that supports it. Yes, Okta SSO Tax is real. Yes, it is annoying. It is cheaper than rebuilding identity after a session-token compromise. Most of the Snowflake-customer breaches of 2024 started with a non-SSO'd account.
SCIM provisioning to every system that supports it. SCIM means offboarding actually offboards. The day someone leaves, every connected system revokes their access in the same SAML attribute push. Without SCIM, the median time to fully revoke at a small startup is days, and there is always one Postgres console nobody remembered.

Fig. 2 — the no-SCIM bar is the entire window of compromise.

One nightly cron closes most of the rest of the gap:

# nightly: diff "people on payroll" vs "humans with prod access"
okta-cli list-users --status active | sort > /tmp/active.txt
aws iam list-users --query 'Users[].UserName' | jq -r '.[]' | sort > /tmp/prod.txt
diff /tmp/active.txt /tmp/prod.txt | mail -s "identity-diff $(date +%F)" sec@yourorg.io

It runs in twelve seconds and surfaces the contractor whose SCIM hook silently broke in March.

the access plane: Tailscale, IAP, PrivateLink

Nothing internal needs to be on the public internet. Anything that isn't can't be scanned by Shodan, can't be hit by a credential stuffer, can't be 0-day'd by a CVE published yesterday. The configs are different per layer, but the move is the same: take the thing off the internet and put authentication in front of it.

For shell access and internal HTTP services, Tailscale. The pitch is honest. Install the daemon on every machine, write a twelve-line ACL, you have a private network without running a VPN appliance. Replace SSH-to-bastion with tailscale ssh. Replace the internal Grafana on grafana.yourorg.io with grafana.your-tailnet.ts.net. Both stop existing on the public internet the same afternoon.

For web apps that need real auth-aware proxying (customer-facing internal tools, vendor admin panels), Cloudflare Access or Google IAP. The user hits a public URL, the proxy hands them off to your IdP, then proxies the request to a private backend. The backend has no public route.

For service-to-service inside cloud accounts, AWS PrivateLink and GCP Private Service Connect. These exist so your stripe-receiver lambda doesn't need to leave the VPC to reach Stripe's API. They are also what you need so the data warehouse in account A can reach the production database in account B without anything traversing the public internet.

Fig. 3 — same services, different boundary. The right panel is whatever Future You at 3am will thank you for.

The anti-pattern is the "we'll just rotate the bastion IP" security group. We won't. The credentials for the bastion are in a Slack channel from 2023. The bastion is one of those things that exists because someone set it up before everyone joined and nobody knows whether it's safe to turn off. The lazy answer is to make the bastion irrelevant.

the helm chart that ships with admin/admin

Every operator-installed thing in the cluster has a default password. Argo CD's admin with auto-generated password is fine, because the password isn't admin. Grafana's chart that ships with admin/admin is not fine. Jenkins ships with a random initial password printed to initialAdminPassword that most operators copy in once and never rotate. Half the database charts have password: changeme in values.yaml and the README says "you should change this," which is not the same as the chart changing it.

The lazy fix is two configs.

First, every secret in the cluster comes from external-secrets or sealed-secrets, never from a values.yaml. Pick one. The choice matters less than the consistency. Mine is external-secrets pointing at Vault, because reconciliation handles rotation upstream and the YAML stays clean.

Second, a weekly cron that hits every Service in the cluster with the top 25 default credentials and pages on success. nuclei ships a template set for this:

nuclei -t http/default-logins/ -l services.txt -severity critical,high

If it finds something, that's a real incident. If it doesn't, you have evidence, which is the audit-log argument postponed by one section.

One honest aside in parentheses: the rate at which Helm chart maintainers have moved away from default passwords is encouraging. Bitnami's PostgreSQL chart now generates a random password by default instead of changeme. The chart that ships with admin/admin today is more likely to be a private internal chart someone wrote three years ago than something current from Bitnami. (Note: the official Grafana chart still defaults to admin/admin — override it via Helm values before first install; "I'll change it later" is the part nobody does.) Check the internal charts first.

sigstore, provenance, and reproducible builds

Part 1 ended on "the next-tier defenses are real, Part 3 will name them." These are them. Sigstore signing, npm provenance, reproducible builds. Each closes a class of attack that pinning and cooldowns can't.

Sigstore for container images. cosign verify confirms an image was built by your specific GitHub Actions workflow, with your repo's OIDC identity, against a transparency-log entry that's public and append-only.

cosign verify ghcr.io/yourorg/api:abc123 \
  --certificate-identity-regexp '^https://github.com/yourorg/api/' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com

If an attacker pushes a malicious image to your registry without also compromising your CI's OIDC trust, the verify fails. Bake the verify into your deploy step; refuse to deploy what doesn't pass. That is the attested-deployment pattern Part 2 named, in one verb in your CD pipeline.

npm provenance. npm audit signatures (since npm 9.5) tells you which dependencies have published provenance attestations linking the .tgz to a specific GitHub Actions build. A package with provenance gives you a tamper-evident chain: this artifact came from this commit on this branch in this repo, built by this workflow. Coverage is uneven (most @types/* packages have it; most one-maintainer packages don't), but the trend is good. The number to track is "what fraction of my install graph has provenance?" That's your remaining audit surface.

Reproducible builds. The hardest of the three. Same source produces the same binary, bit-for-bit, on every build machine. Two implementations have shipped at scale: Debian's reproducible-builds program (reproducible-builds.org tracks coverage by package) and Nix. The lazy version, for a small team, is to build the production artifact twice on two different runners and compare hashes. If they match, your CI is reproducible enough to detect a poisoned-build attack. If they don't, you have a non-determinism bug to fix, which is also worth knowing about.

audit logs are for after the incident

Part 2 ended on "Part 3 will name the controls that exist to make the postmortem readable, not to prevent the incident." This is the section. Audit logging is what tells you whether everything in the previous six sections actually worked, what got accessed when one of them didn't, and which credential to roll at 03:11.

Three streams, all of which support direct destination handoff:

GitHub's audit log to S3, Splunk, Datadog, or whichever SQL-shaped destination you'll actually query. Settings → Audit log → Streaming. Default retention is six months; you want two years. The same goes for Okta's System Log (Reports → System Log → Stream).

AWS CloudTrail to a separate audit account, write-only from production, S3 with Object Lock and KMS-encrypted. Multi-region. The level of paranoia required is "this bucket survives a full prod-account compromise." GCP and Azure have equivalents (Cloud Audit Logs, Activity Logs).

Application audit. Stripe webhook history, Slack audit log, Google Workspace audit log. Each is one config and one Splunk index. The marginal effort approaches zero. The payoff is the difference between a one-page incident summary and a six-week panic.

The runbook for "we think we had a breach Thursday" is then a SQL query against a known schema. Without these, it's an interview with everyone who had access.

the receipts

The unsexy list is one afternoon, one quarter, and one year. The afternoon: PAT cleanup, SSO/MFA mandatory, GitHub audit log streaming on. The quarter: SCIM provisioning everywhere, Tailscale on every internal service, external-secrets across the cluster. The year: sigstore for your images, an npm audit signatures report tracked weekly, reproducible-build hash comparison in CI.

It will not catch a nation-state with patience. It will not catch an insider with a grudge. It will not catch the next Log4j the day it lands. Those are different problems with different budgets, and worth a separate post when one of them happens to one of us.

What it does: it makes the postmortem on your next incident readable. It moves "we don't know what got accessed" out of the executive summary and into "Appendix A, the SQL query." For a small team, that is the difference between recovering and rebuilding.

If you do one thing this week, generate a fresh fine-grained PAT scoped to one repo with a 90-day expiry, switch your gh auth login to it, and delete the eight-year-old ghp_ from your ~/.zshrc. The calendar reminder won't help. Future You at 3am will not rotate it. Make the wrong default impossible.

Lazy SRE's guide to secure systems, part 2: the actions you didn't pin

Harshit Luthra — Mon, 18 May 2026 16:58:05 +0000

Originally published at harshit.cloud on 2026-04-12.

Last March, someone with write access to the trivy-action repo rewrote 76 of its 77 version tags in place. The tags still resolved to aquasecurity/trivy-action — they just resolved to different commits than they did the week before. Every pipeline that ran aquasecurity/trivy-action@0.20.0 (and every other tagged version) ran the attacker's commit instead. Secrets exfiltrated. The stolen credentials chained into PyPI and took down LiteLLM. Nobody noticed for hours, because the workflow file diff was still clean.

This is part 2. Part 1 covered npm: the dependencies you didn't read. Part 2 is the same problem one level up: the workflows you didn't pin. Part 3 is the unsexy list — Tailscale, PrivateLink, IAP, the PAT you forgot.

The thesis from Part 1 stands. The best security work for a small team is the work Future You at 3am will actually execute. The configuration that makes the wrong thing impossible beats the runbook that only discourages it. With GitHub Actions, "the wrong thing" has gotten very specific over the last twelve months, and the configs to block each variety have gotten correspondingly precise.

pinning is necessary but not sufficient

The first thing the trivy-action incident proves: hash-pinning to @0.20.0 is not pinning. It's a name lookup. The owner of the repo is allowed to rewrite that name. The pin you actually wanted was:

- uses: aquasecurity/trivy-action@9b9a3f5c8a5c7e1b6e4d2f1c9b8a7e6d5c4b3a2f # v0.20.0

Full forty-character SHA. Immutable. The version comment is so the next reader knows what they're looking at; the SHA is so the workflow runs the code you reviewed.

Two GitHub features shipped in 2025 that change the math:

SHA pinning enforcement (Aug 2025). An org-level policy that fails workflow runs using unpinned actions, instead of warning about them. Settings → Actions → General → Action pinning. Turn it on. There is no "we'll get to it" version of this toggle.
Immutable Releases (Oct 2025, GA). Action authors opt in to making release tags non-rewritable after publication. If you publish actions, turn this on for downstream consumers. If you consume actions, prefer ones that have.

The lazy stance: enforcement at the org level. The workflow that doesn't have a forty-character SHA fails the run. The PR can't merge. The work of remembering to pin moves from every engineer's head to one setting.

What this doesn't catch: an attacker who compromises the maintainer account and ships a new tag at a new SHA. The SHA is real. Pinning by SHA doesn't help, because the workflow author will rev to the new version when they read the maintainer's release notes. Which is the next config.

cooldown is the same trick that worked for npm

Part 1's load-bearing config was SAFE_CHAIN_MINIMUM_PACKAGE_AGE_HOURS=48. The principle: most published malware is detected and pulled within hours. If you can wait, the wait does the work for you.

The action ecosystem has the same property, with a longer window. yossarian's analysis puts the cooldown that catches most supply-chain attacks at 7-14 days. So:

pinact --min-age 7 .github/workflows/*.yml

Refuses to write a pin younger than seven days. Add to pre-commit, your CI lint, or whatever your dependabot equivalent runs before opening the bump PR.

For Renovate users, the equivalent lives in the action manager:

{
  "packageRules": [
    { "matchManagers": ["github-actions"], "minimumReleaseAge": "7 days" }
  ]
}

That's it. Same trick, different ecosystem.

Fig. 2 — the wait is doing the work. Seven days closes most of the door; fourteen closes most of the rest.

The empirical question is whether seven days is enough. The trivy-action force-push was detected at about nine — seven would have caught most consumers, not all of them. The cost of fourteen is "your action versions lag upstream by two weeks." If your action surface is small (most teams are running actions/checkout, actions/setup-node, one cloud-login action, maybe a deploy action), set fourteen and forget.

pull_request_target is the new postinstall

Part 1 named postinstall as the single trigger that does the most damage and the single switch (ignore-scripts=true) that closes the most doors. Actions has the same shape and the same fix.

pull_request_target runs in the context of the base repository, with access to repository secrets, but is triggered by a PR from a fork. The legitimate use case is small: comment on PRs, label them, run lightweight metadata jobs. The illegitimate use case is enormous: check out the fork's code and execute it. The attack writes itself. Open a fork, modify a script the trusted workflow runs, watch the runner exfiltrate every secret in the env.

Astral, who maintain uv and ruff, wrote it cleanly: "these triggers are almost impossible to use securely." GitHub partially mitigated this in November 2025 by forcing pull_request_target to always use the default branch's version of the workflow, so an attacker can't push a vulnerable workflow on a feature branch and trigger it. But the foot-cannon still ships loaded if your default-branch workflow checks out PR-head code.

Fig. 3 — same workflow, different trigger, opposite blast radius.

The lazy stance:

Don't use pull_request_target unless you've named the specific reason and one other person has signed off.
If you do, never actions/checkout the PR head from inside it. Check out the base SHA, do the metadata thing, exit.
For everything else, use pull_request. It runs without secrets. Attacker-controlled code stays attacker-jailed.

Same shape as ignore-scripts=true. The setting that closes the class.

the safe defaults that go in every workflow

The four-line workflow header that does the most work per character:

permissions:
  contents: read

defaults:
  run:
    shell: bash -euo pipefail {0}

contents: read overrides the org-level default. If a step needs to push a tag or open a PR, that job opts back up to contents: write explicitly. The default is the safe one.

At the checkout step:

- uses: actions/checkout@<sha> # v4.2.0
  with:
    persist-credentials: false

The default behavior of actions/checkout is to leave a credential sitting in .git/config for the rest of the workflow. Later steps have shipped this credential into uploaded artifacts more than once. Opt out unless a later step in the same job needs to push.

Three secret-access rules with the same flavor:

Step-scoped env:, never workflow-scoped, for any secret.
Never ${{ toJson(secrets) }}. Exposes every secret in the project to the runner. There is no use case.
Never secrets: inherit on reusable workflows. Pass each secret by name. The reusable workflow gets exactly what it asked for.

The trivy-action exfiltration worked partly because secrets were workflow-scoped. The malicious step inherited every credential in the env, not just the one the legitimate scan needed. Step-scoping wouldn't have prevented the credential theft — but it would have bounded the blast radius to one secret instead of all of them.

OIDC, the promise from part 1

Part 1 ended on "the next-tier defenses are real, Part 3 names them." OIDC is the part of that conversation that lives here.

The trade: instead of storing an AWS_ACCESS_KEY_ID in repo secrets and praying nobody exfiltrates it, you configure AWS to trust GitHub's OIDC issuer for a specific repo, branch, and workflow. GitHub mints a short-lived (five-minute) OIDC identity token for the workflow run. The workflow trades that for STS credentials whose lifetime you set (default one hour). Nothing long-lived ever sits in the env.

permissions:
  id-token: write
  contents: read

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: aws-actions/configure-aws-credentials@<sha> # v4.0.2
        with:
          role-to-assume: arn:aws:iam::123456789012:role/github-deploy
          aws-region: us-east-1
      - run: aws s3 sync ./dist s3://my-bucket

The role's trust policy restricts the OIDC subject to your exact repo and (ideally) branch. An attacker who compromises a fork PR can't assume the role, because they don't match the trust condition. The OIDC JWT itself lasts five minutes and the STS credential is scoped to whatever you configure (default one hour). Even an exfiltrated credential gets the attacker a bounded window of scoped access, not a permanent IAM user.

For Google Cloud, the equivalent is Workload Identity Federation. For HashiCorp Vault, the JWT auth backend. Same shape across providers.

The labor here is genuinely one-time. Configure the trust relationship once per repo, delete the long-lived key, forget about rotation forever. The rotation runbook you're not maintaining is one of the better quiet wins in this post.

zizmor is the local proxy for workflows

Part 1's safe-chain sat in front of every package install and refused malware before bytes hit disk. The action ecosystem's equivalent is zizmor — a workflow linter that reads your YAML and catches the patterns this post is about, before they merge.

brew install zizmor
zizmor .github/workflows/

It catches unpinned actions, pull_request_target with PR-head checkouts, template-injection patterns where attacker-controlled input lands in a run: string, jobs with excessive permissions. Add it to pre-commit:

# .pre-commit-config.yaml
- repo: https://github.com/woodruffw/zizmor-pre-commit
  rev: v1.x  # pin the rev, obviously
  hooks:
    - id: zizmor

The principle is identical to safe-chain. Move the security check from "after the incident, in the postmortem" to "before the PR can merge, on the dev machine." The CI run is the second line of defense. The pre-commit is the first.

the receipts

The above stack is approximately one afternoon: org-level SHA pinning enforcement, pinact --min-age 7 or Renovate minimumReleaseAge: 7 days, the four-line workflow header, persist-credentials: false, no pull_request_target with PR-head checkouts, OIDC for every cloud credential, zizmor in pre-commit.

It will not catch a maintainer-account compromise that ships clean-looking code which activates weeks later. It will not catch a determined attacker who studies your build and writes a payload that survives every linter and looks innocent at PR review. Nothing in this post will. Part 3 will name the controls that buy partial mitigation against that class: sigstore, npm provenance, reproducible builds, attested deployments. And the ones that exist to make the postmortem readable, not to prevent the incident.

For a small team, the delta from this post is moving from "we're one tag-rewrite away from a credential theft cascade" to "an attacker would need a credentialed insider, or a fifteen-minute window of luck against a scoped IAM role." That's the only delta that matters at this scale.

If you do one thing this week, turn on SHA pinning enforcement at the org level. Everything else gates off that.

Blocking AI Crawlers is the New 'noindex'

Harshit Luthra — Mon, 18 May 2026 16:57:19 +0000

Originally published at harshit.cloud on 2026-01-21.

TIL: Blocking AI Crawlers is the New "noindex"

If you're blocking GPTBot, Anthropic, Perplexity, Gemini — you're trading future reach for short-term control.

the math

AI search traffic today: ~1%
AI search traffic tomorrow: 25–35%

Let them crawl. Train the discovery layer. Be early.

common AI crawler user agents

Crawler	Company
`GPTBot`	OpenAI
`ClaudeBot` / `Anthropic-AI`	Anthropic
`PerplexityBot`	Perplexity
`Google-Extended`	Google (Gemini)

the robots.txt decision

Blocking these crawlers:

User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

Feels like control. Actually it's invisibility.

why this matters

When someone asks an AI "how do I do X" and your content isn't in the training data, you don't exist in that conversation.

The sites that trained the discovery layer early will own the AI search results later.

Visibility > invisibility.

Access Denied: Edgesuite Edition - When Your Browser Extensions Become Attack Vectors

Harshit Luthra — Mon, 18 May 2026 16:57:03 +0000

Originally published at harshit.cloud on 2025-12-31.

Last week I tried booking a flight on Indigo. Access Denied. Tried MakeMyTrip. Access Denied. Ixigo? Same story. Yatra? Blocked.

My banking apps worked fine. But every travel booking site using Akamai's CDN decided I was public enemy number one. Sometimes the site would load, then the OTP API calls would silently fail. Making a complete fool out of me at checkout.

The Debugging Rabbit Hole

First thought: bad IP from my ISP's CGNAT pool. Changed my IP. Worked for 10 minutes. Then blocked again.

Second thought: maybe Akamai's IP reputation is flagging me. Checked their Client Reputation lookup.

Nope. Clean as a whistle.

Google dorking time. Found tons of users globally facing the same issue. Not ISP-specific. Not India-specific. Something else was up.

Then I found this blog that pointed at browser extensions. Interesting.

The Lightbulb Moment

Switched from Arc to Chrome. Still blocked. Because I carried over the same 21 extensions like a digital hoarder.

Here's my toolkit: Wappalyzer, Shodan, Trufflehog, DotGit, and a bunch of OSINT/greyhat recon tools. The same extensions I use for security research were making me look like an attacker to Akamai's Bot Manager.

Turned off all extensions. Instant access to every site.

What's Actually Happening

Akamai's Bot Manager isn't counting your requests. It's fingerprinting the client environment. Browser extensions can inject JavaScript, mutate the DOM, alter request behavior, and add tracking parameters — all things the client-side fingerprint will flag as bot-shaped, the same way it would flag a scraper or an injection probe.

My security toolkit became my own DoS attack vector. Poetic, really.

Some users reported User-Agent changes helped. I didn't test that. I also didn't have time to debug which of the 21 extensions was the actual culprit. Life's too short for that level of troubleshooting.

The Takeaway

WAF rules are aggressive by design. Your legitimate security tools look exactly like attack vectors because, well, they kind of are. The line between security researcher and threat actor is thinner than we'd like to admit.

If you're getting blocked by Akamai with a clean IP:

Check your extensions first, not your ISP
VPN working temporarily? That's behavioral detection, not IP blocking
The Client Reputation tool won't catch extension-based triggers
Your OSINT toolkit makes CDNs nervous

Infrastructure is meant to keep bad actors out. Sometimes it keeps infrastructure wizards out too. Not fun.

Got blocked by Akamai with your security toolkit? Which extension was your culprit? Reach out if this saved you from the same rabbit hole.

VictoriaLogs vs Loki: Real-World Benchmarking Results

Harshit Luthra — Mon, 18 May 2026 16:56:48 +0000

Originally published at harshit.cloud on 2025-11-19.

On 500 GB of logs over 7 days, on the same hardware: 94% lower query latencies, 37% smaller storage, and under half the CPU and RAM. The single number that surprised us most was the 12× drop in needle-in-a-haystack search times.

The setup

At Truefoundry we run multi-tenant ML workloads, which means fast ad-hoc search, high ingestion, live log tailing, and minimal ops on 4 vCPU / 16 GB nodes. Loki was our default, but past the 1M-active-series mark it started showing 30s+ search latencies and high I/O amplification. So we benchmarked it head-to-head against VictoriaLogs and let the numbers decide.

The contestants in one line:

Loki: Grafana Labs' log store. Compressed chunks, label-based indexing, LogQL. Brilliant Grafana integration; expensive regex scans and Go GC overhead at scale.
VictoriaLogs: VictoriaMetrics' columnar LSM log database. Per-field indices, SIMD search, LogsQL. Single binary, low memory footprint, efficient compression.

Methodology in five bullets:

Workload: 65 MB/s sustained ingestion via flog → Vector → destination
Dataset: ~500 GB over 7 days across 20 namespaces and 40 apps
Load test: Locust, 10 virtual users, 43 RPS sustained
Hardware: 4 vCPU / 8 GiB RAM instances
Tuning: Block-cache disabled to simulate cold reads

The headline figure

Before the methodology debate, here's what the seven days produced.

The memory line is the one that most directly translates into infrastructure cost. At steady state, VictoriaLogs sat around 1.3 GB while Loki held 6–7 GB. Freeing ~5 GB per node is the difference between bin-packing four tenants on a box and seven.

Query performance

Four query patterns, run against the same 500 GB / 7-day index:

Query Type	Loki	VictoriaLogs	Improvement
Stats (24h count)	2.5s	1.5s	40% faster
Needle-in-Haystack (500 GB)	12s	~900ms	12× faster
Pattern `:3000` (7d)	2.2s	2.2s	Same
Non-existent (500 GB)	Timeout	2.2s	VL completed

Key Insight: VictoriaLogs' per-token index turns brute-force line scans into index lookups. Loki, once the label filter is exhausted, has nothing left but a full scan.

The two queries that made the case, side by side:

Stats: counting logs over 24 hours

LogQL (Loki):

sum(count_over_time({app="servicefoundry-server"}[24h]))

LogsQL (VictoriaLogs):

{app="servicefoundry-server"} | stats count()

Needle in haystack: finding a single entry across 500 GB

LogQL:

{namespace="truefoundry", app!="grafana"} |= "[UNIQUE-STATIC-LOG] ID=abc123 XYZ"

LogsQL:

{namespace="truefoundry", app!="grafana"} "[UNIQUE-STATIC-LOG] ID=abc123 XYZ"

The non-existent query is the quiet one. Loki times out trying to prove a negative across 500 GB; VictoriaLogs returns "none" in 2.2 seconds. In production that's the difference between an alert that fires and a dashboard that loads.

Ingestion under pressure

We pushed both with 120 flog replicas to find the ceiling.

Metric	Loki	VictoriaLogs	Delta
Peak ingestion	20 MB/s	66 MB/s	3× higher
vCPU (sustained)	4 (throttled)	2 peak	50% lower
Memory	~4 GB	~1.3 GB	3× lower

Loki hit the CPU wall first and never recovered. VictoriaLogs absorbed the same firehose with cycles to spare.

Load test under traffic

Locust, 10 concurrent users, simulating real read traffic:

RPS handled: VictoriaLogs processed 36% higher requests per second
p99 latency: 3.6× faster than Loki under load
Tail latency: consistently lower at every percentile we measured

Why the gap is this big

Four design choices doing most of the work:

Full-text indexing. Per-token indices skip line-by-line filtering entirely.
Columnar LSM layout. Reads touch only the columns the query asks for; fewer disk seeks.
Memory discipline. Lower steady-state overhead means more headroom for everything else.
SIMD search. Vectorised inner loops on commodity CPUs add up over billions of lines.

When to pick which

Choose VictoriaLogs if:

Text search and grep-style queries are the primary workload
Ad-hoc exploration across large windows matters
Resource efficiency and bin-packing density matter
You want fewer knobs to tune in production

Choose Loki if:

Label-based queries dominate; full-text is rare
Deep Grafana ecosystem integration is non-negotiable
You already operate Loki at scale and the migration cost outweighs the wins

For us, on this workload, the resource economics decided it. The freed memory per node became real infrastructure savings within a quarter. 12 seconds turned into 900 milliseconds with no tuning, and that's the number I keep quoting six months later.

Resources

When Netlify killed my free tier: a 15-minute migration to Dokploy

Harshit Luthra — Mon, 18 May 2026 16:56:32 +0000

Originally published at harshit.cloud on 2025-10-24.

When Netlify killed my free tier: a 15-minute migration to Dokploy

Late night. Got this email: "[Netlify] Your projects have been suspended due to credit limit exceeded."

Five sites down:

linkedintel.ai (LinkedIn Sales Intelligence AI for SDR's)
sachin.cool (rookie website from college time)
dilharia.love (wedding RSVP site - yes, judge me)
My personal blog
A ex-ceo's landing page

Netlify moved legacy free tier users to their new 300-credit plan. I burned through it in a week.

New option: $9/month for 1000 credits, or figure something else out.

I had 15 minutes before my girlfriend woke up. Here's what happened.

the €3 solution

Hetzner CX22: 2 vCPUs, 4GB RAM, 40GB SSD. €3.29/month.

Math was simple:

Netlify: $108/year for credit anxiety
Dokploy + Hetzner: $42/year for unlimited deploys

I'd been watching this Dokploy video the week before. Perfect timing.

the 15-minute panic deploy

Minutes 0-5: Spun up Hetzner in Helsinki. Got the IP. Updated DNS.

Minutes 5-8: SSH'd in, ran the Dokploy installer:

curl -sSL https://dokploy.com/install.sh | sh

One command. Dokploy installed Docker, Traefik, PostgreSQL, everything.

Minutes 8-12: Connected Git repos. Dokploy makes this ridiculously easy - paste GitHub URL, select branch, done.

Minutes 12-15: Hit deploy on all 5 projects. Watched them come back to life.

The Fiance woke up. dilharia.love was live. Crisis averted.

what surprised me

SSL just works. Traefik + Let's Encrypt provision certificates automatically. I'm running Cloudflare Full (Strict) mode - zero warnings.

WWW redirects? One checkbox. Netlify charged extra for this.

Logs and monitoring built-in. No Datadog bill. No "$500/month observability platform."

the catch

You own the ops. Server goes down? That's on you. No 99.9% SLA.

You handle security: OS updates, SSH keys, backups. I run apt upgrade weekly and backup to Backblaze B2 for $0.50/month.

For personal projects? Worth it. For business-critical stuff? Pay for managed services.

one month later

Server load: 8% CPU. Zero downtime. SSL renewals automatic.

All 5 sites running smoothly: linkedintel.ai pulling data, sachin.cool looking sharp, dilharia.love collecting RSVPs.

Deployed 3 more projects since then. No credit anxiety. No surprise bills.

Total maintenance time: 10 minutes/week.

Best infrastructure decision I've made this year.

the real lesson

Free tiers aren't free. They're bait.

Platforms give you free hosting to lock you in. Make migration painful. Then change pricing when you're invested.

Netlify's legacy free tier was generous. But businesses change. VCs want returns. Free tiers disappear.

Owning your infrastructure: predictable costs, no surprises, freedom to experiment.

More work? Yes. Worth it for personal projects? Absolutely.

Delivery Service Impersonation is an Alarmingly Effective Social Engineering Vector

Harshit Luthra — Mon, 18 May 2026 16:56:16 +0000

Originally published at harshit.cloud on 2025-10-17.

TIL: Delivery Service Impersonation is an Alarmingly Effective Social Engineering Vector

Most people have minimal security awareness around address disclosure. When someone claims to be delivering a gift from a well-known local business (like a popular bakery with "Diwali hampers" or "festive boxes"), victims willingly provide their exact address or real-time location on WhatsApp. The pretext works because it combines social proof (known business), plausibility (gift delivery), and urgency (driver needs directions now).

why this attack works

The attack rides three psychological triggers at once. Mentioning a well-known local business creates instant credibility. Gift deliveries during festivals are common and expected, so the pretext doesn't trip anyone's filter. And "I'm outside and need directions now" prompts immediate action before the victim has time to verify anything.

the attack pattern

Attacker: "Hi, I'm from [Popular Local Bakery]. I have a Diwali gift
          hamper for you but I'm having trouble finding your location.
          Could you share your address or live location?"

Victim: *Shares full address or WhatsApp live location without verification*

No order confirmation requested. No delivery tracking number asked for. No verification of any kind.

why people fall for it

Gift context: during festivals, people expect surprise gifts from friends and family
Helpful nature: most people want to help someone who seems to be doing their job
Time pressure: the implied urgency ("I'm waiting outside") prevents critical thinking
Low perceived risk: sharing an address seems harmless compared to financial data
Trust in local brands: using a known local business name lowers suspicion

defense strategies

for individuals

Always ask for order/tracking numbers before sharing location
Verify with the business directly using their official contact
Ask who sent the gift and verify with them
Be suspicious of unsolicited delivery calls
Use landmark-based directions instead of exact addresses when possible

for organizations

Train employees on this attack vector
Include address disclosure in security awareness programs
Emphasize verification before sharing any personal information
Use delivery apps with in-app communication to reduce direct contact

real-world impact

This attack can be used for:

Physical surveillance and stalking
Burglary planning (knowing when someone is home)
Identity theft (address is often used for verification)
Targeted phishing (now knowing exact location)
Physical security breaches

the broader lesson

The weakest link in security is rarely the technology, it's the human element. This attack requires zero technical skill, no expensive tools, just social engineering and a phone.

When someone asks for personal information, always verify their identity first, no matter how legitimate they seem.

My Watchlist: From 70s Basements to Victorian Crime Scenes

Harshit Luthra — Mon, 18 May 2026 16:55:30 +0000

Originally published at harshit.cloud on 2025-01-12.

When I'm not wrestling with Kubernetes clusters or debugging infrastructure at 2 AM, you'll find me binging shows that either make me laugh or make me think. Here's my watchlist confession.

The Sitcom Holy Trinity

That 70's Show

There's something timeless about a bunch of teenagers sitting in a basement, roasting each other. The circle scenes, Red's threats about putting his foot somewhere uncomfortable, and Kelso's stupidity that somehow loops back to genius. It's comfort TV at its finest.

Arrested Development

"I've made a huge mistake." Haven't we all? This show rewards rewatching like no other. The layered jokes, the callbacks, the narrator's deadpan delivery - it's a masterclass in comedy writing. The Bluth family dysfunction hits different when you've seen enough corporate chaos yourself.

How I Met Your Mother (HIMYM)

Yes, I have opinions about the finale. But everything before that? Legendary. Barney's suits, Marshall and Lily's relationship goals, and Ted's endless romantic optimism somehow never got old. The slap bet alone deserves its own appreciation post.

The Detective Obsession

I'm an avid detective movie and show enthusiast. Something about watching brilliant minds piece together impossible puzzles scratches an itch that debugging production issues just can't reach.

Sherlock

Benedict Cumberbatch's Sherlock is peak detective content. The mind palace sequences, the rapid-fire deductions, the chemistry with Watson - it redefined what a detective adaptation could be. "The game is on" still gives me chills.

Detective Conan

Shinichi Kudo trapped in a kid's body, solving murders that somehow happen everywhere he goes. The Japanese detective anime that's been running since 1996 and I'm still invested. The Black Organization arc is chef's kiss.

High Potential

This one's newer, but it has a lot of potential (pun intended). The premise of a high-IQ cleaning lady solving crimes that stump detectives? Count me in. It's fresh, it's fun, and it's finding its groove.

The Common Thread

Whether it's a sitcom or a detective thriller, I gravitate toward smart writing. Shows that respect their audience, plant seeds that pay off later, and create characters you'd want to grab a beer with (or solve crimes with).

What's on your watchlist? Always looking for recommendations - especially if it involves either a laugh track or a magnifying glass.

GitHub Actions vs GitLab CI: a practical comparison

Harshit Luthra — Mon, 18 May 2026 16:55:14 +0000

Originally published at harshit.cloud on 2024-12-20.

GitHub Actions vs GitLab CI: a practical comparison

Two years, 50 microservices, two CI platforms running side by side. Some repos on GitHub, some on GitLab, same team writing the YAML for both. Here is what stuck after the marketing slides wore off.

syntax and configuration

GitHub Actions

name: CI Pipeline
on:
  push:
    branches: [main]
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
      - run: npm ci
      - run: npm test

The YAML is readable, the marketplace has an action for almost everything, and matrix builds are a single block. The nesting gets verbose once you have reusable workflows, and environment variable precedence is its own small religion.

GitLab CI

stages:
  - test
  - build

test:
  stage: test
  image: node:20
  script:
    - npm ci
    - npm test
  only:
    - main
    - merge_requests

Flatter than GitHub's nesting, Docker is a first-class citizen, and the stages concept maps cleanly to how you think about a pipeline. There is no marketplace, so reusable components come from include: files and Docker images you assemble yourself.

performance and speed

build times

A typical Node.js app on our setup builds in 3 to 5 minutes on GitHub Actions and 4 to 6 minutes on GitLab CI. Close enough that I never picked a platform on speed alone.

parallelization

Both handle parallel jobs well. GitHub Actions has cleaner syntax for matrix builds:

strategy:
  matrix:
    node-version: [18, 20, 22]
    os: [ubuntu-latest, windows-latest]

GitLab requires more manual setup for the same result.

ecosystem and marketplace

GitHub Actions marketplace

Over 20,000 actions, and the caching one is the example I keep coming back to:

- uses: actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}

One block, content-addressed cache keyed off the lockfile. The first time you delete the manual cache logic you wrote for GitLab and replace it with this, you feel it.

GitLab's approach

GitLab does not have a marketplace. You write scripts or use Docker images:

test:
  image: node:20
  cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
      - node_modules/
  script:
    - npm ci
    - npm test

More control, but more work.

docker integration

GitLab CI wins here

GitLab CI was built with Docker in mind:

build:
  image: docker:latest
  services:
    - docker:dind
  script:
    - docker build -t myapp .
    - docker push myapp

It just works. No weird permissions issues.

GitHub Actions

Needs more setup for Docker.

- name: Set up Docker Buildx
  uses: docker/setup-buildx-action@v3
- name: Build and push
  uses: docker/build-push-action@v5
  with:
    context: .
    push: true
    tags: myapp:latest

Works fine, but requires more marketplace actions.

secrets management

GitHub

env:
  API_KEY: ${{ secrets.API_KEY }}

Simple. Secrets are org/repo scoped. Works well.

GitLab

variables:
  API_KEY: $CI_DEPLOY_TOKEN

More flexible with group-level variables and environments. Better for complex setups.

cost

GitHub Actions gives private repos 2,000 minutes/month on the free tier, public repos are unlimited, and overage is $0.008/minute. GitLab SaaS gives 400 minutes/month free and charges $10 per 1,000 additional minutes, but self-hosted runners are unlimited. If you can run your own runners, GitLab gets cheaper fast at scale. If you can't, GitHub's free tier outlasts it.

self-hosted runners

GitHub

./config.sh --url https://github.com/org/repo --token TOKEN
./run.sh

Setup is straightforward. Runners are repo or org-scoped.

GitLab

gitlab-runner register
gitlab-runner run

More flexible. Can be project, group, or instance-wide. Better for large organizations.

debugging experience

GitHub Actions has clear, searchable logs, lets you re-run individual jobs, and exposes a debug mode behind two secrets. You can SSH into a runner via a third-party action, but it is not a native feature.

GitLab is the one I reach for when a pipeline is genuinely stuck. The log viewer is good, individual job retries are good, but the real difference is interactive debugging. SSH into the runner mid-job, or open a web terminal from the failed job in your browser, and poke at the filesystem while the build is still alive. The first time you do this on a Docker-in-Docker failure that only repros on CI, you stop missing it everywhere else.

when to pick which

GitHub Actions wins when you are already on GitHub, want the marketplace, and your pipelines are small to medium. GitLab CI wins when your Docker workflows are non-trivial, your runner fleet is large, your deployment strategies are gnarly, or you need to debug pipelines without a redeploy loop.

my setup

I use both. GitHub Actions for open-source and frontend, GitLab CI for infrastructure code and the deployments that involve five stages and a manual approval.

common pitfalls

GitHub Actions has a 6-hour hosted-runner job timeout, a 90-day artifact retention default (configurable up to 400 days for public repos, 90 for private), and tight concurrent-job limits on the free tier. Plan around them or pay.

GitLab's shared runners get sluggish at peak, Docker builds need docker:dind as a service container, and CI/CD variable precedence has at least six rules you will need to read twice. The one that bites me most: project-level variables silently override group-level ones with the same name.

migration tips

GitHub to GitLab

# GitHub
- uses: actions/checkout@v4

# GitLab equivalent
git clone $CI_REPOSITORY_URL
cd $CI_PROJECT_NAME

GitLab to GitHub

Most scripts translate directly. The win is collapsing a few of them into marketplace actions you no longer have to maintain.

Starting fresh, pick whichever platform already hosts your code. The integration tax of running CI on the other vendor outweighs every syntax preference in this post. Whichever one you pick, the only investment that pays back is making the pipeline fast. A slow CI is worse than no CI; it just costs more to ignore.

DEV Community: Harshit Luthra

How to bypass corporate MDM and AI gateways on Claude Code

what's an MDM, in three sentences

the managed-settings situation

why rm doesn't work

the cleanup script

the launchd arms race

the AI gateway angle

bypassing the gateway

should you actually do this

what these scripts don't do

Lazy SRE's guide to secure systems, part 5: the dev laptop is the perimeter

MDM is the table you set first

hardware keys, one-time spend

EDR is where the budget goes

the password manager and browser hygiene argument

the personal device problem

the receipts

Lazy SRE's guide to secure systems, part 4: the four DNS records

SPF, and the include trap

DKIM, in DNS

DMARC, the part that does the work

CAA, two lines to gate cert issuance

the monitors

the receipts

Lazy SRE's guide to secure systems, part 3: the unsexy list

the PAT you forgot is in four places

identity is the perimeter

the access plane: Tailscale, IAP, PrivateLink

the helm chart that ships with admin/admin

sigstore, provenance, and reproducible builds

audit logs are for after the incident

the receipts

Lazy SRE's guide to secure systems, part 2: the actions you didn't pin

pinning is necessary but not sufficient

cooldown is the same trick that worked for npm

pull_request_target is the new postinstall

the safe defaults that go in every workflow

OIDC, the promise from part 1

zizmor is the local proxy for workflows

the receipts

Blocking AI Crawlers is the New 'noindex'

TIL: Blocking AI Crawlers is the New "noindex"

the math

common AI crawler user agents

the robots.txt decision

why this matters

Access Denied: Edgesuite Edition - When Your Browser Extensions Become Attack Vectors

The Debugging Rabbit Hole

The Lightbulb Moment

What's Actually Happening

The Takeaway

VictoriaLogs vs Loki: Real-World Benchmarking Results

The setup

The headline figure

Query performance

Ingestion under pressure

Load test under traffic

Why the gap is this big

When to pick which

Resources

When Netlify killed my free tier: a 15-minute migration to Dokploy

When Netlify killed my free tier: a 15-minute migration to Dokploy

the €3 solution

the 15-minute panic deploy

what surprised me

the catch

one month later

the real lesson

related posts

Delivery Service Impersonation is an Alarmingly Effective Social Engineering Vector

TIL: Delivery Service Impersonation is an Alarmingly Effective Social Engineering Vector

why this attack works

the attack pattern

why people fall for it

defense strategies

for individuals

for organizations

real-world impact

the broader lesson

why `rm` doesn't work