Skip to content

CONCEPT Cited by 4 sources

Policy-as-data

What it is

Policy-as-data stores authorization policies outside application code — in a database, a dedicated policy store, or a config bundle — so they can be changed, audited, and reasoned about independently of code deploys. The runtime reads policies from the store at evaluation time (often with caching).

Contrast with policy-in-code: if user.role == "admin" { allow(); } sprinkled through the codebase. Every policy change is a code change; policies are invisible to auditors; no unified analysis is possible.

Why it matters

  • Change velocity. Authorization policy change cadence typically exceeds code change cadence — new tenants, new roles, new regulatory requirements. Coupling them slows both.
  • Auditability. A single store of all policies is trivially auditable; policies scattered through code are not.
  • Analyzability. A single store of policies written in a formal language (Cedar) is amenable to automated reasoning — equivalence, reachability, redundancy, policy-change impact analysis.
  • Separation of duties. Policy authorship can be gated by a different role (infosec) than code authorship (app teams).

Governance flow

Convera's production shape:

Cedar policy authors (infosec team, regulated IAM role)
  → Write policies into DynamoDB (source of truth)
  → DynamoDB Streams capture changes
  → Continuous-sync pipeline propagates to AVP policy stores
  → Lambda authorizer evaluates at request time

Key properties:

  • Write-side IAM-bounded. Only infosec can author policies, via a regulated IAM role.
  • Read-side app-bounded. The Lambda authorizer reads evaluated decisions, not raw policies.
  • Asynchronous propagation. DynamoDB Streams + sync pipeline means policy changes propagate on a bounded (but non-zero) delay; cache TTLs at API Gateway define the effective floor.

(Source: sources/2026-02-05-aws-convera-verified-permissions-fine-grained-authorization)

Relation to spec-driven development

Policy-as-data is a special case of concepts/specification-driven-development — the policy is the spec, the runtime is the executor. Cedar's analyzability-by-design makes the spec subject to proof: policies can be proven equivalent, policies can be proven to never reach a given resource, policies can be proven redundant. This is why policy-as-data + Cedar + AVP is a coherent stack — the surface, language, and engine were co-designed around the policy-as-data premise.

Caveats

  • Cache-invalidation is the propagation floor. Policy change → authorizer-decision-cache TTL is the time before a new policy takes effect. Convera's source doesn't discuss this tradeoff.
  • Policy-store size limits matter. Each engine has quotas; at scale, per-tenant policy stores (per-tenant-policy-store) are needed not just for isolation but for quota reasons.
  • Dynamic attribute lookups still happen. "Policy as data" is about the policy text, not the attributes it references; those still need authoritative sourcing at evaluation time.

Seen in

  • sources/2026-02-05-aws-convera-verified-permissions-fine-grained-authorization — Convera stores Cedar policies in DynamoDB, uses DynamoDB Streams to continuously sync into AVP; authorship gated by regulated IAM role; authorizer reads decisions via AVP at request time.
  • sources/2026-02-17-allthingsdistributed-byron-cook-automated-reasoning-trust-ai — the AWS policy-interpreter decade-of-proof lineage; Cedar + AVP are the public extraction of internal policy-as-data work.
  • sources/2026-02-26-aws-santander-catalyst-platform-engineering — infrastructure-provisioning-time realization: Santander Catalyst's policies catalog is "a central repository of policies ensuring compliance and security across all operations using Open Policy Agent" (systems/open-policy-agent / Gatekeeper). Rego policies live in the catalog separately from Crossplane XRDs or application code; enforced at Kubernetes admission time (policy-gate-on-provisioning). Same discipline as Convera (policies in a dedicated store, versioned, authored by security team, evaluated by a dedicated engine), different enforcement layer (K8s admission vs API Gateway authorizer) and different policy language (Rego vs Cedar). Third wiki instance of the concept alongside Cedar/AVP and AWS SCPs.

  • sources/2026-08-31-dropbox-testing-cookie-behavior-across-hundreds-of-web-surfaces-with-our-in-house-auditor — classification-as-data for a test oracle. Dropbox keeps its cookie classifications (approved cookies, known exceptions) out of the cookie auditor's source code so the Privacy team can update the list without an engineering release. Same core benefit as the authz instances — the classification's change cadence (new services, new regulatory guidance) exceeds code cadence, so decoupling it from deploys lets privacy protections keep pace. Here the "policy" is the definition of correct behavior a checker asserts against, not an authorization decision — extends policy-as-data from the enforcement plane to the verification/test-oracle plane.

  • sources/2026-09-08-databricks-build-durable-agents-with-temporal-and-lakebase — policy-as-data served to a running agent via a synced table, no Worker redeploy. Underwriting thresholds (min credit score, auto-approve DTI, hard-decline thresholds, policy name) live in Unity Catalog as the source of truth; a continuous Lakebase synced table (agent_policy.underwriting_policy_limits) makes them a read-only Postgres copy that the agent's policy_lookup queries by normalized loan purpose. Policy owners edit the UC source, the sync pipeline propagates, and a later run reads the new value without a Worker or API deployment — the canonical policy-change-cadence-exceeds-code-cadence benefit, here for business/underwriting policy rather than authz. The emitted policy result records every rule's threshold, actual value, pass/fail, source, and rationale (policy decisions are themselves data). A demo fixture_fallback path exists when Lakebase is unavailable; the article notes a regulated Workflow might instead fail closed, and that the application must make that fallback choice explicitly. (Source: sources/2026-09-08-databricks-build-durable-agents-with-temporal-and-lakebase)

Merged aliases

  • authentication-policy-engine
  • permissions-dsl
  • security-model-as-data-model
Last updated · 766 distilled / 2,225 read