« Phase 09 · Warmup · Track Overview

Hitchhiker's Guide — The Control Plane

The fast orientation. What the pieces are, what they are called, and how they fit — before the deep dive takes them apart.

Table of Contents

• 1. Don't panic: the one-paragraph version
• 2. The map
• 3. The vocabulary
• 4. The request path, end to end
• 5. What lives where
• 6. The five things that will surprise you
• 7. Reading a policy engine
• 8. Where the neighbouring phases connect
• 9. What to build first

1. Don't panic: the one-paragraph version

The control plane is the part of the platform that knows what agents exist, what they are allowed to do, and whether they are currently in a fit state to do it. It answers two questions — what can this principal see? and may this principal do this? — and it answers them from local material, because putting it on the synchronous request path would make its availability a multiplier on the platform's. The material is a signed, versioned policy bundle plus a registry of agents and tools; when the source is unreachable, the enforcement points keep using the last known-good bundle, alarm on staleness, and eventually refuse.

2. The map

                       ┌────────────────────────────────────────────┐
                       │              CONTROL PLANE                 │
                       │                                            │
   policy source ──►   │  agent registry ─┐                         │
   (git → CI → sign)   │  tool registry  ─┼─► capability discovery  │
                       │  eval pipeline  ─┘                         │
                       │        │                                   │
                       │        └──► posture signals                │
                       └──────────────────┬─────────────────────────┘
                                          │  signed bundle, pushed
                                          │  (NOT on the request path)
                       ┌──────────────────▼─────────────────────────┐
                       │               DATA PLANE                   │
                       │                                            │
   request ──► PEP ──► │  local PDP (sidecar / library)             │
                       │      │                                     │
                       │      ├─ lease cache (TTL, revocation)      │
                       │      └─ decision record ──► trace          │
                       └────────────────────────────────────────────┘

The dashed idea worth internalizing: the arrow from control plane to data plane is a push, not a call. Everything else follows from that.

3. The vocabulary

4. The request path, end to end

   1. AUTHENTICATE      verify the credential; extract agent, user, chain   (Phase 08)
   2. LEASE CHECK       live? not high-impact? not revoked? version current?
   3. KYA POSTURE       active, owned, model pinned, eval fresh, not anomalous
   4. POLICY            default-deny, deny-overrides, over (S, A, R, E)
   5. DECISION RECORD   effect, reason, rule, ALL matched, policy version
   6. OBLIGATIONS       mask, require approval, force audit
   7. ENFORCE           the action gateway performs it                      (Phase 10)
   8. TRACE             one span per step, carrying identity + version      (Phase 14)

Steps 2 and 3 are cheap and short-circuit; step 4 is the expensive one. Order them that way.

5. What lives where

The pattern: the control plane owns the truth; the data plane owns a copy and the decision.

6. The five things that will surprise you

1. Discovery is a policy decision. You will want tools/list to be a database query. It is not; it is an authorization decision per principal per request. See WARMUP §11.

2. Fail-static, not fail-shut. Everyone's instinct in a bank is "if we can't check, we refuse." That instinct produces an outage. See WARMUP §9.

3. Caching a deny is a bug. Caching an allow bounds how long a revocation takes. Caching a deny bounds how long a fix takes, which nobody wants.

4. A new bundle must invalidate leases. Otherwise your atomically-activated policy takes effect one TTL later, and the decision records in between name a version that is no longer active.

5. Posture is graduated. A binary posture check is one that operators will tune until it never fires.

7. Reading a policy engine

If you have never read Rego, this is enough to follow a review:

package platform.authz

import rego.v1

default allow := false                          # ← default-deny, explicitly

allow if {                                      # ← a rule; ALL conditions must hold
    input.action == "crm.read"
    input.resource.tenant == input.subject.tenant
    not deny                                    # ← deny-overrides, expressed by hand
}

deny if {                                       # ← multiple `deny` bodies are OR'd
    input.resource.classification == "restricted"
    input.subject.clearance != "restricted"
}

Three things to notice, because they are the ones that trip people up:

• default allow := false is the default-deny. If it is missing, an unmatched request produces undefined, and what your PEP does with undefined is now the security boundary.
• Multiple rules with the same name are a logical OR. Two deny blocks mean "deny if either".
• Deny-overrides is not built in. You express it, usually as not deny in the allow body. Cedar builds it in (forbid always wins), which is one of the reasons to prefer Cedar when you can.

Cedar, for contrast:

permit (
    principal in Group::"payments-agents",
    action == Action::"payments.release",
    resource in Book::"wholesale"
) when { context.approvals.size >= 2 };

forbid (principal, action, resource)
when { context.anomaly_score >= 0.5 };          // forbid ALWAYS wins

8. Where the neighbouring phases connect

9. What to build first

If you are standing up a control plane on a real platform, this order minimizes rework:

1. The agent registry, with a mandatory human owner and a pinned model version. Everything else references it, and retrofitting the owner field across forty agents is a quarter of work.
2. The decision record shape, including the policy version — even before there is a policy engine. It is the artifact everything downstream consumes.
3. A trivial policy engine with default-deny and deny-overrides, and three rules. The semantics matter more than the expressiveness, and changing semantics later breaks every rule.
4. Bundle distribution with fail-static, before the rule set grows. Retrofitting fail-static means rewriting how every PEP obtains policy.
5. Discovery filtering, before agents are built against an unfiltered list. Agents that have learned to expect a tool will break when it disappears.
6. Leases and continuous authorization, once the PDP is measurably on the critical path.
7. The kill switch, when the first agent gets a write capability. Not before, and definitely not after.