« Track Overview · Warmup · Lab 01
Phase 09 — The Control Plane: KYA, Zero Trust & Policy-as-Code
Answers these JD lines: "Design the platform's control plane, including policy-gated execution, Know Your Agent (KYA) enforcement at runtime, agent registries, tool registries, capability discovery, evaluation pipelines, and tracing and lineage at agent and tool granularity" · "Implement zero-trust principles across the agentic stack, including least-privilege scoping per agent and per task, real-time policy evaluation, behavioral posture checks, and continuous authorization rather than static service-account-style access."
Why this phase exists
The control plane is the layer that knows every agent in the bank — and being that layer is the entire justification for having a platform rather than twelve teams with API keys.
"Know Your Agent" is the JD's own coinage, by analogy to KYC, and the analogy is exact. For every agent in production you must be able to answer, at runtime, not at onboarding:
- who owns it, and is that person still here;
- what it may do — tools, scopes, data classifications, action limits;
- what model it uses and at which pinned version;
- what it has been evaluated against, and how recently;
- what its current posture is: anomalous behaviour, failed evals, an open incident.
And the zero-trust half: authorization is not a thing that happened at session start. An agent task can run for an hour while risk signals change, a user's entitlements change, or the agent's own evaluation goes stale. Continuous authorization means the decision is re-evaluated at each consequential step, not cached for the session.
The third element is the one that makes the other two enforceable: policy as code. A rule in a wiki is a suggestion; a rule in a versioned, tested, signed bundle is a control — and it is the only form an auditor can reconcile against a decision record.
Concept map
- Control plane vs data plane: what changes slowly and must be correct, versus what runs per request and must be fast. The synchronous-dependency trap and fail-static as the third posture (Phase 00).
- The agent registry: identity, owner, version, permitted tools, data classifications, evaluation status, environment, lifecycle state. The KYA database.
- The tool registry: from Phase 02, now as the control plane's authoritative source.
- Capability discovery: the registry filtered by policy for this principal, right now — the same filter-before-you-list rule as Phases 02 and 03, at platform scope.
- PDP / PEP: decision and enforcement separated, so one policy governs many enforcement points.
- Policy-as-code: OPA/Rego and Cedar; default-deny and deny-overrides; ABAC with a relationship component; the decision record with a policy version.
- Bundle distribution: versioned, signed, atomically activated, with staleness alarms and a hard stop — plus a second channel for urgent revocation.
- Posture checks: evaluation freshness, anomaly scores, recent behaviour, environment — fed into the decision as environment attributes, and split into categorical failures (stop everything) and graduated ones (stop the consequential actions only).
- Continuous authorization: re-evaluation triggers, decision TTLs, and what a revocation must interrupt.
- Evaluation pipelines: golden sets, trajectory scoring, safety suites, regression gates (RAGAS, Opik, LangSmith, Promptfoo as the named tools) — and evaluation status as a policy input, which is the idea that ties quality to authorization.
- Tracing and lineage at agent and tool granularity: what must be emitted for the decision to be reconstructable.
The lab
| Lab | You build | Proves you understand |
|---|---|---|
| 01 — The Control Plane | an agent registry with a full lifecycle; a Rego/Cedar-shaped policy engine with default-deny, deny-overrides and ABAC over (subject, action, resource, environment); versioned signed policy bundles with atomic activation, staleness alarms and a hard stop; authorization-aware capability discovery; posture checks including evaluation freshness and an anomaly score; continuous authorization with decision TTLs and mid-task re-evaluation; a kill-switch channel that beats the refresh interval; and a decision record carrying inputs, outcome, policy version and trace id | that the control plane is where "we know what our agents can do" stops being an aspiration — and that fail-static, signed bundles and policy-versioned decision records are what make it auditable |
119 tests, all green. Test contract: no matching rule denies; any deny beats any allow; an unreachable bundle source keeps the last known-good policy and raises staleness; past the hard stop the evaluator refuses; a suspended agent's in-flight task is interrupted by the kill switch within the stated latency; a stale evaluation blocks a high-impact action but not a read; and every decision record names its policy version.
Documents
| Document | For |
|---|---|
| WARMUP.md | zero to principal on control planes — first principles, then the interview answers |
| HITCHHIKERS-GUIDE.md | the fast orientation: what the pieces are and how they fit |
| DEEP-DIVE.md | the mechanisms, in detail, with the failure modes |
| PRINCIPAL-DEEP-DIVE.md | the trade-offs you own at principal level |
| CORE-CONTRIBUTOR.md | what it takes to work on OPA, Cedar or an internal PDP |
| STAFF-NOTES.md | judgment, review signal, war stories |
Deliverables checklist
- You can list the six things KYA must answer at runtime.
- You can explain fail-static and why fail-open and fail-shut are both wrong.
- You can write a default-deny, deny-overrides evaluation loop.
- You can explain why discovery is a policy decision, not a lookup.
- You can state a revocation-latency budget and how you meet it.
- You can explain why evaluation status is an authorization input.
- You can describe what a decision record must contain for an examiner.
Key takeaways
- KYA is a runtime property, not an onboarding checklist.
- Continuous authorization because a long task outlives the conditions that admitted it.
- Fail static: keep enforcing the last known-good bundle, alarm on staleness, hard-stop eventually.
- Policy in a bundle, entitlement facts in a local store — both versioned, neither on a synchronous network path.
- Discovery is authorization. A capability a principal cannot use must not be visible.
- Posture is graduated, not binary. A control that downs the fleet when an eval job runs late is a control operators will disable.
- Evaluation status gates action. That single link is what makes quality a control rather than a dashboard.
- A decision without a policy version is not evidence.