Authored as rules
Each rule is a condition (e.g. amountUsd >= 5000) plus an effect — allow, deny, or require_approval — and a priority. No redeploy: rules are tenant-scoped data the runtime reads on every run.
Policy-as-Code
Govern AI agents with rules you can test before you ship.
Author allow, deny, and require_approval rules in one place, simulate any decision before it goes live, and gate every change against a suite of golden policy tests — so a rule edit can never quietly change what your agents are allowed to do.
deny > require_approval > allow · simulate before ship · golden tests gate every change
Policy Studio
# cortex_policy_rules · priority order · deny > require_approval > allow
rule "high-value-payout" {
priority: 10
when: amountUsd >= 5000
effect: require_approval
}
rule "export-pii" {
priority: 5
when: action == "export" && pii == true
effect: deny
}
simulate ▸ POST /v1/governance/simulate
require_approval
allow
trace ▸ high-value-payout matched · reason: amountUsd >= 5000
governance ▸ simulate before ship · golden tests gate every change
Governance you can author
Policy is configuration, not a code deploy.
Cortex governance is a set of prioritized rules — each with a condition and an effect of allow, deny, or require_approval. The runtime evaluates them in priority order on every run, and the most-restrictive effect always wins: deny beats require_approval beats allow. Because rules are data, your risk and compliance teams author and change them directly — and every change is testable before it touches a single agent.
Most-restrictive wins
Rules apply in priority order, disabled rules are skipped, and the strictest matching effect prevails: deny > require_approval > allow. Governance defaults to caution, never to permission.
Simulated before ship
Run any context through the live rules — or an unsaved candidate set — and get the decision plus a per-rule trace, so you see exactly which rule fired and why before you save it.
Tested as a gate
Golden policy tests pin the decisions that must hold. Run them against a candidate rule set and a single failure tells you not to ship — a regression gate for governance itself.
The problem it solves
An untested policy edit is a silent change to what agents can do.
When governance lives in scattered if-statements and prompt text, a well-meaning rule edit can quietly widen what every agent is permitted to do — and you only find out in the audit. Policy-as-Code makes the rules explicit data, lets you preview a decision before it ships, and refuses to let a change land if it breaks a single golden case. The same engine powers both the live decision and the simulation, so what you test is exactly what runs.
Simulate any context → decision + per-rule trace, before savingdeny > require_approval > allow — most-restrictive effect winsOne failed golden test → the candidate rule set never ships
How it works
Author, simulate, test, ship.
One pure engine — evaluateRules(rules, context) — decides every run and every simulation. That shared path is what makes a simulation trustworthy: the preview and the production decision are the same code.
- 01
Author the rule
Write a condition and an effect — allow, deny, or require_approval — with a priority. Lower priority evaluates first; disabled rules are skipped. Rules are tenant-scoped data, not a deploy.
- 02
Simulate before ship
POST a context to /simulate against the live rules or an unsaved candidate set. You get the effect, the matched rule, the reason, and the full per-rule trace — preview the change before it's real.
- 03
Run the golden tests
Pin known cases as golden tests (context → expected effect). Run them against the candidate rule set; a single failure means a regression — don't ship it.
- 04
Ship under the gates
Once the candidate set passes, it becomes the live policy — evaluated on every run inside the same fail-closed runtime, alongside identity, budget, and the trust ledger.
Where policy sits
The policy gate is one stop in the run.
What's in the engine
Rules, simulation, tests, and the trace between them.
Rule authoring
- allow / deny / require_approval
- Condition + priority
- Enable / disable per rule
- Tenant-scoped, no redeploy
- CRUD + deleteRule via SDK
Evaluation engine
- Pure evaluateRules(rules, context)
- Priority order, lowest first
- deny > require_approval > allow
- Disabled rules skipped
- Same engine, live + simulate
Simulation
- POST /simulate { context }
- Live rules or candidate set
- Returns effect + matchedRule
- Per-rule trace + reason
- Preview unsaved changes
Golden policy tests
- context → expectEffect
- Create / list / delete cases
- POST /tests/run → passed/total
- Run against a candidate set
- Regression gate before ship
Trace & evidence
- Every rule's match/skip recorded
- Reason for the decision
- Matched rule identified
- GET /counts → rules, tests
- Auditor-readable output
Runtime floor
- Action requiresApproval still applies
- High-risk actions held separately
- Policy can only tighten, not weaken
- Fail-closed alongside other gates
- Admin-gated mutations console-side
Prove it — don't just claim it
Same rules, two contexts, two honest decisions.
Pin a require_approval rule at amountUsd >= 5000, then simulate. A $7,400 payout returns require_approval with the matched rule and reason in the trace; a $100 payout returns allow because nothing matched. No guessing — the simulation runs the exact engine that gates production.
- Simulate { amountUsd: 7400 } → require_approval
- Simulate { amountUsd: 100 } → allow
- An export with pii: true → deny (most-restrictive wins)
- Every simulation returns the matched rule, the reason, and the per-rule trace
Golden Policy Tests
POST /v1/governance/tests/run { candidateRules: […] } ▸ 3 / 4 passed
big-payout-needs-approval
{ amountUsd: 9000 } · expect require_approval
passsmall-payout-allowed
{ amountUsd: 100 } · expect allow
passpii-export-denied
{ action: export, pii: true } · expect deny
passrefund-under-cap-allowed
{ amountUsd: 240 } · expect allow · got deny
failtests ▸ 1 failed → candidate rule set does not ship (regression gate)
3Effects: allow · require_approval · deny
$7,400Simulated → require_approval (rule at ≥ $5,000)
$100Simulated → allow (no rule matched)
1Failed golden test blocks the rule change
Policy Studio
# cortex_policy_rules · priority order · deny > require_approval > allow
rule "high-value-payout" {
priority: 10
when: amountUsd >= 5000
effect: require_approval
}
rule "export-pii" {
priority: 5
when: action == "export" && pii == true
effect: deny
}
simulate ▸ POST /v1/governance/simulate
require_approval
allow
trace ▸ high-value-payout matched · reason: amountUsd >= 5000
governance ▸ simulate before ship · golden tests gate every change
Golden tests as a regression gate
Validate a rule change before it ever touches an agent.
Send a candidate rule set to /tests/run and Cortex evaluates every golden case against it without saving a thing. A naive deny-all candidate would fail the cases that expect allow — so the gate tells you not to ship it. Pin the decisions that matter once, and no future edit can silently change them; the run endpoint is the manual gate you run on every change.
- Run golden tests against a candidateRules set — nothing is saved
- Result is { total, passed, failed, results[] }
- A deny-all candidate fails the allow cases → don't ship
- The decisions you care about are pinned against every future edit
Works with the rest of the runtime
Policy doesn't enforce alone — the runtime does.
Policy-as-Code is one gate in the same fail-closed runtime as identity, actions, oversight, and the ledger. Follow the spokes.
Action Fabric
When a rule returns require_approval, the action lands in the approval inbox — pending_approval until an admin approves, never auto-executed.
Oversight Modes
The five autonomy modes set how much an agent may execute on its own — and the risk gate is a floor policy can tighten but never loosen.
Trust Ledger
Every policy decision is recorded in a hash-chained, tamper-evident audit trail with signed, offline-verifiable receipts.
Agent IAM
Agents are governed identities with allow-listed models and actions — policy decides per-run, identity decides per-agent.
Ontology
Object, property, and action permissions give policy conditions real business meaning to evaluate against, not just raw fields.
Control Tower
Live rule and test counts surface as KPIs and CSV rows — watch and export the state of your policy estate in one place.
Security & compliance
Built for the enterprise security review.
Deny-by-default evaluation, most-restrictive-wins precedence, admin-gated rule mutations, and a per-rule trace on every decision — mapped to the frameworks your auditors already use.
SOC 2ISO 27001ISO 42001HIPAAGDPREU AI ActNIST AI RMFFINRA
Write the rules once. Prove them every time.
Put your agent governance into testable, simulatable policy — so a rule change can never quietly change what your agents are allowed to do.