Policies & guardrails

Pre-beta · last updated 2026-06-10

Policy enginePolicies are enforced by the Cendriix orchestrator before any agent step executes. They cannot be bypassed by agent code — the enforcement layer is below the agent runtime.

Policies overview

A policy is a declarative rule that the Cendriix orchestrator evaluates before executing each agent step. Policies express three things:

Guardrails — hard rules that prevent unsafe or prohibited actions
Cost caps — ACU budgets enforced before spend occurs
Data consent — scoping rules for what data can cross agent boundaries

Policies are attached to a workspace, a team, or a specific workflow. Workspace policies apply to all runs in the workspace; team policies narrow them for specific teams; workflow policies are the most specific and take precedence.

Guardrails

Guardrails prevent agent actions that match a prohibited pattern. Cendriix ships a default guardrail set for all workspaces. You can extend it with custom rules.

Default guardrails (all workspaces):

No agent may delete a production database without a confirmed blast-radius score < 0.1
No agent may execute arbitrary shell commands outside a sandboxed devbox
No agent may exfiltrate data to an external endpoint not in the approved-endpoints list
No agent may make changes to identity/auth infrastructure (IAM, Cognito) without explicit human approval

yaml

# Custom guardrail in policy.yaml
guardrails:
  - id: no-prod-delete
    description: "Block any step that would DELETE from a production database"
    match:
      agent: "*"
      action: "database.delete"
      environment: "production"
    action: block
    notify_channel: "#security-alerts"

  - id: require-test-pass
    description: "Block deploy-canary if the test suite did not pass"
    match:
      agent: "deploy-canary"
      condition: "steps.run-tests.output.passed == false"
    action: block

Cost caps

Cost caps are enforced at three levels. When a cap would be exceeded, the step stops and the run enters a "cost-blocked" state. The owning team is notified via the configured channel.

Workspace cap — monthly ACU limit for the entire workspace
Team cap — monthly ACU limit per team
Run cap — per-run ACU limit set in the workflow YAML

The consent model controls which data categories can flow between agents in an A2A handoff. Each entity in the Cortex knowledge graph is tagged with one or more data categories (e.g., PII, PHI,financial, internal).

A consent policy defines which categories each agent type is permitted to receive. Handoff edges in a workflow carry a consent_scope that the orchestrator validates before the handoff executes.