Glossary Entry

What is Policy DSL?

DeAgenticAI's Policy DSL is a declarative language that defines AI agent governance rules — spending limits, allowlists, and escalation paths — enforced cryptographically at signing time.

Overview

Policy DSL is Layer 3 of the Agentic Control Plane stack — the layer that gives AI agent governance its operational substance. Where Layer 2 validates incoming agent proposals, Layer 3 evaluates them against governance rules and either authorises or blocks the signing ceremony.

DeAgenticAI’s Agentic Control Plane enforces cryptographic policy over AI agent authority — separating what an agent can do from what it is authorized to do — in Web3 and enterprise financial environments. Policy DSL is the language in which those authority boundaries are defined.

Existing policy languages — Rego, Cedar, policy-as-code — enforce governance rules at the application layer. They were built for enterprise software environments, not for autonomous AI agents signing cryptographic transactions. When the application layer is compromised, the software-layer policy can be bypassed. Policy DSL operates differently: rules defined in Policy DSL are enforced at the signing ceremony itself. An agent cannot produce a valid signature for an action that violates its active policy, regardless of what the orchestrating system instructs.

Policy DSL defines five categories of governance rules, each addressing a specific dimension of agent authority: spending limits, protocol allowlists, risk thresholds, time windows, and escalation paths. Together, these five rule types cover the full surface of agent authority — what the agent may spend, which protocols it may access, under what conditions it may act, during which hours, and which actions require human confirmation before proceeding.

How does it work?

  1. 1

    Evaluate validated intents against active policy

    Policy DSL rules are evaluated at signing time. When an AI agent proposes an action, the Policy Evaluation layer checks the validated intent against the active policy bundle tied to that agent's identity.

    A valid cryptographic signature is only produced if the intent satisfies every applicable rule. If a rule is violated, the action is blocked before the MPC signing ceremony — no valid signature, no on-chain transaction.

  2. 2

    Apply spending limits

    Spending limits define the maximum value an agent may transact — per action, per time period, or in aggregate.

    An autonomous treasury agent might be authorised to execute rebalancing transactions up to a defined threshold without human confirmation, with any transaction above that limit routed to an escalation path for committee review.

  3. 3

    Enforce protocol allowlists

    Protocol allowlists define the specific smart contracts, DeFi protocols, or destination addresses the agent is authorised to interact with.

    An agent operating under a DAO treasury Policy DSL can only sign transactions to protocols explicitly named in its allowlist. Attempts outside that list are blocked at Layer 3 before signing.

  4. 4

    Check risk thresholds and time windows

    Risk thresholds add conditional controls, such as restricting autonomous signing authority when volatility exceeds a defined threshold or during specific market conditions.

    Time windows add temporal constraints so the signing authority can be limited to defined operating hours.

  5. 5

    Route escalation paths

    Escalation paths define what happens when an action needs human confirmation before signing.

    Instead of hard blocking, Policy DSL routes the request to designated approvers such as a treasury lead, risk officer, or multisig group.

  6. 6

    Bind to sanitization and MPC verification

    Intent Sanitization (Layer 2) validates proposals before Policy DSL evaluation, so rules are applied to clean, verified intents rather than raw model output.

    Downstream, Intent-Evaluated MPC verifies the policy authorization hash independently at signing nodes, reinforcing Policy DSL enforcement.

Why does this matter?

Policy DSL enforces at the signing layer. The enforcement is not a software check that precedes signing — it is embedded in the signing ceremony itself. An agent cannot produce a valid MPC signature for a transaction that violates its policy bundle. The cryptographic architecture makes bypass structurally impossible, not merely prohibited.

For DAO treasury automation, this distinction is operational. A governance framework that can be bypassed by a compromised AI agent is not a governance framework — it is an audit log for incidents that have already occurred. Policy DSL creates enforceable limits on agent authority before any transaction reaches the chain.

Fast-Path Execution — sub-100ms signing for pre-authorised transactions — operates within the authorised policy context established by Policy DSL. Even the fast path cannot sign an action that violates the active policy bundle.

Frequently Asked Questions

What is Policy DSL?

DeAgenticAI's Policy DSL is a declarative language that defines AI agent governance rules — spending limits, allowlists, and escalation paths — enforced cryptographically at signing time.

It is Layer 3 of the Agentic Control Plane and enforces governance at the signing ceremony rather than the application layer.

How does Policy DSL differ from Rego or Cedar for AI agent governance?

Rego and Cedar enforce policy rules at the application layer, where a compromised orchestrator can bypass checks.

Policy DSL enforces at the signing layer, so an agent cannot produce a valid signature for policy-violating actions.

What governance rules can Policy DSL define for an AI agent?

Policy DSL supports spending limits, protocol allowlists, risk thresholds, time windows, and escalation paths.

These rules define what the agent can spend, where it can transact, when it can act, and when human approval is required.

Can a DAO use Policy DSL to automate treasury without losing governance control?

Yes. A DAO treasury policy can define exactly what the agent may do autonomously and which actions require committee escalation.

Governance is enforced as a structural signing constraint, with override paths defined through escalation rules.

Shape the Control Layer for Agentic AI

Our early access is invite-only. Join the design partner waitlist to track DeAgenticAI's progress and shape governed autonomous execution with our team. No marketing fluff-just infrastructure updates.

By joining, you agree to receive updates about our platform. No spam, ever.