Working Safely on a System You Don't Own

Earlier chapters covered getting access. This one is about what happens once you have it — specifically on a system that belongs to someone else's team, where the ordinary confidence of working on your own infrastructure doesn't automatically apply.

Confirming Authorization and Scope Before Touching Anything

Before making any change — not just diagnosing — on a system that isn't yours to freely administer, confirm explicitly: who actually owns this system, what are you authorized to do on it (read-only diagnosis? specific fixes? anything at all?), and is there a change-approval process that applies here. This is a genuinely different question from "do I have access" — having access and being authorized for a specific action are not the same thing.

The Trivially-Easy Mistake: Wrong Host, Wrong Session

Remote access tools make it genuinely easy to lose track of which session is connected to which host, especially with several near-identical terminal or RDP windows open side by side. A command meant for staging, accidentally run against production because the wrong window happened to have focus, is a classic and genuinely damaging mistake — not a rare, exotic failure.

A Practical Habit: Read the Prompt Before You Type

Literally look at the shell prompt — typically user@hostname — immediately before running any command that changes state, not just once at the start of a session. This is the single cheapest check against the wrong-host mistake, and it's worth building as a deliberate habit precisely because it's easy to stop doing once a session feels routine.

Dry Runs and Confirmation Prompts

Many tools support a dry-run or "show what would happen" mode — rsync --dry-run, a package manager showing its plan before applying it. Using these before the real action, especially on an unfamiliar or high-stakes system, catches a mistake before it happens rather than after. Related: don't habitually bypass built-in confirmation prompts (scripting -y or --force by default) specifically on systems you don't own or aren't deeply familiar with — the extra friction of a confirmation prompt is doing genuinely useful work in exactly this scenario.

When in Doubt, Ask — Even If It Feels Slow

On an unfamiliar system, especially one owned by another team, asking "can you confirm it's safe to do X here" before acting isn't a sign of incompetence — it's good practice, the same discipline Incident Response & Ticketing Workflows already applied to escalation timing: acting alone past the point where checking would be faster costs more than the moment spent asking.

Documenting What You Did, Even Outside a Formal Incident

Even for routine work — not a formal incident — briefly noting what you changed on a system you don't own, and when, and why, is genuinely valuable for the team who actually owns it, since they'll otherwise have no record of why their system's state changed. A lightweight version of Chapter 5's own live-timeline discipline, applied to any change on someone else's system, not only formal incident response.

Working Example: A Close Call, Caught in Time

An engineer is about to run a cleanup script, and pauses — the practical habit from earlier in this chapter — to read the prompt first: root@prod-db-3, not the expected root@staging-db-1. The mistake is caught before anything runs. A brief, blameless note goes to the team anyway: what nearly happened, and why — not to assign fault, but because a near-miss is exactly the kind of information worth sharing, in the same spirit as Incident Response & Ticketing Workflows' own blameless review. Hiding it out of embarrassment would only mean the same near-miss is more likely to happen again, to someone else, with no warning.

Hands-On Exercises