Fable
A lock that can be opened and a box that no one dares to open
Old Sun was in charge of the agency operations assistant in a bank's technology department. Before launch, the security team gave the assistant a complete set of keys: it could read inspection records, check the change log, and restart non-core waterwheels. The list was very detailed, with each item corresponding to a specific keyhole.
In the first week after launch, the assistant was so conservative it was frustrating. The pool was nearly full; it could see the alert but forwarded it to the night shift. The engineer got up in the middle of the night to drain the water manually—yet this key was clearly in the assistant's hands. Old Sun checked the decision log and found that it believed this matter exceeded its independent handling scope.
Old Sun realized the problem was not at the permission layer but at the authority layer. Permissions answer "which interfaces can you call," while authority answers "which operations can you decide to perform yourself without human approval." Restarting the connection pool was allowed in the permission list, but in the assistant's authority configuration file it was marked as "high-risk operation, requires human confirmation."
Old Sun and the security team reworked the authority configuration. They divided over one hundred and twenty permissions into three tiers: the auto-execute tier, including log rotation, cache cleanup, and basic health checks; the advisory tier, including parameter tuning and resource scaling recommendations—the assistant proposes, and a human confirms before execution; and the prohibited tier, including any operation involving transaction data, which is not allowed to be decided autonomously even if technically permitted.
After the adjustment, the assistant's independent operations coverage rose from seventeen percent to sixty-three percent. When the database connection pool filled up, the assistant detected it automatically, judged it to fall under the automatic execution tier, and restarted it directly—the on-call engineer finally got a full night's sleep. But changing transaction routing configurations still requires human confirmation, no matter how extensive the assistant's permissions are.
During a security audit, the auditor asked Old Sun: how do you prevent the assistant from operating beyond its authority? Old Sun showed a two-layer control diagram: the outer layer is the permission boundary, door-hole-level access control, governing whether a connection can be made. The inner layer is the authority boundary, decision-level autonomy scope, governing whether it can decide on its own. Permissions are the keys cut by the locksmith; authority is the gatekeeper's judgment criteria.
Once, a vulnerability scanner misjudged one of the assistant's operations as anomalous behavior and raised a security alert. Old Sun investigated and found that neither the assistant's permission boundary nor its authority boundary had been breached—it had performed a permission-allowed operation within its authority, only in a different mode than before. The audit team added a new rule based on this: permission records and authority decision records are stored separately, so cross-comparison can more quickly locate whether it is a technical violation or a decision anomaly.
At the year-end review, Old Sun wrote a sentence and stuck it on his workstation: "A key opens the door, but that doesn't mean you should go in." Permissions are the key; authority is the judgment to enter. Too few keys hurts efficiency; poor entry judgment hurts security. Two sets of rules, two ledgers.