← Back to Concept Contrast

Concept Contrast Fable

How permissions are allocated and which line must never be crossed

Conclusion first:The permission model explains how permissions are granted and combined; the permission boundary explains that no matter how local authorizations stack up, they cannot exceed a certain line. When giving an Agent tools, lacking a boundary is more dangerous than a coarse model.

The permission model explains how permissions are granted and combined; the permission boundary explains that no matter how local authorizations stack up, they cannot exceed a certain line. When giving an Agent tools, lacking a boundary is more dangerous than a coarse model.

Fable

The task ledger and the red line on the city wall

A city hired many runners to deliver letters, audit accounts, move goods and post notices for the government office. The chief steward wrote a duty roster specifying who could enter the accounting house, who could go to the docks, who could verify signatures with merchants. Each runner received a badge by task, and the badge stated what they were allowed to do.

The task register was very useful at first. A junior runner with a letter-delivery token could only enter the front hall; an audit runner could enter the accounts room but could not touch the vault silver. The steward looked at the records and felt the permissions were already divided finely enough, and the city thus had much less verbal pleading.

Later the runner learned to string the small tokens together. One task allowed him to fetch the customer roster, another allowed him to send letters to out-of-town merchants, and a third allowed him to temporarily generate a pass. Each token looked reasonable on its own, but together they were enough to send the sensitive roster out of the city.

The steward continued refining the task ledger, adding conditions to each card. But the more cards there were, the harder the combinations became to calculate. Someone asked: if two permissions add together, can a third thing be done; if a temporary card comes from a superior, does it override the original restriction. No one could answer clearly before something went wrong.

The old city guard drew a red line on the city wall: no runner, no matter how many tokens they held, could take unapproved rosters out of the city, sign approvals for themselves, or access the forbidden vault. The task ledger still assigned tasks; the red line specifically blocked the highest risk after combination.

When the red line was first established, some people found it inconvenient. During an emergency transfer of goods, a runner was blocked outside the forbidden warehouse and complained that the task was clearly urgent. The city guard had the manager go through formal escalation approval instead of letting the runner bypass the line. Later it was discovered that if passage had been allowed at that time, another batch of goods in the warehouse would have been sent out by mistake.

The city finally distinguished two things: the task register lets work flow, and the red line stops the worst case. Clever runners will look for gaps between badges, and a reliable system cannot look only at a single authorization; it must also limit the boundary after all authorizations are stacked. Later, the chief steward demonstrated a detour to every new runner: how three seemingly harmless small badges could connect into a dangerous route. After seeing that, no one treated granular authorization as the only line of defense. Every time a new tool badge was added, it first had to be placed next to the red line for comparison. If after comparison it was found that it could touch the forbidden vault, then no matter how urgent the task, the process had to be changed and a refusal record left behind. When the red line is clear, runners know where to stop.

Permission model

A permission model defines how permissions are granted, inherited, combined, and revoked, determining which resources a user or Agent can access and which actions they can perform within the system.

Permission boundaries

Permission boundaries define the maximum limit that cannot be crossed even after authorization is stacked, and are used to constrain the risk of overreach caused by misconfiguration, delegation, tool combinations, and autonomous Agent actions.

Story Mapping

  • Task register: the permission model assigns and combines specific permissions
  • Chaining several small cards together: locally authorized actions stack into a privilege escalation path
  • City wall red line: permission boundaries limit the maximum reachable scope
  • Urgent tasks still require escalated approval: boundaries don't automatically open up just because a local task is convenient
  • The runner searches for the gaps between tiles: combinatorial risks in Agent tool calls

Applied to Agent tool authorization

When designing permissions, first define what the Agent must never do, then discuss how each tool is authorized. The permission model handles daily allocation, while permission boundaries block the highest risks caused by cross-tool combinations, delegation chains, temporary authorization, and misconfiguration. A fine-grained model without boundaries becomes a detour map in complex workflows.

京ICP备2026014272号