Policy Studio

Governance policies

Policies define what your agents are allowed to do. Every governed tool call is evaluated against your active policy before it executes — the decision is made, recorded, and receipted before the tool runs.

▲

CLI — ardyn policy

Create, list, and manage policies from your terminal. Interactive rule builder walks you through each field. Ideal for scripting, CI/CD, and developers who prefer the command line.

Best for: developers, automation, onboarding

■

Console — Policy Builder

Visual rule builder at ardyn.ai/console → Policies tab. Create rules, test them against live governance calls, and archive old policies — all in the browser. No terminal required.

Best for: ops teams, non-technical users, live testing

→

Both paths write to the same API. Policies created via CLI and policies created in the console are identical — stored in the same tenant ledger and evaluated by the same governance engine. Use whichever fits your workflow.

Policy concepts

Understanding how the policy engine evaluates tool calls before building your first policy.

Rules

A policy is a named collection of rules. Each rule has a condition (what to match), a verdict (what to do), and a reason (what appears in the AEA receipt).

Verdicts

Verdict	What happens	AEA minted?
ALLOW	Tool executes normally. AEA is minted with the governance decision.	Yes
BLOCK	Tool never executes. Agent receives an error with the block reason. No tool output.	Yes (block receipt)
ESCALATE	Execution paused. Routed to the escalation channel for human approval. Proceeds on YES, cancels on NO. AEA minted on YES only.	On approval only

First match wins

Rules are evaluated in priority order. The first rule whose conditions match the tool call determines the verdict. Order from most specific (BLOCK) to least specific (ALLOW).

Layers

Layer	Purpose	Evaluated
Business	High-level business controls (financial limits, regulatory requirements)	First
Operational	Day-to-day operating rules (safe tools, tool restrictions)	Second
Technical	Low-level technical controls (command patterns, file paths)	Third

Default disposition

If no rule matches, the default disposition applies — ALLOW or BLOCK. For most production policies, set default to Allow and write explicit BLOCK rules. For high-security, set default to Block and write explicit ALLOW rules.

Using the CLI

The Ardyn CLI provides three policy commands. Requires ardyn init to be run first.

ardyn policy create

Interactive rule builder. Prompts for each field and previews the policy before applying.

bash

ardyn policy create

ardyn policy list

Lists all active policies in your org with rule counts and status.

bash

ardyn policy list

ardyn policy show <id>

Shows all rules for a specific policy.

bash

ardyn policy show 7d67e1a2

Using the console

The Policy Builder is at ardyn.ai/console → Policies tab.

Policy examples

Common policy patterns for different use cases.

Financial agent

For agents that approve invoices, process payments, or access financial systems.

BLOCK delete_records BLOCK sudo ESCALATE send_payment ALLOW read_file ALLOW web_search

Clinical / PHI agent

For agents accessing patient records or clinical data.

BLOCK delete_record ESCALATE write_record ALLOW read_record ALLOW web_search

Code deployment agent

For agents that can write code and deploy to production.

BLOCK sudo BLOCK rm -rf ESCALATE deploy_production ALLOW terminal ALLOW execute_code

Research agent

For agents that browse, search, and summarize.

BLOCK write_file BLOCK execute_code ALLOW web_search ALLOW browser_navigate ALLOW read_file

Testing policies

Test policy rules before they affect production agents using the governance evaluate endpoint.

From the CLI

bash

curl -s -X POST https://api.ardyn.ai/v1/attest \
  -H "Authorization: Bearer $ARDYN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "api_key": "ardyn_live_...",
    "tool_name": "terminal",
    "input_hash": "$(echo -n '''{"command":"sudo apt-get update"}''' | sha256sum | cut -d" " -f1)",
    "output_hash": "$(echo -n '''...''' | sha256sum | cut -d" " -f1)"
  }'
# 200 → ALLOWED + AEA minted
# 403 → BLOCKED (policy or interlock)

From the console

In the Policies tab, expand any policy and click Test Rule next to a rule.

From the Test Governance tab

The Test Governance tab in the console tests arbitrary tool calls against the live policy.

Rule reference

Condition operators

Operator	Matches when	Example
Equals	Field exactly equals the value	tool_name Equals terminal
NotEquals	Field does not equal the value	tool_name NotEquals delete
In	Field is one of a list	tool_name In [read_file, web_search]
Matches	Field matches a regex pattern	tool_input.command Matches ^sudo
Contains	Field contains the substring	tool_input Contains tenants.db
Exists	Field is present and non-empty	hardware_report_hash Exists

Matchable fields

Field	Description
tool_name	Name of the tool being called
tool_input	Full tool input as JSON string
agent_id	The agent making the call
framework	Agent framework (openai, anthropic, langgraph, etc.)

Policy API

Method	Endpoint	Description
GET	/v1/policies	List all active policies
POST	/v1/policies	Create a new policy
GET	/v1/policies/:id	Get policy by ID
PUT	/v1/policies/:id	Update policy rules
POST	/v1/policies/:id/archive	Archive a policy
POST	/v1/attest	Govern + attest a tool call — evaluate policy, return verdict, mint AEA

Advanced topics

Dry-run / Preview

Test a policy version against a tool call without affecting the live ledger. The dry-run endpoint uses the exact same evaluation engine as enforcement — what you see is what you get.

bash

curl -s -X POST https://api.ardyn.ai/v1/policies/:id/versions/:v/dry-run \
  -H "Authorization: Bearer *** \
  -H "Content-Type: application/json" \
  -d '{
    "tool_name": "terminal",
    "tool_input": {"command": "sudo apt update"}
  }'
# Response: {decision, reason, matched_rules, changed_set}

✓Honesty property: the dry-run engine is the same instance that enforces. A dry-run ALLOW means the same call would be ALLOWED at enforcement time.

Policy versioning

Every policy is born at version 0. When you activate a policy, a snapshot of its current rules is taken as a new immutable version. Past versions remain in the history — version N can always be replayed for audit.

Method	Endpoint	Description
GET	/v1/policies/:id/versions	List version history
GET	/v1/policies/:id/versions/:v	Get a specific version snapshot
POST	/v1/policies/:id/activate	Snapshot current rules as a new version + activate

Rollback

Rollback is forward-restore: it creates a new version that is a copy of a previous version's ruleset. The restored version is a new policy version with its own activation receipt. The restored_from field in the receipt links back to the original version, forming an unbroken audit chain.

bash

curl -s -X POST https://api.ardyn.ai/v1/policies/:id/versions/:v/activate \
  -H "Authorization: Bearer ***

→Rollback always creates a new version — it never mutates or deletes history. Every state change is provable.

Publish receipts

Every policy activation emits a signed AEA (Ardyn Evidence Artifact) with kind: "governed_tool_decision". The AEA carries the policy hash, version number, and the full ruleset snapshot active at enforcement time. An auditor can verify that a specific tool call was evaluated against a specific policy version — independently, offline, with no access to the Ardyn gateway.

Public chain endpoints

These endpoints return live ledger state and are accessible without authentication. They power the live system metrics on the Ardyn homepage.

Method	Endpoint	Description
GET	/v1/chain/state	Live chain state — total entries, block count, timestamp
GET	/v1/chain/latest-aea	Most recent valid AEA (safe fields: id, tool, verdict, seq)
GET	/v1/verify/:id	Verify any AEA independently — no auth required