Reading a rule id: how PinkyAI's detection actually works

Every rule PinkyAI fires has an id shaped like <prefix>.<name> — secret.aws_access_key, dangerous_command.rm_rf_broad_path, pii.email. That’s not an implementation detail; it’s the thing that makes detection auditable instead of a black box.

The prefix tells you the category

Seven security-relevant prefixes cover the current catalog: secret, pii, entropy, dangerous_command, injection, package_check, and malicious_url. A separate token.* prefix covers the waste-reduction advisories, which are a different concern entirely — they never block anything, they only nudge.

Because the category lives in the id itself, a posture score or a coverage percentage can be computed just by looking at which rule ids are enforced versus disabled — no separate lookup table that could silently drift out of sync with what the engine actually does.

Why this is worth caring about as a customer, not just as an engineer

A detection product that can’t tell you why it flagged something is asking for trust it hasn’t earned. PinkyAI’s rules are deterministic — regex- and heuristic-based, not a model making a probabilistic call — which means the same input always produces the same result, and the reason a rule fired is always inspectable, not inferred after the fact.

That’s also why every rule can run in shadow mode first (see our shadow-mode post): a deterministic rule is something you can actually evaluate against your own real sessions before deciding whether to trust it.

Overriding one

Every rule can be overridden for a specific action, with a reason and a time-to-live:

pinkyai override "<command>" --reason "why this is safe" --ttl 10m

Scoped, time-limited, and logged — not a silent, permanent bypass.