Developer platform

Build on the governed runtime.

One typed SDK, a REST API, and a CLI for the governed AI agent platform — register agents, propose actions, author policy, query the ontology, and read a tamper-evident Trust Ledger. The same gates that protect the console enforce on every request.

Book a demoSee the architecture

@cortex/client SDK · REST · CLI · Webhooks · Sandbox

agent.tspolicy.tscurl
example
// Author once. Every run is gated, every action provable.
import { Cortex } from "@cortex/client";
const cortex = new Cortex({ apiKey, tenantId });
// Propose a high-risk action — the gates decide.
const res = await cortex.actions.propose({
key: "refund.issue",
input: { amount: 5000 },
});
pending_approval{ status: "pending_approval", riskLevel: "high" }
// High-risk actions hold for an admin. Approve, then read
// the signed receipt — verifiable offline against the chain.
audit/verify ▸ { ok: true, brokenAtSeq: null, head: { seq: 1042, hash: "0x9f3a…c1" } }
Quickstart

From install to a governed verdict in three steps.

Install the SDK, authenticate against a tenant, and propose your first governed action — every call recorded in a Trust Ledger you can verify offline. The snippets below are illustrative examples.

  1. 01

    Install @cortex/client

    Add the typed SDK to your project. It is a thin client over the same REST API and the same fail-closed gates.

  2. 02

    Authenticate

    Construct the client with your tenant-scoped API key and tenantId. Every call is bound to your tenant in the data path — no cross-tenant reads.

  3. 03

    Run a governed action & read the verdict

    Propose an action. Low-risk runs execute; high-risk or approval-required actions hold as pending_approval. Read the verdict, then verify the receipt.

installexample
# 01 · install the typed SDK
npm i @cortex/client
 
# 02 · authenticate (API key + tenant)
import { Cortex } from "@cortex/client";
const cortex = new Cortex({
  apiKey: process.env.CORTEX_KEY,
  tenantId: process.env.CORTEX_TENANT,
});
run a governed actionexample
// 03 · propose — the gates decide the verdict
const res = await cortex.actions.propose({
  key: "refund.issue",
  input: { amount: 5000 },   // high-risk
});
 
// → { status: "pending_approval", riskLevel: "high" }
// low-risk actions return { status: "executed" }
Core concepts

Six ideas every integration is built on.

The surfaces are thin clients over the same governed runtime. Learn the concept, then follow each to its capability page for the full picture.

Governed runtime & gates
  • Every run passes the same ordered gates
  • Deny is the default — fail-closed
  • Stable codes: 402 · 403 · 409 · architecture
Ontology & permissions
  • Typed enterprise object model
  • Object & property-level RBAC (none/read/write)
  • Reads redact below read · ontology
Action Fabric
  • Named actions with a risk level
  • dry-run → propose → approve → execute
  • Immutable invocation ledger · action fabric
Trust Ledger & provenance
  • Hash-chained, tamper-evident audit
  • Signed receipts, verifiable offline
  • 10-hop lineage · trust ledger
Agent IAM
  • Agents are governed identities
  • Owner · risk tier · expiry · allowed models
  • Expired identity → 403 · agent IAM
Solution Packs
  • Ontology, policies & actions as one artifact
  • Signed · verified · diffed on import
  • Re-deploy into your tenant · packs
API & resources

The resource areas you'll work with.

Reach every governed surface over REST, the typed @cortex/client SDK, or the CLI. Below is what each resource area does — not an exhaustive endpoint reference. Follow a card for the full capability.

Agents & identities
client.agentIdentities

Register agents as governed identities with an owner, risk tier, expiry, and allowed models/actions. Expired or suspended identities are refused at runtime (403).

Learn more
Actions
client.actions

Named actions with a risk level and approval policy. Dry-run → propose → approve/deny → execute → compensate, each step recorded in an immutable invocation ledger with an evidence pack.

Learn more
Policies
client.governance

Author rules, then simulate a decision (with a per-rule trace) or run golden policy tests against a candidate rule set before you ship — most-restrictive effect wins.

Learn more
Ontology & permissions
client.ontology

A typed enterprise object model with object/property-level RBAC. Grants resolve to none / read / write; reads redact properties below read, and writes are gated per type.

Learn more
Audit & verify
GET /v1/audit/verify

A hash-chained, tamper-evident audit ledger. verify returns { ok, brokenAtSeq, head } over a range, and head returns the current chain head for external anchoring.

