← Back to concept explainers

Concept Fable

Policy as code

Conclusion first:Policy as Code expresses security, compliance, and business governance rules as machine-executable code, and manages these rules through version control, testing, approval, deployment, and auditing. For enterprise Agents, it allows tool permissions, data access, approval thresholds, and compliance constraints to be continuously delivered, automatically verified, and enforced by a policy engine.

Policy as Code · Governance/Security

Read the story first. There is no rush to give a definition here; let the question grow on its own first.

Fable

Only after the city ordinance was carved into movable type could it withstand revision, testing, and questioning

Yancheng's rules used to be written on notices. Every time tax rates, shipping schedules, or embargoed goods changed, the clerk would recopy them and post them at each dock. After automated ledger ships appeared, notices were no longer enough. The ledger ships needed to make immediate judgments before invoicing, releasing goods, and reviewing—they couldn't wait for boatmen to run and read the small print on the wall.

The clerk first bound the notices into a booklet for each dock to follow. As a result, different docks understood them differently, and the same batch of salt could pass at the east gate but was stopped at the west gate.

After a tax rate adjustment, the north dock failed to replace an old notice, and the account ship released goods under the old rules. The error was not large, but no one could say clearly which version of the rules should have been in effect at that moment.

In the city, important city ordinances were changed to movable type. Each rule had a number, version, example, and approval record; before changing the type, it was tested in a sandbox to see which ships would be affected.

Every judgment of the ledger ship read the movable-type version of the rules. If the result was abnormal, the clerk could point out which rule, which version, and which modification caused the change. Later, when a compliance inspection arrived, the clerk no longer hauled out a pile of notices. He showed the rule book, test records, approval chain and execution traces.

The first error happened in the middle of the night. The ledger boat released a batch of salt sacks according to the old notice, and only at dawn did they learn the ban had changed the night before. The clerk said he had posted the new paper; the boatman said the dock was too dark to see it. If rules only hang on the wall, they can't keep up with every judgment.

Later Salt City wrote the rules into executable decrees that the ledger ships could directly enforce. When a ship arrived, a ticket was issued, or goods passed through the warehouse, the decree would immediately check the date, cargo type, origin, and permissions; changing the rules no longer meant only changing a notice, but changing the same executable decree and having all docks sync. The words on the wall were for people to read; the rules in the ships were responsible for actually blocking actions. The clerk's job also became easier. In the past he had to guess which dock had or hadn't read the new notice; now he only maintained the same decree in one place and checked whether each ship executed it. Only when rules moved from paper into action did disputes decrease greatly.

Yancheng learned that if governance rules are to enter automated execution, they cannot just be scattered in documents. They must be executable, testable, version-controlled and subject to after-the-fact review.

Reveal

This story is about: policy as code

Policy as Code expresses security, compliance, and business governance rules as machine-executable code, and manages these rules through version control, testing, approval, deployment, and auditing. For enterprise Agents, it allows tool permissions, data access, approval thresholds, and compliance constraints to be continuously delivered, automatically verified, and enforced by a policy engine.

What matters is that it is not just a term, but a structural problem that repeatedly appears in real AI / Agent systems. Understanding it lets you judge when to add a model, when to change a process, and when to add governance.

Metaphor mapping

  • Paper notice: manual policy document
  • Automatic ledger ship: an Agent requiring real-time rule-based judgment
  • Different docks understood it differently: manual interpretation led to inconsistent execution
  • Movable type rule: Policy as Code
  • Numbers, versions, and test cases: rules that can be versioned and tested
  • Sandbox run: pre-deployment strategy testing
  • Rule repository and execution logs: auditable governance evidence

Andy Ren Xu's judgment

The practical value of this concept is that it helps you break "AI features that look smart" into deliverable, verifiable, and governable units of work.

policy engineOPAguardrailsCI/CD controlsautomated compliance
京ICP备2026014272号