Why the per-key options matter as much as the key itself

It's easy to focus on whether a key is present and skip past the comma-separated options prefix, but those options can change what a key is actually allowed to do far more than the key's type or length. A `command="..."` option forces every connection using that key to run a single fixed command regardless of what the client requests — the standard way to hand out a key that can only run a backup script, not a shell. Options like `no-port-forwarding`, `no-X11-forwarding`, and `no-pty` strip capabilities a key would otherwise have. Auditing an `authorized_keys` file for what a key is scoped to do means reading the options, not just confirming a key exists.

A stale or overly broad file is a common, quiet risk

authorized_keys files accumulate over time — a contractor's key from a project that ended two years ago, a key added for one-off automation that was never removed, a key with no restricting options that could have had one. None of that is visible from the file's size or a quick glance; it only shows up when each line is actually parsed and read. Running an `authorized_keys` file through a structured parser like this one periodically is a lightweight way to catch what's actually granted before it becomes a "how did that key get access" incident.