The Phone Call
When your computer needs something from another computer, it makes a phone call. It looks up a phone number in a phone book (DNS), it dials (HTTP or HTTPS), the other computer answers and runs three checks — who are you, do you have permission, what are you asking for — and then either gives you what you asked for, hangs up, or says “too many calls, try again later.” The whole conversation is just that. Everything else is implementation detail.
Plain-Language Key — What These Words Actually Mean
spacepulse.space) into computer addresses (192.168.1.1).www.example.com CNAMEs to example.com.Why This Tab Exists (the freight train context)
An hour before this lab was written, a Cloudflare AI agent was supposed to fix a small business’s security settings. It said it would. It didn’t. It never returned an error. It just stopped. That’s a real, nameable failure mode: silent failure with no error state feedback. An informed user should be able to recognize that pattern, name what should have happened instead (a clear HTTP code), and demand better from the systems they pay for. You’re going to know all the words in this tab by the time you leave it.
The Locks
You already understand locks. This is just locks on phone calls. A key proves who’s calling. A permanent key is a house key under the doormat — if anyone copies it, anyone gets in. A temporary token is a hotel key card — if stolen, it stops working at noon tomorrow. Least privilege means a key that opens only the door it’s supposed to. None of this is exotic. It’s the way you already think about your front door, your car, your office.
The “Millions of Machine Identities” Moment
Your payroll system calls the IRS database something like 847 times a day. Each call carries a key. Each key was issued by someone, can be revoked by someone, and gets rotated by someone (or doesn’t). Across one mid-size company, that’s easily hundreds of thousands of keys in flight. CyberArk research notes that 68% of organizations lack identity security controls, and AI agents are creating more privileged identities in 2025 than any other technology. The number, made real, is the lesson: most of the people responsible for those systems cannot explain what an API call is. That gap is why this lab exists.
Proxy vs DNS Only — The Orange Cloud
When you proxy traffic through a CDN or a firewall (Cloudflare’s orange cloud, in their UI), the protective layer sits between the public internet and your actual server. Visitors hit the CDN; the CDN talks to you. Your real address never leaves the building. DNS-only mode (gray cloud) means the address book points directly at your server — the guard at the gate has been told to step aside. Both modes work. One is hiding behind a guard; the other is standing in the doorway. For anything that holds data, behind the guard is the answer.
The Signs on the Door
Most websites leave a public note outside the building that tells automated callers what they’re allowed to do. Another note tells security researchers who to call if they find a vulnerability. Most people don’t know either note exists. They’re short, readable, written in plain text. You’re going to read three of them and recognize the shape, and then we’ll walk through the seven HTTP response codes that an informed non-expert should be able to name.
robots.txt — The Welcome Mat Note
A note the website leaves outside saying which doors robots are allowed to knock on. Crawlers (search engines, archive bots, AI scrapers) are expected to read it first and behave accordingly. It’s a social contract, not a lock. A robot that ignores the note may get IP-banned, may face legal action, may just look bad — but the note itself doesn’t enforce anything. Size of the file ≈ how much the company has thought about automated access.
Small Business (one-liner)
User-agent: * Allow: /
Everyone, everywhere, anything. No file at all is even less restrictive — an unlocked door with no note.
Wikipedia (selective)
User-agent: * Disallow: /wiki/Special: Disallow: /wiki/Search Disallow: /wiki/Random Allow: / Sitemap: /sitemap.xml
Block specific noisy paths, allow the rest, point crawlers at the sitemap. Reasonable defaults for a large public-knowledge site.
Google (~500 lines, excerpted)
User-agent: * Disallow: /search Disallow: /sdch Allow: /search/about Allow: /search/static Disallow: /maps? [ ... ~480 more lines ... ] User-agent: GPTBot Disallow: / Sitemap: /sitemap.xml
Hundreds of paths, dozens of named crawlers, individual policies per bot. This is what “deeply thought through” looks like.
security.txt — The Emergency Contact Note
A newer standard (RFC 9116). A file at /.well-known/security.txt that tells security researchers “if you find a problem, here’s who to call.” The 10-feet-inside-the-warning-track moment: we’re showing how the good guys report problems, not how to exploit them.
Typical security.txt (real example, redacted)
Contact: mailto:security@example.com Contact: https://example.com/security-form Expires: 2026-12-31T23:59:59z Encryption: https://example.com/pgp-key.txt Preferred-Languages: en, es Canonical: https://example.com/.well-known/security.txt Policy: https://example.com/responsible-disclosure
Six lines. Email, encryption key, expiration date, language. A researcher who finds a vulnerability has a clear path to report it without guessing whether the company even has a security team.
HTTP Response Codes — The Seven That Matter
When a server responds to a phone call, it returns a three-digit code that says what happened in machine-readable form. There are dozens defined — you only need to recognize seven. The Cloudflare AI that didn’t tell you it failed should have returned one of these. That’s the literacy move: when something silently stops working, ask “what code was returned?”
| 200 | OK | fine — here’s what you asked for |
| 401 | Unauthorized | your key is wrong or missing |
| 403 | Forbidden | your key is fine, you just don’t have permission for this |
| 404 | Not Found | the address you dialed doesn’t exist |
| 429 | Too Many Requests | slow down — rate limit hit |
| 500 | Internal Server Error | their server broke — not your fault |
| 503 | Service Unavailable | their server is overloaded or under maintenance |
The Silent-Failure Anti-Pattern
A well-designed system that fails returns one of those seven codes (or a sibling) and the system that called it can react. A badly-designed system that fails does not return anything — it just stops responding, or returns 200 with an empty payload, or worse, returns 200 with a misleading response. Silent failures are the worst kind because the caller thinks everything worked. If you’re paying a vendor for an AI agent, an API, or an automation pipeline, the right question to ask is: “what error codes will you return when things break, and how do I subscribe to them?” If the answer is “we’ll tell you in the dashboard,” that’s not enough.
What You’re Responsible For
You don’t need to understand every wire in the wall to know that you shouldn’t ignore a burning smell. This is the burning-smell checklist. Three columns — what runs automatically without you, what you (yes you) are responsible for, and what you should be asking your vendor or your IT person. Not a lecture. A checklist.
✓ Runs Automatically
- Rate limiting — bouncing calls that come in too fast
- TLS encryption — the HTTPS sealed envelope
- Server-side auth — the receptionist checking IDs
- Load balancing — when traffic spikes, spreads visitors across servers so none drowns (the Clarksville sinkhole cascade, browser-style: when one basin fills, route to the next)
- DMARC on a properly configured domain
- Bot Fight Mode / WAF rules on a properly configured CDN
This is already running. You didn’t break it. Don’t turn it off.
✓ YOU Are Responsible
- Key rotation — schedule it, do it, document it
- Least-privilege review — once a quarter, who has access to what, why
- MFA on every account — single biggest protection per dollar of effort
- Knowing who has access — the offboarding list when someone leaves
- Watching for the burning smell — unexplained logins, key alerts, unexpected charges
- Backups — not just having them; testing they restore
If nobody checks this, nobody checks it. The first person who notices is the person responsible.
✓ Ask Your Vendor / IT
- “What error codes will you tell me about?”
- “Do you have a
security.txt?” - “What’s your rate limit, and what happens when I hit it?”
- “Where are your logs, and how do I get to them?”
- “What’s your incident notification policy?”
- “Is my key rotated automatically or do I have to do it?”
- “Where do your AI agents store credentials — mine, or theirs?”
An informed non-expert can ask all of these. If the vendor can’t answer them, that’s the answer.
The Silent-Failure Demo
Good design: something fails → system returns an HTTP code → your dashboard pings → you see the failure within minutes → you act on it. Bad design: something fails → system returns nothing → your dashboard shows green → you find out next week when a customer complains. The difference between these two patterns is the difference between “ran into a problem” and “had an incident.” You should be able to name this pattern when you see it, and you should be willing to push back on vendors who design the bad version.
The 10-Foot Boundary, Stated Plainly
This lab teaches you to understand and protect systems you’re responsible for. It does not teach exploitation, vulnerability research, or penetration testing. Those require credentials, ethics agreements, and supervised classroom space — they live down the hall in Zone D, behind badge readers, with College VIII (Law & Ethics) frameworks wrapped around them. You’re 10 feet inside the warning track. That’s the right place to be.
The DOSA Close
You’re standing in DOSA — the building’s name is deliberately dual: Denial of Service Attack and Delivery of Security Always. Same word, same building, two meanings, one philosophy. Down the hall, behind the badge readers in Zone D, students learn to attack systems so they understand how to defend them. You don’t need to go in there. You just learned the line every DOSA student is told on day one:
“The defender has to be right every time.
The attacker only has to be right once.
That asymmetry defines the profession.”
Now you know enough to tilt that asymmetry back a little. That’s what literacy is for.
About This Lab
The Call is the first lab in College I — Cybersecurity & AI Ethics, located in DOSA Building 1, Zone A (public lobby). Dean: Dr. Luna “Lynx” Lee Rodriguez. Access-control architecture credited to James Whitfield (Corridor Sentinel). Self-led — no instructor tab; the tabs are the teacher.
Sister coursework in development: HASS (Human-AI Systems Stewardship, Three Gauge Test, GFAS detection) lives separately. Zone D coursework (offense, pen-testing, vulnerability research) is gated behind badging and College VIII legal frameworks — not accessible from this lab and not taught here. Same building. Different room. The architecture is the boundary.
The Cloudflare-agent worked example from CLAUDEDEV Amendment C (silent-loop UX friction) is the live reason this lab exists. The freight train hit Travis mid-Cloudflare session. The literacy is the response.