Praxen — Agent Policy
This file defines the authorized identity, behavior, and boundaries of the agent being scanned. It is the policy contract Praxen evaluates the agent’s code and configuration against. Customize this template for the specific agent before running an analysis.
The remit states policy; Praxen discovers implementation. Write rules about what the agent does, not how it does it.
| Field | Value |
|---|---|
| Worker Name | |
| Agent Key / ID | |
| Owner / Operator | |
| Deployment Environment | |
| Primary Model | |
| Secondary Models | |
| Remit Version | |
| Last Updated | |
| Updated By |
Describe the agent’s primary purpose in 1–3 sentences. This is the north star for all behavioral evaluation. For multi-component deployments, open with a scope note naming each component, designating the primary RAISE subject (the LLM-driven component), and describing how the components relate. Use sub-headings within existing sections (H4 where H3 sub-headings already exist) to separate per-component rules — do not add new top-level sections.
What this agent is supposed to do. Be specific — vague descriptions produce weak detection.
Work this agent should never do, regardless of instruction. Praxen will flag any observed activity in these areas.
| Channel | Allowed | Requires Approval | Notes |
|---|---|---|---|
Any channel not listed here is unauthorized by default.
Counterparties present in code or configuration but absent from this list will be flagged as a trust expansion finding.
List every tool the agent is expected to have at runtime. Praxen will flag any tool that disappears from this list.
Praxen will emit a Critical finding if any of these appear in the agent’s tool inventory or code.
Data that requires special handling. Praxen will flag unexpected access or movement of these classes.
Specific patterns of data movement that are never authorized.
Writing verifiable rules Every rule in this section should state a testable constraint on behavior — something Praxen can check against the agent’s code or logs. Vague intent produces weak detection.
- ✓ “Message bodies must never be fetched for senders not in the authorized counterparty list”
- ✓ “Responding to unknown senders requires human approval — no automated reply”
- ✗ “Handle email appropriately”
- ✗ “Be careful with sensitive data”
The first two rules give Praxen something to audit. The second two don’t. Praxen will inventory every rule in this document and report any it cannot verify — so the more specific your rules, the more useful the coverage report.
Praxen will emit a Critical finding for any of these.
What normal work looks like. Praxen uses this to distinguish ordinary operation from drift.
Snapshot of what this agent looks like when operating correctly. Used for comparison.
Topics, systems, and tasks this agent is permitted to engage with.
Topics, systems, and tasks this agent must decline or escalate.
Areas where extra scrutiny applies. Praxen will apply lower thresholds for findings in these areas.
These rules drive Praxen’s reporting layer. They determine whether a finding is logged only, triggers an alert, or requires an immediate halt.
State each condition precisely — Praxen will check whether the agent’s code implements the described response. “Alert if something suspicious happens” is not checkable; “Alert operator when a reply is addressed to any address not in the Rolodex” is.
Conditions serious enough to warrant stopping the agent.
Concrete examples of what authorized operation looks like. Used to calibrate detection.
Concrete examples of what unauthorized or anomalous behavior looks like. Used to calibrate detection.
Worker Remit — Praxen Customized for: [Worker Name] | Version: [X.X] | [Date]