Learn more
Solution Packs
client.packs

Bundle ontology types, policies, and actions into a signed, versioned artifact. verify checks hashOk + signatureOk; import previews a diff and applies into the caller's own tenant.

Learn more
REST API@cortex/client SDKCLIWebhooks & events
Ways to integrate

Five surfaces, one governed runtime.

The API, SDK, CLI, and webhooks are thin clients over the same fail-closed gates — identity, budget, guardrails, registry, control-tower, policy, and audit. There is no ungoverned back door.

REST API

Drive every governed surface over HTTPS — register actions, propose and approve them, query the ontology, run governance simulations, and read the Trust Ledger. The same gates that protect the console protect the API.

tenant-scoped · Bearer token
  • Tenant scoping enforced in the data path
  • Admin-only routes (approve · deny · pack import) gated server-side
  • Stable status codes you branch on — 402 · 403 · 409
@cortex/client SDK

Typed TypeScript client over the REST API. Strongly-typed resources for agents, actions, governance, ontology, audit, and packs — with the same tenant scoping and gate semantics as the raw API.

npm i @cortex/client · ESM + types
  • client.actions · client.governance · client.packs
  • client.ontology.permissions · client.agentIdentities
  • Token + tenantId on every call
CLI

Ship governance from your terminal and CI. Export and verify signed Solution Packs, run policy tests as a regression gate, and check the Trust Ledger — without leaving the pipeline.

scriptable · CI-friendly
  • Run policy tests before you ship a rule change
  • Export and verify a signed pack (hashOk · signatureOk)
  • Verify the ledger chain offline
Webhooks & events

Cortex emits governed lifecycle events — ActionExecuted, ActionFailed, approval decisions — through the platform event path that also seals the Trust Ledger. Subscribe to reconcile against the tamper-evident audit trail.

event-driven · ledger-sealed
  • Action lifecycle: proposed · approved · executed · compensated
  • Every event sealed into the hash chain as it is recorded
  • Reconcile by ledger sequence (seq)
Sandbox & quickstart

A governed tenant you can provision and seed with sample ontology, policies, and actions. Run your first gated action and read a real Trust Ledger you can verify — without touching production.

tenant-isolated · 0 production blast radius
  • Seed sample ontology, policies & actions
  • Dry-run first — validate input, no side effect
  • Inspect every gate decision in the invocation ledger
Policy-as-Code

Version governance the way you version your app. Author allow / require-approval / deny rules, simulate a decision before shipping, and gate changes with golden policy tests in CI.

simulate · test · promote
  • Most-restrictive wins: deny > require_approval > allow
  • simulate() returns the per-rule decision trace
  • tests.run() as a regression gate before you ship
Provable, not just logged

Verify the ledger offline.

The Trust Ledger is hash-chained: each record seals the previous one. verifyChain recomputes the chain and returns { ok, brokenAtSeq } — any insert, edit, delete, or reorder flips ok to false. Outcome receipts are detached signatures you can verify with the published key, so a third party can confirm a run happened without trusting Cortex's database. The snippet is an illustrative example.

  • Chain integrity: verifyChain(records) → { ok, brokenAtSeq }
  • Signed receipts: verifyReceipt(claims, sig, key), constant-time
  • HMAC-SHA256 today; Ed25519 publishable verify keys are the documented upgrade
Explore the Trust LedgerSee the architecture
verify offlineexample
import {
  verifyChain, verifyReceipt,
} from "@cortex/provenance";
 
// 1 · recompute the hash chain
const v = verifyChain(records);
// → { ok: true, brokenAtSeq: null }
 
// 2 · verify a signed outcome receipt
const valid = verifyReceipt(
  claims, signature, verifyKey,
);
// → true   (tamper → false)
Go deeper

Understand the runtime you're building on.

The developer surfaces sit on top of the full platform. See how the gates fit together, and explore every governed capability end to end.

The architecture

Console, runtime gates, ~22 microservices, and one Postgres-backed ontology and Trust Ledger — the layered system every API call flows through.

The platform

Action Fabric, Agent IAM, the ontology, oversight modes, the MCP gateway, and the Trust Ledger — every governed capability, each reachable from the API and SDK.

Build governed agents on day one.

Get a guided tour of the API, SDK, and CLI — and see your first gated action land in a verifiable Trust Ledger.

Book a demoTalk to engineering