Edictum
Edictum Control Plane

Edictum Control Plane

Optional hosted control-plane surface for remote ruleset delivery, approvals, and event visibility. It does not implement Workflow Gates.

AI Assistance

Right page if: you need the shipped control-plane surface for ruleset delivery, approvals, or event visibility. Wrong page if: you need Workflow Gates -- see https://docs.edictum.ai/docs/reference/workflows and https://docs.edictum.ai/docs/guides/workflow-gates. Gotcha: the control plane does not execute `kind: Workflow` documents. Workflow Gates run in the SDK runtime.

Edictum Control Plane is optional. It is not the Workflow Gates runtime.

Edictum enforces rules and workflows locally in the agent process. The control plane is the hosted layer for teams that want remote ruleset delivery, approvals, and centralized visibility.

What Control Plane Does

  • Hosts rulesets and pushes updates over SSE
  • Accepts audit events and shows them in the UI
  • Stores approval requests and operator decisions
  • Provides agent/fleet visibility for server-backed agents

What Control Plane Does Not Do

  • It does not enforce tool calls
  • It does not evaluate kind: Workflow
  • It does not store workflow stages as a first-class document
  • It does not replace the local SDK runtime

If the new story is Workflow Gates, stay in the SDK docs:

Use Control Plane Only When You Need

  • Remote ruleset updates without redeploying agents
  • Central approval handling for server-backed agents
  • A hosted event feed and fleet view
  • A control plane for remotely managed rulesets

Current Control Plane Docs

The control plane never evaluates rules or workflows in production. Agents evaluate locally. The server stores events, manages approvals, and pushes ruleset updates. Notifications support Telegram, Slack, Discord, and webhook channels, but only Telegram is interactive today.

Security

The control plane is a security-critical surface, so the security model matters.

  • Human auth: Clerk-backed operator traffic in the hosted app
  • API keys: workspace-scoped, one-way hashed, edk_-prefixed
  • Workspace isolation: API reads and writes stay workspace-scoped
  • Ruleset signing: server-backed rulesets are signed server-side
  • Fail closed: agents still enforce locally when remote coordination fails

Security model

License

FSL-1.1-ALv2 -- source available, converts to Apache 2.0 after two years.

Last updated on

On this page