POLICIES
Defining what agentic systems are allowed to do
Waxell Policies are the runtime enforcement rules that govern what AI agents are allowed to do — defined centrally in the governance plane, applied uniformly across every workflow, and evaluated deterministically before execution proceeds.
Policies are the rules that determine what your agents can do, when they can do it, and what happens when they reach a boundary. Policies don't live in your workflow code. They live in the governance layer — defined centrally, enforced uniformly, applied the same way every time.
Waxell ships with 26 policy categories covering everything from cost controls to kill switches to PII protection. You define the rules. Waxell enforces them.
Free during beta. 2-line setup.
Agent-based workflows act across multiple systems, data sources, and decision points. Without explicit rules, acceptable behavior is implicit — which means it's inconsistent.
Policies change that. Policies determine which actions are allowed, which carry additional constraints, and which are blocked entirely. Governance stops being informal understanding and becomes enforceable control.
How Does Waxell Define and Manage Policies?
Policies are first-class governance objects in Waxell — not config files, not embedded business logic, not documented assumptions.
Waxell policies are defined in the governance plane and applied by reference across every workflow that uses them. Agents don't carry local copies of policy logic, and they don't interpret rules independently. When a policy changes, it changes everywhere — immediately, without requiring a code deploy.
Twenty-six policy categories. Each one governs a distinct surface area of agent behavior — from how much an agent can spend, to what it can remember across sessions, to whether it's allowed to send a message at all.
Every category in that grid is enforced at runtime. Not logged after the fact. Enforced before execution proceeds.
How Does Waxell Enforce Policies at Runtime?
Policies are evaluated deterministically before execution proceeds — conditions are met, or execution stops. No probabilistic reasoning, no adaptive interpretation, no silent override.
When a policy blocks execution, the outcome is explicit and logged: what was blocked, which rule applied, and the surrounding context. You don't reconstruct what happened from timestamps — the record is already there.
Policy management belongs to non-engineer operational owners. Because policies aren't embedded in workflow code, changing a rule doesn't require a code change and doesn't introduce drift. Changes take effect immediately, across every workflow that references them.
How Are Policy Decisions Recorded and Audited?
Every policy decision is recorded with enough context to understand what rule applied and why.
This is different from logging. Logging tells you what ran. Policy traceability tells you what was evaluated, what the outcome was, and the conditions that surrounded it. The record exists before you need it — not after an incident when you're trying to reconstruct intent from inference.
Every policy decision record is available in Waxell Observe — searchable, filterable, and inspectable without leaving the dashboard.
Observable by design.
All policy decisions are logged automatically. No instrumentation required.
Replayable in testing.
Agent behavior can be replayed in testing using the same inputs, rules, and constraints.
Context-complete.
Each decision includes the surrounding context — not just the outcome.
POLICY A
POLICY B
POLICY C
POLICY D
Designed to scale
