Govern an AI ops agent with signed decision records

AI agents now do real work: they read customer records and push changes to production. This tutorial shows how to set limits on one, and how to prove afterwards what the limits decided.

You need no Cedar or Cedarling background. Acme, its people and its customers are fictional.

Why agents need guardrails and evidence

An agent acts fast and it acts for a person. If it reads the wrong customer, exports a whole database, or deploys unreviewed code, the damage is real and the person it acts for is accountable. Prompt text can also trick an agent into trying something nobody intended.

Guardrails mean a separate check, outside the agent, says yes or no before each action. The agent cannot talk its way past a rule it does not control.

Evidence is the second half. Auditors, customers and regulators ask what the agent was allowed to do and who said so. A signed record answers that without relying only on a log that someone could edit.

Meet Acme's ops agent

Alice is an on-call site reliability engineer (SRE) at Acme. Her ops agent helps her with three actions:

Action	What it does	Rule
Read a customer	Opens one customer's record	Only the customer named on the ticket assigned to Alice
Export customers	Copies the whole customer list	Never allowed for an agent
Deploy	Ships a workload to staging or production	Staging when Alice is on call. Production only for an approved change while a human is on call

Two more rules sit on top. An agent that is not trusted may do nothing. A request flagged as suspicious, such as a likely prompt injection, is blocked even if everything else is in order.

Cedarling is the open source engine that checks these rules. It answers each request with ALLOW or DENY and the rule behind the answer.

Try it in the Playground

The Playground runs the real Cedarling engine in your browser. Each link opens Alice's agent with one request ready to run. Press the run button and read the answer.

1. Read a customer on the ticket. Expect ALLOW, because this is the customer named on Alice's ticket. This answers: can the agent do its normal job?
2. Read a customer off the ticket. Expect DENY, because the customer is not the one on the ticket. This prevents the agent from browsing customers it was not asked about.
3. Export all customers. Expect DENY. This prevents bulk data theft, whoever asks.
4. Deploy to production, unapproved. Expect DENY, because no one approved the change. This prevents an unreviewed change reaching production.
5. Deploy to production, approved. Expect ALLOW, because the change is approved and a human is on call. This answers: can the agent still ship real work through the proper process?
6. The same approved deploy, with a prompt injection. In the Request Runner, set the Context dropdown to Prompt injection and change nothing else, then run it. Expect DENY. The change is approved, but the request is flagged as suspicious. This prevents a poisoned prompt from using an otherwise valid approval.

Want to see why? Open the policy file in the Playground. Each rule has an @id and a plain-English @reason. When a rule decides, the answer names it; when no rule allows the request, the answer is Deny by default.

See the proof

A decision you cannot check later is only a claim. Open the proof view to look at a recorded decision and check it yourself.

TRACE is Lock's format for signed evidence. When Cedarling decides, it can sign a record of that decision with its private key. Lock, the Gluu service that collects these records, verifies the signature and stores the record unchanged, so an auditor can fetch it later.

What the signature covers, and what it does not:

• Signed: the answer, the action, the rules release it was checked against, who signed, and when.
• Not signed: any story the demo adds around the record, such as who made the change. The proof view marks it as not part of the signed record.
• Not proven: that the agent obeyed the answer, or that every decision was reported.

If the proof view shows a recorded decision, press Tamper: change the answer to flip ALLOW to DENY. The signature check fails, because the record no longer matches what was signed. Reset restores it. This prevents quiet edits to the record after the fact. If it says "The recorded example is not published yet.", you can check your own file from the optional step below.

To check a file of your own, choose it under Proof file in "Verify your own", or paste its contents and press Verify pasted proof. It is checked in your browser. Nothing is uploaded.

Optional: make your own on Agama Lab

Agama Lab is Gluu's hosted workspace for designing and testing policies. This step runs a real decision on a sandbox server and downloads its signed record. You need an Agama Lab account and a GitHub-backed Agama Lab project.

The sandbox is a single shared environment. A reservation lasts about 15 minutes and can be kept for up to an hour. Download the proof bundle before you press Done testing, and do not press Deploy again before downloading, because that replaces the sandbox release.

1. Download the policy store from this site's address plus /resources/playground/policy-stores/acme-ops-agent/1.2.0.cjar, which is https://cedarling.dev/resources/playground/policy-stores/acme-ops-agent/1.2.0.cjar. A .cjar is a packaged set of rules, schema and settings.

2. In your Agama Lab project, open the Policy Designer and choose Import policy store using .cjar file.

3. Choose Test on sandbox, choose Working copy, then choose Deploy to sandbox. The first deploy can take 2 to 3 minutes while the sandbox starts.

4. Sign in as tester1. This test user has the role admin, which the store treats as an admin allowed to deploy.

5. Fill in the request with action AcmeOps::Action::"Deploy":

   • Resource type: AcmeOps::Resource

   • Resource: billing-api

   • Resource attributes (JSON):

     CEDARLING_GENERATED_CODE_BLOCK__STANDALONE-2

   • Context (JSON), which says the change is approved and a human is on call:

     CEDARLING_GENERATED_CODE_BLOCK__STANDALONE-3

6. Press Run decision, not Run. Run decision asks the sandbox server and produces a signed record; Run checks the request in your browser and produces none. Expect ALLOW.

7. On the decision, press Evidence. In the TRACE evidence section, press Load evidence. If it says "No TRACE records yet", wait a few seconds and press Load evidence again.

8. On the record, press Download proof bundle. Then open the proof view and choose the file under Proof file.

In production, match the ticket assignee on a stable identifier from your identity provider, such as sub, not a display name like given_name; the sandbox uses given_name because its test users have no other readable identifier.

This answers: is this decision from my own test, and does its signature check out?

What this does not prove

A valid signature proves which key signed the record, and that nothing in it changed since. That is all.

It does not prove the agent did what the decision said. The host application still has to enforce ALLOW and DENY.

It does not prove every decision was reported. A record that was never sent leaves no trace.

It does not make Acme's rules right. It shows which rules ran, not whether they were the right ones.

The Playground runs in your browser and does not sign records. Acme is fictional, and nothing here is a compliance or legal claim.